Description

A focused course, tailored for you

Multi-Criteria SOC 2 Delivery for Assurance Managers

Build SOC 2 engagements that close clean: description alignment, subservice org decisions, and criteria expansion.

The description says one thing; the walkthrough evidence says another. Three weeks from issuance, the system description needs amending, the complementary user entity controls list has gaps the client didn't anticipate, and the management assertion has language that testing cannot substantiate.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Complex SOC 2 engagements fail at the description, not the controls. A well-scoped engagement with solid control design still produces a qualified opinion when the system description doesn't accurately represent the in-scope services, the subservice organization boundaries are ambiguous, or criteria categories were added without re-scoping the testing work program. For Senior Managers running multiple trust engagements, the same failure pattern recurs across clients: scoping decisions made at planning that unravel during fieldwork, description language inherited from the prior reporting period that no longer matches the production environment, and subservice organization disclosures that leave ambiguity the practitioner and client cannot resolve before issuance.

What you walk away with

Write a description of the system that accurately represents services, boundaries, and controls without requiring amendment during fieldwork.
Apply carve-out and inclusive methods for subservice organizations with documented rationale that survives practitioner review.
Scope and test Availability and Privacy criteria as additions to an existing Security-only engagement without reopening the security opinion.
Build a complementary user entity controls list that is traceable to specific criteria points and specific enough for user auditors to evaluate.
Draft and review the management assertion before testing begins so practitioners and clients agree on what the control environment covers.

The 12 modules

Module 1. Scoping the System Boundary

Define and document the in-scope system components: services, infrastructure, people, and processes the practitioner must cover. Addresses what happens when client-provided boundary documentation contradicts the production architecture, how to confirm the boundary before fieldwork starts, and how to produce the system boundary confirmation memo that practitioners and clients both sign off on before testing begins. Reusable confirmation template included.

Module 2. Writing the Description of the System

The description is what the report reader holds you to. Covers the five required elements under SSAE 18 and AT-C 320, how each maps to the testing work program, and the three most common description failures: inherited language from the prior period that no longer reflects production, controls described in general terms that evidence cannot substantiate, and services listed in the description but not included in the testing scope. Practitioner review checklist included.

Module 3. Common Controls and CC Criteria Evidence

Works through the criteria points practitioners most often find inadequately evidenced: CC6.1 through CC6.8 on logical and physical access management, CC7.1 through CC7.5 on system operations and monitoring, and CC9.2 on business partner risk management. For each criteria point the module identifies what acceptable evidence looks like in cloud-native environments where traditional paper-trail documentation does not exist. Testing note templates included for all three criteria groupings.

Module 4. Adding Criteria to an Existing Engagement

Expanding a Security-only engagement to include Availability, Confidentiality, or Privacy criteria is not additive; it requires re-scoping the description, extending the testing work program, and re-confirming the engagement letter. Covers the decision framework for when to add criteria versus when to start a new engagement, what the description must now include, and how to document criteria additions in the management assertion before fieldwork begins.

Module 5. Subservice Organizations: Carve-Out vs. Inclusive Method

The decision to carve out or include a subservice organization changes both the description and the testing scope. Covers the SSAE 18 decision criteria, how each method affects report language, what practitioner documentation is required to support the method chosen, and how to use vendor SOC 2 reports as complementary evidence when the inclusive method applies. Includes a subservice organization decision worksheet and report disclosure template for both methods.

Module 6. Building Complementary User Entity Controls

CUECs are assertions, not boilerplate. Derives CUECs from the tested controls so each is traceable to a specific criteria point, identifies the user entity control required, and is specific enough to be testable by a user auditor. Covers common CUEC failures: generic language not tied to a criteria point, missing controls for non-Security criteria, and language that describes the client system rather than the user entity's own responsibility.

Module 7. The Management Assertion: Review It Before Fieldwork

Most practitioners review the assertion after testing. This module argues for reviewing it before fieldwork begins. Covers what the assertion commits the client to, how practitioner testing evaluates those commitments, and the specific language AT-C 320 requires. Includes a pre-fieldwork assertion review protocol for Senior Managers to use with clients, and how to handle assertion language the evidence will not support before testing is underway.

Module 8. Testing Methodology for Trust Controls

Trust controls test differently from financial statement controls. Covers sampling methodology for Type II engagements covering a full annual period, how to design test procedures for automated controls with no paper evidence trail, how to evaluate control failures against the materiality threshold for SOC 2 opinions, and how to document testing conclusions when the evidence is a system log, an automated rule, or a configuration setting rather than a human sign-off.

Module 9. Control Deficiencies and Qualified Opinions

A control failure three weeks before issuance has three resolution paths: remediation with re-testing, qualification, or scope removal. Covers how practitioners decide which path applies, how to document the deficiency in the testing memo, how to communicate the finding to client management before it enters the report, and what the practitioner response looks like when the client wants to include a remediation plan rather than accept a qualified opinion.

