A SOC 2 report is an attestation examination performed under the American Institute of CPAs' Statement on Standards for Attestation Engagements (SSAE) No. 18, evaluating a service organization's controls against the Trust Services Criteria the AICPA maintains. "SOC 2 certified" is a common but technically wrong phrase - there is no certificate and no pass/fail badge. What a vendor actually holds is a report containing a licensed auditor's opinion, and the value of that opinion depends entirely on details most questionnaire-driven programs skip past: which criteria were in scope, what period was tested, and what the auditor actually found.
The Trust Services Categories - scope is chosen, not fixed
Every SOC 2 examination is scoped against some subset of five Trust Services Categories. Security (the "Common Criteria") is mandatory in every SOC 2 report; Availability, Processing Integrity, Confidentiality, and Privacy are optional add-ons the vendor selects. A report scoped to Security alone and one scoped to all five are both legitimately "a SOC 2 report" - they just say different things. Before weighing a report at all, check its cover page for which categories are actually in scope; a vendor handling health records under a Security-only report has not had its confidentiality or privacy controls examined at all.
Type I vs. Type II
A Type I report evaluates whether controls were suitably designed as of a single point in time. A Type II report goes further and tests whether those controls actually operated effectively over a review period - typically six to twelve months, sometimes as short as three months for a vendor's first report. Type I answers "does this look right on paper"; only Type II answers "did it actually work." For any vendor above your lowest risk tier, ask for Type II and decline a Type I offered as a substitute - it is materially weaker evidence, not an earlier edition of the same thing.
What the five sections of a report actually contain
| Section | What it contains |
|---|---|
| I - Management's assertion | The vendor's own statement that its system description is accurate and its controls meet the stated criteria. |
| II - Independent service auditor's report | The auditor's opinion: unqualified (clean), qualified (an exception limits the opinion), adverse, or disclaimer of opinion. This is the single most important line in the document, and it is the part a "SOC 2 on file" checkbox in a vendor management tool never captures. |
| III - Description of the system | The vendor's own account of the service, its infrastructure, and the controls in place - written by the vendor, not the auditor. |
| IV - Description of tests of controls and results (Type II only) | Every control tested, how it was tested, and the result - including any exceptions. A report with zero exceptions across a full year is worth more than a shorter review period; a handful of promptly-remediated exceptions is not automatically disqualifying, but an analyst who never reads this far will never know either way. |
| V - Other information provided by management (optional, unaudited) | Management's responses to any exceptions, remediation plans, and - most often - the list of complementary user entity controls below. The auditor did not verify this section; it is management's own commentary. |
Complementary user entity controls (CUECs) - the part vendors leave for you
A SOC 2 report's system description routinely assumes the customer runs certain controls on its own side - and the vendor's controls are only sufficient if the customer holds up its half. These are complementary user entity controls. Typical examples: the customer is responsible for provisioning and de-provisioning its own users' access, for configuring multi-factor authentication where the vendor offers it, or for reviewing the vendor's audit logs on some cadence. A report can carry a clean opinion while assuming CUECs your organization has never actually implemented - which means the assurance the report appears to offer is conditional on homework you have not done. Reading the CUEC list (usually in Section V) and confirming each one against your own configuration is a step a "collect and file" SOC 2 process skips almost every time.
Subservice organizations - carve-out vs. inclusive
Most vendors run on other vendors: a SaaS company's SOC 2 report almost always depends in part on its cloud infrastructure provider. The report handles this one of two ways. Under the carve-out method, the subservice organization's controls are excluded from the audit's scope and testing entirely - the report simply states that certain criteria rely on the subservice organization's own controls, and you are expected to separately obtain and review that subservice organization's report. Under the inclusive method, the subservice organization's controls are tested directly as part of the same engagement, and its results appear in Section IV alongside the primary vendor's. A carve-out is not a red flag by itself - it is the more common approach for cloud infrastructure - but it does mean the report in front of you is incomplete on its own, and following the chain down is exactly the exercise covered in fourth-party risk.
SOC 1 and SOC 3, briefly
Two adjacent reports are worth distinguishing so a vendor cannot substitute one for a SOC 2 unnoticed. SOC 1 is scoped to controls relevant to a customer's financial statement audit - internal control over financial reporting - and matters when a vendor's errors could misstate your books (a payroll processor or fund administrator, for example), not general information security. SOC 3 is a public-facing summary that can only be issued alongside a Type II examination; it carries the same overall opinion but omits Section IV's detailed control tests and results, which makes it a marketing document rather than an assessment input - ask for the full Type II report, not the SOC 3, whenever a vendor offers a choice.
What SOC 2 does not verify
- Current posture. A Type II review period ends before the report is issued, and the report is often months old by the time you read it. It says nothing about what changed after the period closed.
- Your specific contract terms. The Trust Services Criteria are generic; they do not check compliance with the security addendum, SLA, or breach-notification clause you actually signed.
- The vendor's real-world attack surface. The report documents controls the vendor's own system description describes - it is not an external scan of what is actually internet-facing today. See vendor attack surface monitoring for what that adds.
- Scope you did not check. As above - a category, a subservice organization, or a business unit outside the stated boundary is not covered, however clean the opinion looks.
Banking regulators have made this same point directly to their supervised institutions: the U.S. federal banking agencies' 2023 interagency guidance on third-party relationships expects institutions to evaluate a third party's SOC or similar independent reports as one input into ongoing monitoring - reviewing scope, testing results, and any exceptions - rather than treating receipt of the report itself as the diligence step.
Turning a SOC 2 report into TPRM actions
- Check the categories and period before anything else. A Security-only report or a stale review period changes what the report can support - see vendor tiering for how much scrutiny a given relationship warrants.
- Read the opinion type in Section II, not just whether a report exists. A qualified opinion or a pattern of unremediated exceptions in Section IV is a finding, not paperwork to file.
- Extract and verify the CUEC list against your own configuration rather than assuming your side is covered by default.
- Trace carve-out subservice organizations and request their reports separately when the vendor's own report does not cover them.
- Track the expiration date and fold it into continuous monitoring rather than discovering a lapsed report at the next scheduled reassessment.
Where this sits among TPRM platforms
SOC 2 review is table stakes in TPRM workflow tools - OneTrust, ProcessUnity, and Panorays all give a program a structured place to log a report, its coverage period, and its exceptions, and to flag the renewal date before it lapses. What none of those workflows do on their own is confirm the report's claims still hold today: BitSight, SecurityScorecard, and UpGuard contribute the externally observable half of the picture an audited-but-self-reported SOC 2 opinion cannot - what the vendor's attack surface actually looks like months after a testing period the auditor is no longer watching. Rescana's approach pairs that continuous, evidence-based monitoring with automated evidence collection, so a SOC 2 report is treated as one input checked against current signal rather than a document trusted at face value until the next renewal - the same gap covered generally in evidence-based risk scoring.
Frequently asked questions
What is a SOC 2 report and how is it used in vendor risk assessment?
A SOC 2 report is an independent attestation, performed by a licensed CPA firm under the AICPA's Statement on Standards for Attestation Engagements No. 18, evaluating a vendor's controls against the AICPA's Trust Services Criteria - Security plus, optionally, Availability, Processing Integrity, Confidentiality, and Privacy. It is not a certification; there is no pass/fail badge, only an auditor's opinion. In vendor risk assessment it is used as evidence of a vendor's control design (Type I) or operating effectiveness over a review period (Type II), read alongside the scope of categories covered, the auditor's opinion type, and any noted exceptions - not treated as sufficient on its own simply because a report exists.
What is the difference between SOC 2 Type I and Type II reports?
A Type I report evaluates whether a vendor's controls were suitably designed as of a single point in time. A Type II report goes further and tests whether those controls actually operated effectively over a review period, typically six to twelve months. Type I answers whether the control design looks right on paper; only Type II provides evidence the controls worked in practice over time. For any vendor above the lowest risk tier, a Type II report is materially stronger evidence and should be requested rather than accepting a Type I as equivalent.
What are complementary user entity controls (CUECs) in a SOC 2 report?
Complementary user entity controls are controls a SOC 2 report's system description assumes the customer - not the vendor - is responsible for implementing, without which the vendor's own controls may not achieve the stated criteria. Common examples include the customer managing its own user provisioning and de-provisioning, configuring multi-factor authentication where the vendor offers it, or reviewing the vendor's audit logs on a defined cadence. A report can carry a clean auditor's opinion while assuming CUECs the customer has never actually implemented, so verifying the CUEC list - usually found in the report's other-information section - against your own configuration is a necessary step, not an optional one.
Does a SOC 2 report replace continuous vendor monitoring?
No. A SOC 2 Type II report's review period ends before the report is issued, so by the time a customer reads it the report already describes a window that has closed - it says nothing about the vendor's posture since. It also does not observe the vendor's actual internet-facing attack surface, verify compliance with the specific contract a customer signed, or cover scope, subservice organizations, or business units outside its stated boundary. U.S. federal banking regulators' 2023 interagency guidance on third-party relationships explicitly frames a SOC report as one input into ongoing monitoring, not a substitute for it. Programs typically pair SOC 2 review with continuous, evidence-based monitoring to close the gap between the report's testing period and the vendor's current state.