--- title: "How to read a vendor's SOC 2 report (a buyer's due-diligence guide)" canonical: "https://auditbadger.com/blog/how-to-read-a-vendor-s-soc-2-report-a-buyer-s-due-diligence-guide/" last-updated: "2026-07-29" --- # How to read a vendor's SOC 2 report (a buyer's due-diligence guide) By Maciej • Published 2026-07-05 • 8 min read • Categories: Soc2, Compliance Governance, Risk Management **TL;DR:** A SOC 2 report is something to evaluate, not just collect. Confirm it's a current Type II covering the right system and criteria; read the auditor's opinion (unqualified, qualified, adverse, or disclaimer) and check a licensed CPA firm issued it; then read Section 4, because a clean report can still list exceptions that matter to you. Don't miss the two things buyers skip: the Complementary User Entity Controls (your security homework) and how subservice providers like AWS are handled (carve-out vs inclusive). Finally, remember a SOC 2 proves how a vendor runs security — specific promises like "we won't train on your data" live in the DPA, not the attestation. **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](/blog/what-is-soc-2-compliance-the-complete-guide-for-founders-2026/) 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](https://www.aicpa-cima.com/resources/download/illustrative-soc-2-r-report-with-description-and-assertion) 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](/blog/soc-2-for-ai-startups-controls-for-llm-model-risk/) 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](/blog/what-is-soc-2-compliance-the-complete-guide-for-founders-2026/) - [SOC 2 vs SOC 3: Which Report Do You Actually Need?](/blog/soc-2-vs-soc-3/) - [SOC 2 for AI Startups: Controls for LLM & Model Risk](/blog/soc-2-for-ai-startups-controls-for-llm-model-risk/) - [How Startups Can Get SOC 2 Without a Security Team](/blog/how-startups-can-get-soc-2-compliance-without-a-security-team/) ## Frequently asked questions ### Is a clean (unqualified) SOC 2 opinion enough to trust a vendor? Not on its own. An unqualified opinion means the vendor's controls were suitably designed and, in a Type II report, operated effectively overall — but a clean report can still list individual exceptions the auditor judged immaterial to the opinion. Read Section 4 (the auditor's tests and results) and check whether any exception touches a control you actually rely on. Also confirm the report's scope and period, and that you meet the Complementary User Entity Controls it assumes. ### What are Complementary User Entity Controls (CUECs) in a SOC 2 report? CUECs are controls the vendor assumed you — the customer — would implement for the overall arrangement to be secure. Typical examples are enforcing SSO and MFA on your side, deprovisioning your own departing users, configuring the product's security settings correctly, and reviewing your own access. They're listed in the system description section of the report. Extract them, confirm you actually perform each one, and keep that list — it's the vendor-diligence evidence your own auditor will want to see. ### What is a SOC 2 bridge letter and when should I ask for one? A bridge letter (also called a gap letter) is a signed management statement covering the period between a SOC 2 report's end date and today. Ask for one when a vendor's audit period ended several months ago, since the report itself says nothing about controls after its period end. Keep in mind the bridge letter is written by the vendor's management, not the auditor — the auditor can't attest to a period they didn't examine — so it carries a lower grade of assurance than the report. ### What does the carve-out method mean in a vendor's SOC 2 report? Under the carve-out method — the most common approach — the vendor's own subservice providers, such as AWS, GCP, or Azure, are excluded from the report, and you're expected to review those providers' SOC 2 reports separately. Under the rarer inclusive method, the subservice provider's controls are tested and included in the vendor's report. Check which method is used and whether the report names its critical subservice organizations; with carve-out, your due diligence isn't finished until you've accounted for the cloud infrastructure underneath. ### Does a vendor's SOC 2 report prove they won't train on or share my data? No. A SOC 2 report attests that a vendor operates its security controls in a disciplined way — it doesn't make specific data-use promises. Commitments such as not training on your data or not sharing it with a fourth party live in the data processing agreement (DPA) and the contract, not the attestation. Use the SOC 2 report to judge whether the vendor is operationally trustworthy, and use the DPA and master service agreement to pin down the specific promises you need in writing.