Module 10. SOC 2 for AI and Automated Decision Systems

Applying trust criteria to AI pipelines and automated decision models requires evidence collection methods that traditional work programs were not designed to support. Covers how to scope AI systems into the system description, what controls apply to model training data governance and automated output monitoring, and which Security and Availability criteria points carry the most risk when the tested system is an AI pipeline rather than a human-operated service environment.

Module 11. Multi-Year Engagement Management and Bridge Letters

SOC 2 Type II reports cover a defined period, not a point in time. Covers how to manage the transition between reporting periods, when bridge letters are appropriate versus when they create practitioner exposure, how to document significant control changes that affect period-over-period comparability, and how to maintain the practitioner record of client communications so nothing needs to be reconstructed at the start of the next engagement cycle.

Module 12. Assembling and Issuing the Report Package

The complete deliverable: practitioner opinion, system description, criteria with management assertion, testing results, and CUEC list. Covers the pre-issuance review sequence with client management, what changes are acceptable at the final review stage without triggering re-testing, how to document the issuance decision in the engagement file, and how to manage rollout when the report goes to multiple relying parties with different disclosure agreements in place.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

Engagement starts with a client-provided boundary document last updated two reporting periods ago that doesn't reflect three infrastructure components added since the prior report.

Fieldwork is underway and testing evidence shows a control that operates manually two days per month, not continuously as the description states.

Client wants to add Privacy criteria to a Security-only engagement with four weeks left in the reporting period.

A cloud infrastructure vendor is both a subservice organization and a user entity; the engagement team must decide which relationship governs the SOC 2 scope.

What you get with this course

12 written modules in the Art of Service learning environment, accessible at your own pace.
Downloadable templates for system boundary confirmation, CUEC derivation, pre-fieldwork assertion review, and subservice organization disclosure.
Practitioner testing note templates for CC6, CC7, and CC9 criteria in cloud-native environments.
The hand-built implementation playbook: a practitioner-specific, engagement-ready version of the course methodology applied to your practice context, delivered alongside course access.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.

Before and after

Before

Each engagement has at least one three-week scramble before issuance: the description doesn't match the evidence, a subservice org disclosure the client and practitioner can't agree on, or a criteria addition that was scoped in planning but not fully tested.

After

Engagements close on time because the description was confirmed against the production architecture before fieldwork began, subservice org method decisions are documented before testing starts, and criteria additions are scoped into the work program at planning rather than identified as gaps at final review.

What happens if you do not address this

Late-stage scope conflicts are practitioner risk, not just scheduling risk. A qualified opinion on a trust report that a client's customers rely on creates exposure that a well-structured engagement would have avoided. The gap between what the description commits to and what the evidence supports doesn't resolve itself; it compounds each engagement cycle.

Who it is for

Trust assurance practitioners at the Senior Manager level who manage SOC 2 Type I and Type II engagements from scoping through report issuance. You've run enough cycles to know where the gaps tend to appear. This course provides a structured method for closing them before they reach the issuance memo.

Who this is NOT for. Entry-level auditors learning what SOC 2 is. This is for practitioners who already understand the AICPA Trust Services Criteria and need a repeatable method for managing complex multi-criteria engagements, handling subservice organization decisions, and building descriptions that hold through a full Type II cycle without amendment.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Most practitioners complete the course in four to six focused sessions, typically aligned to the planning and fieldwork phases of an active engagement.

Why $199 is the right number

The AICPA publishes SOC 2 guidance and practice aids at no cost. General assurance textbooks cover trust criteria in detail. Neither provides a practitioner-specific method for closing the description-to-evidence gap in an active engagement or a repeatable process for adding criteria scope without creating prior-period comparability issues. The course fills the execution layer between published standards and engagement management.

FAQ

Does this cover SOC 2 Type I engagements as well as Type II?

Yes. The description-writing, criteria scoping, subservice organization, and management assertion modules apply directly to both Type I and Type II. The testing methodology and control deficiency modules focus on Type II because that is where most engagement risk is concentrated, but the planning and scoping framing is useful for Type I work as well.

I already know the AICPA Trust Services Criteria well. Is this still useful?

The course is not a criteria explainer. It is a practitioner method for managing the gap between what the criteria require and what client control environments actually provide. If your engagements close without late-stage scope conflicts, you likely don't need it. If they don't, the gap is usually in the three artefacts the course focuses on: description, assertion, and CUECs.

Does it address SOC for Privacy and SOC for Cybersecurity?

The Privacy criteria modules align with the AICPA's SOC for Privacy framework and the Privacy category of the Trust Services Criteria. SOC for Cybersecurity is covered in the context of CC9.2 and the subservice organization modules. Dedicated SOC for Cybersecurity engagement management is outside scope, but the description and criteria scoping methods transfer directly.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.