How to read a vendor's SOC 2 report (a buyer's due-diligence guide)

Key Concept: How to actually read a vendor's SOC 2® report during due diligence — where to look, what a clean opinion does and doesn't prove, and the two sections most buyers skip
Reading Time: 9 minutes
Difficulty: Intermediate
Relevant for: Founders, engineers, and security reviewers vetting a SaaS vendor

A vendor sends you a SOC 2 report as a 60-page PDF, usually behind an NDA, and the unspoken message is "we're compliant, please stop asking questions." Most buyers skim the first page, see the word "unqualified," and file it. That's a mistake. A SOC 2 report is evidence you're meant to evaluate, not a badge you collect — and read properly, it tells you exactly where a vendor's security actually stands and what work it quietly pushes back onto you.

This is the reader's side of SOC 2. If you're the one being audited, start with our complete SOC 2 guide for founders instead. This guide is for when someone else's report lands in your inbox and you have to decide whether it means anything.

First: confirm it's even the right report

Before reading a word of the controls, check three things on the cover and opening pages. Get any of them wrong and the rest of your review is wasted effort.

• Type I or Type II? A Type I report attests that controls were suitably designed at a single point in time. A Type II report attests they also operated effectively across a period (typically 3–12 months). Type II is the one that means something — it's the difference between "we drew a good blueprint" and "we lived in the house for a year and it didn't leak." Accept a Type I only from a genuinely early-stage vendor, and only as a temporary bridge to their first Type II.
• What period does it cover, and how old is it? A Type II covers a historical window — say, Jan 1 to Dec 31 of last year. If that window ended eight months ago, the report says nothing about the vendor's controls since. Ask for a bridge letter (also called a gap letter): a signed management statement covering the gap between the report's period end and today. Note the bridge letter is written by the vendor, not the auditor — the auditor can't attest to a period they didn't examine — so it's a lower grade of assurance than the report itself.
• What's in scope? The report covers a specific system and a specific set of Trust Services Criteria. Security (the common criteria) is always included; Availability, Confidentiality, Processing Integrity, and Privacy are optional. Confirm the product you're buying is the system that was audited — not a sister product or a legacy platform — and that the criteria you care about (Confidentiality and Privacy, if they'll hold your data) are actually covered.

Read the auditor's opinion — and check who wrote it

Section 1 of the report is the independent auditor's opinion, and it comes in four flavors. This is the single most important paragraph in the document (AICPA publishes an illustrative report if you want to see the standard structure):

• Unqualified — clean. Controls were suitably designed and (in a Type II) operated effectively. This is what you want, but it is not a promise of zero exceptions — see the next section.
• Qualified — clean "except for" one or more specific areas that fell short. A qualified opinion is not automatically disqualifying; read what was qualified. A qualification on a control irrelevant to your use case is very different from one on the exact area you're relying on.
• Adverse — the auditor found pervasive, material failures; the system did not operate as described. Treat this as a stop sign.
• Disclaimer — the auditor couldn't gather enough evidence to form an opinion. Rare, and a red flag about cooperation or documentation.

Then check who signed it. The opinion is only as good as the firm behind it — it should be issued by a licensed CPA firm, not a "compliance platform" or an unlicensed consultancy. A recognizable, peer-reviewed audit firm is a quiet but real quality signal.

The section that actually matters: tests and exceptions

Everyone reads the opinion. Almost nobody reads Section 4 — the description of the auditor's tests and their results — which is where the truth lives. For each control, a Type II report states what the auditor did to test it and whether they found any exceptions (deviations where the control didn't operate as intended).

Here's the nuance that separates a real review from a rubber stamp: a report can carry a clean, unqualified opinion and still list exceptions. The auditor may judge individual deviations immaterial to the overall opinion — but "immaterial to the auditor" is not the same as "immaterial to you." Read every exception and ask: does this touch how the vendor will handle our data? An exception in a control you don't depend on is noise; an exception in access revocation, encryption, or backup restoration — when that's exactly what you're buying — is a conversation.

Where a vendor has exceptions, look for their management response (often in Section 5, "Other Information"). A vendor who names the deviation, explains the root cause, and describes remediation is showing you a working control environment. Silence, or defensiveness, tells you something too.

The two things buyers almost always miss

Complementary User Entity Controls — your half of the deal

Buried in the system description is a list of Complementary User Entity Controls (CUECs): controls the vendor assumed you would implement for the whole arrangement to be secure. A vendor's SOC 2 is designed on the premise that you do your part — enforce SSO and MFA on your side, deprovision your own departing users, configure the product's security settings correctly, review your own access.

This is the most commercially useful part of the report and the most ignored. The CUECs are a free, vendor-written checklist of the security homework their compliance depends on you doing. Extract them, confirm you actually do each one, and keep that list — during your own audit, "we reviewed each vendor's CUECs and confirmed our responsibilities" is exactly the kind of vendor diligence assessors want to see.

Subservice organizations — the vendor's vendors

Your vendor almost certainly runs on a subservice organization — AWS, GCP, Azure. There are two ways their report handles it. Under the far more common carve-out method, the subservice provider's controls are excluded from this report, and you're expected to review that provider's SOC 2 separately (their cloud host's report is a link in the chain, not an afterthought). Under the rarer inclusive method, the subservice provider's controls were tested and appear in this report.

Check which method is used and whether the report names its critical subservice organizations. Carve-out is normal and fine — but it means the report in your hands doesn't cover the infrastructure underneath, so your diligence isn't finished until you've accounted for that layer too.

A practical read: the 8-point checklist

1. Type II, not Type I (for anything beyond an early-stage bridge).
2. Recent period — and a bridge letter covering any gap to today.
3. Right system + right criteria in scope (your product; Confidentiality/Privacy if they hold your data).
4. Opinion — unqualified; read carefully if qualified; stop if adverse or disclaimer.
5. Licensed CPA firm issued it.
6. Exceptions in Section 4 — read every one against your use case, not just the summary.
7. CUECs — extract them and confirm you meet your side.
8. Subservice organizations — note carve-out vs inclusive, and review the cloud provider's report if carved out.

A SOC 2 report is a "how," not a "yes"

The final mindset shift: a SOC 2 report proves a vendor runs their security program in a disciplined way. It does not answer every specific question you might have. A common trap — one we flag for AI startups too — is assuming a vendor's SOC 2 proves they won't, say, train on your data or share it with a fourth party. It doesn't. That commitment lives in the data processing agreement and the contract, not the attestation. Use the SOC 2 report to judge whether the vendor is operationally trustworthy; use the DPA and MSA to pin down the specific promises you need.

How AuditBadger helps

AuditBadger gives small teams one place to run exactly this kind of vendor diligence: a register of your critical vendors, each one's SOC 2 status and report period, the CUECs you're responsible for, and reminders when a report is going stale and it's time to ask for the next one or a bridge letter. When your own auditor asks how you evaluate the security of your subprocessors, you have the answer already documented — and onboarding is run by our founding team, so you're not decoding someone else's report alone.

Reading a vendor's SOC 2 well is a small skill with outsized leverage: it's how you tell a vendor who runs a real security program from one who just paid for a nice-looking PDF.

Related reading

• What Is SOC 2 Compliance? The Complete Guide for Founders
• SOC 2 vs SOC 3: Which Report Do You Actually Need?
• SOC 2 for AI Startups: Controls for LLM & Model Risk
• How Startups Can Get SOC 2 Without a Security Team