A SOC 2 report is the most common piece of evidence vendors will hand you, and one of the most misread. This guide walks through what to look for, in the order you should look for it, so a SOC 2 review takes minutes instead of days — and produces a conclusion you can actually defend.
Step 1 — Identify the report type and period
Before reading anything else, confirm two things:
- Type I or Type II? Type I tests control design at a point in time. Type II tests operating effectiveness over a period — usually 6 to 12 months. For most vendors processing real data, only Type II should be accepted.
- What period does it cover? A Type II report covering a 3-month window is weaker than one covering 12. A report whose period ended more than 12 months ago is stale; ask for a bridge letter or the next report.
Step 2 — Read the scope, not the marketing
The scope section defines what the auditor actually tested. Two questions to answer:
- Which system or service is in scope? A vendor with five products may only have one audited. Confirm the product you're buying is the one in the report.
- Which Trust Services Criteria (TSC)? Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional. If you are buying a service where availability matters or confidential data flows, the corresponding TSC should be in scope — its absence is itself a finding.
Step 3 — Check the auditor and the opinion
Find the CPA firm and the auditor's opinion letter. There are four opinion types:
- Unqualified — the controls operated as described. This is what you want.
- Qualified — one or more controls had material issues. The qualifications must be read and assessed individually.
- Adverse — controls did not operate effectively. Material concern.
- Disclaimer — the auditor could not form an opinion. Treat as no report.
Step 4 — Work through the exceptions
Exceptions are the deviations the auditor found. Most non-trivial reports have some. The question is never "are there exceptions?" but "what kind, and how were they handled?"
- Severity — does the exception affect a control you depend on (encryption, access provisioning, change management, incident response)?
- Frequency — a single missed access review is different from a pattern.
- Management response — has the vendor acknowledged it, remediated it, and changed the process?
Exceptions in critical control areas without a credible remediation response are red flags worth raising before contract signature.
Step 5 — Don't skip the CUECs
Complementary User Entity Controls (CUECs) are the things you have to do for the vendor's controls to work. Examples: provisioning and de-provisioning users in their portal, configuring MFA in their admin console, classifying data correctly before upload.
If you do not perform the CUECs, the vendor's controls do not protect you. Extract every CUEC, assign each to an owner inside your organisation, and add them to your operations backlog. This is often the most overlooked part of a SOC 2 review.
Step 6 — Check sub-service organisations and carve-outs
Most SaaS vendors rely on a cloud provider, a payment processor and a handful of other sub-services. The report will either include those (inclusive method) or carve them out (carve-out method). Carve-outs are not bad in themselves — but you need to verify the sub-service has its own attestation, and check that the boundary between the vendor's controls and the sub-service's controls is clear.
What a finished SOC 2 review should produce
Once the steps above are done, write down — in your assessment — at minimum:
- Report type, period, auditor and opinion.
- System in scope and Trust Services Criteria covered.
- Material exceptions and how they affect your decision.
- CUECs assigned to internal owners.
- Sub-services and their own assurance status.
For how SOC 2 relates to the other common attestation, see SOC 2 vs ISO 27001.