A SOC 2 report is an independent CPA firm's attestation, issued under AICPA standards, on whether a service organization's controls meet the Trust Services Criteria within a scope the vendor and its auditor defined. Reviewing one consists of seven steps: confirming that the report type and period meet what the vendor's tier requires, checking that the scope covers the system and the Trust Services Criteria the user entity relies on, triaging every exception in the testing matrix rather than reading the opinion alone, extracting the Complementary User Entity Controls (CUECs) the vendor assumes the user entity operates, resolving how any subservice organization is treated, mapping the criteria to the reviewing program's practice controls, and dispositioning any bridge letter on file. The seven steps together produce a dispositioned record for the vendor file; a report accepted without them supports a narrower conclusion than the file records.
A SOC 2 report is a service organization control report issued under AICPA attestation standards, in which an independent CPA firm reports on whether a service organization's controls are suitably designed and, in a Type II report, operating effectively against the Trust Services Criteria. The report's conclusions are bounded by a scope the vendor and its auditor defined: a named system, a named set of criteria categories, and, for Type II, a stated review period. A SOC 2 report on file is therefore evidence about a defined scope rather than a general assurance that a vendor is safe to use, and the review determines the boundaries of that scope before the report is dispositioned as a completed due-diligence item.
In a vendor risk or third-party risk management (TPRM) engagement, the client's tiering policy determines what level of SOC 2 a vendor owes, and the reviewer reads the report as submitted, dispositions it against that policy, and returns a register recording each determination. This guide covers the seven-part method: report-type fit, scope, opinion and exceptions, CUECs, subservice organizations, the criteria-to-practice-control crosswalk, and bridge letters.
Report types: Type I and Type II
The two report types answer different questions, and the review confirms which type is in hand before any control row is read.
| Type | What it tests | What it does not test |
|---|---|---|
| Type I | Suitability of design at a single point in time. The auditor confirms the described controls exist and are built to meet the criteria. | Whether those controls actually operated correctly over any stretch of time. |
| Type II | Suitability of design and operating effectiveness across a defined review period. The auditor samples control operation and documents the test results. | Anything outside the stated review period, or outside the report's declared scope. |
Period length is assessed alongside type. No minimum is mandated, though practitioner convention treats a period under about three months as thin evidence and six to twelve months as the mature-program norm. A vendor's first SOC 2 sometimes carries a one- or two-month review window, occasionally called a gap or bridge-period report. The register records such a period explicitly as thin evidence rather than as equivalent to a full twelve-month period.
The type is fitted to the vendor's tier before the review proceeds. A critical-tier vendor is expected to hold Type II; a critical-tier vendor presenting only Type I represents a due-diligence gap to be logged, escalated for a compensating control, or waived with documented risk acceptance, rather than recorded as equivalent. The tier itself, and with it the required report type, is set upstream of the review — see the vendor risk categories a TPRM program should cover.
Scope and Trust Services Criteria coverage
A SOC 2 report covers what the vendor and its auditor agreed to scope. Confirming fit requires checking two separate dimensions.
System boundary. The system description, usually Section 3 of the report, names the specific product, environment, or business unit in scope. A vendor running twelve product lines may have scoped its SOC 2 to one of them. The review confirms that the system the user entity consumes is the system the report names by name, rather than inferring coverage from the vendor's cover correspondence.
Criteria category. SOC 2 reports are built around five Trust Services Criteria categories, and only one is mandatory.
| Category | What it covers |
|---|---|
| Security (mandatory) | Protection against unauthorized access, disclosure, and system damage that would compromise availability, integrity, confidentiality, or privacy. |
| Availability | System availability for operation and use, measured against the vendor's commitments and SLAs. |
| Processing Integrity | Complete, valid, accurate, timely, and authorized processing. |
| Confidentiality | Protecting information the vendor designated confidential. |
| Privacy | Personal information collected, used, retained, disclosed, and disposed of per the vendor's stated commitments. |
A report scoped to Security alone is a valid SOC 2, and it carries no assurance on any category outside that scope. Where the user entity depends on the vendor for uptime guarantees or personal-data handling, an out-of-scope Availability or Privacy category means the report provides no assurance on that dimension, irrespective of the Security section's findings. The category list is read off the cover or opinion letter directly; a vendor's description of itself as "SOC 2 certified" does not establish which categories were scoped.
Reading the opinion and triaging every exception
The auditor's overall opinion sits at the front of the report and summarizes conclusions that the testing matrix records in detail.
| Opinion | Meaning |
|---|---|
| Unqualified (clean) | Controls were suitably designed and, for Type II, operated effectively throughout the period, with no material exceptions. |
| Qualified | One or more material exceptions or scope limitations exist, but they aren't pervasive enough to invalidate the whole report. |
| Adverse | Controls weren't suitably designed or didn't operate effectively. Pervasive failure. |
| Disclaimer of opinion | The auditor couldn't obtain enough evidence to form an opinion at all. |
An unqualified opinion can coexist with individual "exceptions noted" rows inside the Type II testing matrix, usually Section 4, where the auditor judged those exceptions immaterial to the overall opinion. A clean opinion and a zero-exception testing matrix are distinct findings, and the review records each separately.
For every exception row, the reviewer captures which criterion it maps to, how many test instances failed against the sample size, whether a compensating control is documented, and whether the vendor remediated during the period or the exception remained open at report date. The escalation determination rests on failure rate, remediation status, and compensating control rather than on the presence of the word "exception." A single failed instance in a large sample, remediated during the period and supported by a compensating control, presents a different risk profile from a control that failed at every test instance.
Complementary User Entity Controls
A SOC 2 report assumes that the user entity operates certain controls on its own side. AICPA describes a Complementary User Entity Control as one the vendor's system description states it assumed the customer would implement, necessary in combination with the vendor's own controls for the relevant Trust Services Criteria to be achieved. A common example reads: "user entities are responsible for notifying us of changes to their authorized user list in a timely manner." Where that control is not operating on the user entity's side, the vendor's clean opinion does not deliver the assurance its scope appears to describe.
CUECs typically appear in the system description, sometimes with additional references attached to specific criteria rows in the testing matrix. The review reads that section in full rather than treating it as boilerplate. For each CUEC, the reviewer restates it in plain terms, names the internal control or team on the user entity's side that satisfies it — a CUEC about timely deauthorization maps to the user entity's own offboarding process — and confirms that the internal control is operating. A CUEC with no internal control mapped to it is recorded as a gap.
Subservice organizations: carve-out and inclusive methods
Most vendors of any complexity operate on top of other vendors: cloud hosting, payment rails, sub-processors. The report's treatment of those subservice organizations determines whether the review is complete or whether a second document is required.
- Carve-out method. The report excludes the subservice organization's controls from its own scope and states that the vendor relies on them without testing them directly. Where a carved-out subservice organization is material to the service, such as the vendor's cloud host, that organization's own SOC 2 report is obtained independently. A carve-out means the vendor's report carries no evidence about that layer.
- Inclusive method. The subservice organization's relevant controls are described and tested directly inside the vendor's own report. No separate report needed for that control set.
The register names every subservice organization mentioned in the report, records which method applies, and, for every carve-out, notes whether that organization's own report has been obtained or whether the gap is recorded as a documented risk acceptance.
Mapping the criteria to TPRM practice controls
The report's criteria follow AICPA's structure: Security's nine Common Criteria (CC1 through CC9), plus supplemental categories for Availability, Confidentiality, and Privacy. The crosswalk below converts those criteria rows into the practice-control areas a vendor risk engagement acts on.
| AICPA criteria | TPRM practice control area |
|---|---|
| CC1 (Control Environment) + CC9.2 (vendor and business-partner risk management) | Onboarding due diligence: confirms the vendor runs its own vendor-risk program on its fourth parties. |
| CC2.3 (communication of confidentiality/privacy changes) | Contract review: supports a contractual notice-of-material-change clause. |
| CC3.2 + CC3.4 (risk assessment includes vendor/partner threats and changes) | Ongoing monitoring triggers: corroborates that vendor-relationship changes are a monitored category on the vendor's own side too. |
| CC6 (Logical and Physical Access Controls) | Contracting access-control clauses at onboarding; offboarding access-revocation assurance. |
| CC7 (System Operations) + CC8 (Change Management) | Incident-response readiness and SLA/change-notification monitoring. |
| A1 (Availability, supplemental) | SLA and business-continuity clause verification. |
| C1 (Confidentiality, supplemental) | Data-handling and data-residency clause verification. |
| P6.4 + P6.5 (Privacy, supplemental) | Breach-notification clause and data-return/destruction terms. |
Every practice-control area the user entity's contract touches receives a determination — clean, exception, or not-in-scope — rather than being left blank because the report did not address it. A criteria category outside the report's scope is itself a determination for the record.
Bridge letters and their coverage limits
A bridge letter is a short, formal letter issued by the vendor rather than the audit firm, covering the interval between the end of the last report period and the current date. It is a management assertion rather than an audited statement, and it represents that no known material changes to the control environment have occurred since the report period ended. It is not signed by the CPA firm, does not test operating effectiveness, and by convention covers a short gap, commonly no more than about three months.
A gap of a few weeks to roughly three months with a bridge letter on file is logged and the vendor continues on cadence. A gap approaching or exceeding six to twelve months, repeated bridge letters in place of a new report cycle, or a stale report with no bridge letter, are each escalated: a current report is required, a compensating assessment is run, or a risk acceptance is documented at the appropriate authority level. A bridge letter's own date is part of the disposition; a letter a year old does not evidence that the underlying report is current.
The seven-step SOC 2 review checklist
The steps are run in order for every SOC 2 report a vendor submits.
- Confirm report type and period. Type I or Type II, exact dates, and whether the report meets the vendor's tier requirement.
- Check scope. The system named matches the system the user entity consumes, and every Trust Services Criteria category the use case depends on is in scope.
- Read the opinion, then the testing matrix. Every exception row is logged, not only the summary opinion.
- Extract CUECs. Each is mapped to an internal control on the user entity's side and confirmed as implemented.
- Resolve subservice organizations. Carve-out or inclusive, with the fourth party's own report obtained where material.
- Crosswalk criteria to practice controls. Onboarding, contracting, monitoring, incident response, offboarding.
- Disposition the bridge letter. Gap length, letter on file, accept or escalate.
Where SOC 2 reviews fail in a vendor risk engagement
- Treating "sent a SOC 2" as done. No confirmation of type, scope, or period before it gets filed as complete evidence.
- Reading only the opinion letter. The Section 4 testing matrix never gets opened, so exceptions embedded inside a clean opinion get missed entirely.
- Skipping CUEC extraction. The vendor's clean opinion gets credited with assurance the client's own team never actually implemented.
- Missing a subservice carve-out. Fourth-party risk gets treated as covered when it was never tested by anyone.
- Accepting a stale bridge letter. A letter sitting on file for a year, or a stack of successive letters, gets waved through instead of triggering a fresh-report requirement.
Fitting the review into a vendor-risk engagement
The review is not a standalone opinion. Each step's output feeds the client's vendor file, and the finished register is the deliverable. The review work is scoped explicitly at engagement setup, including which vendors receive the full seven-step treatment and which receive a lighter sampling pass by tier, on the same terms as any other deliverable defined in a terms of reference for a compliance consulting engagement. Where the engagement is competitively scoped, the methodology is named in the response when responding to a compliance consulting RFP rather than described as a generic "vendor due diligence" line item.
Exceptions and CUEC gaps logged during the review carry forward past the register. A CUEC with no internal control behind it, or a vendor exception with no compensating control, is remediation input, tracked as any other finding is tracked through a corrective action plan with an owner and a date. In a banking-as-a-service structure the review is partner-oversight work: a sponsor bank's non-delegable BSA/AML and operational responsibility extends to how a fintech partner's own vendors are vetted, which places the SOC 2 review among the concrete tasks inside sponsor-bank oversight of a partner program.
Primary sources
- 2017 Trust Services Criteria (with Revised Points of Focus – 2022), AICPA: the controlling criteria document for the five TSC categories and the Common Criteria referenced throughout this guide.
- 2018 SOC 2 Description Criteria (with Revised Implementation Guidance – 2022), AICPA: governs how a vendor's system description, including CUECs and subservice-organization treatment, is required to be written.
- System and Organization Controls (SOC) Suite of Services, AICPA: the overview distinguishing SOC 1, SOC 2, and SOC 3 engagements.
- Statement on Standards for Attestation Engagements No. 18, AICPA: establishes AT-C sections 105 and 205, the examination-engagement standard behind every SOC 2 report, as subsequently amended.
- Illustrative SOC 2 Report with Illustrative System Description, AICPA: a worked example of the report sections, including CUEC and subservice-organization language, referenced in Steps 2, 4, and 5 above.