How to Read a SOC 2 Report (Without a CPA)

The five sections of a SOC 2 report

A SOC 2 report looks intimidating — often 40 to 100 pages — but it has a fixed structure, and once you know the map you can read the parts that matter in well under an hour. Knowing which type you hold (Type I design-only, or Type II design-plus-operation over a period) is the prerequisite; this guide is about reading the report itself.

Every SOC 2 has the same five sections: (1) the independent auditor's opinion, (2) management's assertion, (3) the system description, (4) the trust-services criteria with the auditor's tests and results, and (5) any other information the vendor chooses to include. Most reviewers waste time reading front-to-back. Read them in priority order instead — the signal is concentrated in sections 1, 3, and 4.

Start with the opinion (Section 1)

The auditor's opinion is the bottom line, so read it first. There are four flavors and they are not subtle:

• Unqualified ("clean") — the auditor found the controls suitably designed and, for a Type II, operating effectively. This is what you want.
• Qualified — the auditor found one or more material problems; the report says 'except for…'. Not automatically disqualifying, but you must read exactly what the exception was.
• Adverse — the controls are not effective. A serious red flag.
• Disclaimer — the auditor couldn't form an opinion (usually insufficient evidence). Treat as no assurance.

Check the scope in the system description (Section 3)

Section 3 is the vendor's description of the system the report covers, and it is where scope games hide. The single most common SOC 2 mistake is accepting a report whose scope does not include the product you actually use.

Read it for three things: which system or product is in scope (is it the specific service you buy, or just the vendor's corporate environment?); the period covered (for a Type II); and which trust-services criteria are included. A clean opinion on the wrong scope tells you nothing about your risk.

Match the trust-services criteria to what you need

SOC 2 covers up to five trust-services criteria, and a report only addresses the ones the vendor chose to be audited against:

• Security (the 'common criteria') — always included; the baseline.
• Availability — uptime and resilience commitments. Require it if the vendor is in a critical path.
• Confidentiality — protection of information designated confidential. Relevant for most data-handling vendors.
• Processing integrity — that processing is complete, valid, accurate, and timely. Relevant for vendors that compute or transform your data.
• Privacy — handling of personal information per the vendor's privacy notice. Require it where the vendor processes personal data.
• If you need availability or confidentiality assurance and the report only covers security, that's a gap to raise — not a pass.

Read the test results and exceptions (Section 4) — the heart of it

Section 4 is the longest section and the one with the real signal. For each control, it lists the criterion it maps to, the test the auditor performed, and the result. The column that matters most is the exceptions (or deviations) — controls that failed during the period, with the vendor's management response.

Read every exception. A report with a handful of exceptions plus sensible remediation responses is normal and often more trustworthy than one claiming zero exceptions across a twelve-month window. What you are looking for is the pattern: are the exceptions minor and addressed, or do they cluster around access control, change management, or monitoring — the controls that matter most?

Find the controls YOU have to implement (CUECs)

Buried in most reports is a list of Complementary User Entity Controls — CUECs. These are the controls the vendor assumes YOU will implement for their controls to actually be effective. They are responsibilities the report quietly hands back to you.

Common CUECs: you must manage your own user provisioning and de-provisioning, configure the security features the vendor offers, protect your own credentials, and review the vendor's output for accuracy. Skipping the CUEC list is how a buyer assumes a vendor 'has security covered' while silently owning half the controls. Read them, and confirm you actually do them.

Check the subservice organizations (the vendor's vendors)

Most vendors rely on subservice organizations — their own critical providers (hosting, payments, email). A SOC 2 handles these one of two ways. The carve-out method excludes the subservice org's controls from the report (you're expected to review that provider's own SOC 2 separately). The inclusive method folds them in.

This is your fourth-party risk surfacing inside the report. If the report carves out a critical subservice org, note that you have an unexamined dependency one level down — and either obtain that provider's SOC 2 or accept the gap explicitly.

Mind the gap — the bridge letter

A SOC 2 Type II covers a defined window that almost always ended before the day you are reading it. The time between the report's end date and now is unexamined. For anything beyond a couple of months, ask the vendor for a bridge letter (also called a gap letter): a short statement, signed by vendor management, attesting that no material changes to the control environment occurred since the report period.

A bridge letter is not an audit — it's the vendor's own word — but its absence on a months-old report is worth noticing, and its presence is a reasonable stopgap until the next report lands.

A practical read order — and what to keep

Put it together: read the opinion (Section 1), confirm the scope and period and criteria (Section 3), work through the exceptions (Section 4), pull out the CUECs and check you do them, note any carved-out subservice orgs, and grab the bridge letter if the period is stale. Fifteen focused minutes on the right pages beats an hour reading cover to cover.

Then record what you found, because a SOC 2 is dated evidence that expires: the report type and period, the criteria covered, the exceptions you accepted, and when the next report is due. In a spreadsheet that record rots — the report ages out and no one notices. v3ndor's interface lets you record each vendor's SOC 2 details and renewal date on the vendor record and surfaces expiring attestations before they lapse, so the answer to "is their SOC 2 current, and what did it actually say?" is one click, not an archaeology project. Request access at /request-access to see it on your own vendors.