How to Read a SOC 2 Report Before Signing a Vendor

Every SOC 2 Type II report follows a standard structure defined by the AICPA. Understanding this structure lets you navigate even the longest reports efficiently and extract the information your risk assessment requires.

Section I: Management's Assertion. This is the vendor's own statement that their controls meet the Trust Services Criteria. It's typically one to two pages and identifies the system in scope, the period covered, and the criteria addressed. Read this first to confirm the scope matches what you need — if you're evaluating their data processing platform but the report only covers their marketing website, the report isn't relevant.

Section II: Independent Auditor's Report. This is the auditor's opinion — the most important section of the entire document. It tells you whether the auditor believes the vendor's controls are fairly presented and operated effectively. We'll cover opinions in detail in the next section.

Section III: System Description. A detailed description of the vendor's system, infrastructure, people, data, and processes. This section helps you understand what the vendor actually does and how they do it. It typically covers the technology stack, data flows, personnel and roles, and physical infrastructure.

Section IV: Trust Services Criteria, Controls, and Tests. This is the longest section — often 50+ pages. It maps the vendor's specific controls to the applicable Trust Services Criteria and describes the auditor's tests and results. This is where you'll find exceptions and deviations.

Section V: Other Information (if applicable). Some reports include additional information provided by management that wasn't part of the audit. This section is unaudited and should be treated as supplementary context, not verified assurance.

The auditor's opinion in Section II is the single most important piece of information in the report. It comes in two forms, and the difference between them is significant.

An unqualified opinion (sometimes called a "clean" opinion) means the auditor concluded that the vendor's controls were fairly presented and operated effectively throughout the examination period. This is what you want to see. It doesn't mean the vendor is perfect — it means the auditor didn't find material issues with the controls in scope.

A qualified opinion means the auditor identified one or more material issues. The qualification will describe the specific areas where controls were insufficient or where the auditor couldn't obtain adequate evidence. A qualified opinion doesn't automatically disqualify a vendor, but it requires careful evaluation. What was the nature of the qualification? Has the vendor remediated the issue? Does the qualified area affect your specific use case?

In practice, qualified opinions are relatively rare because vendors typically work with their auditors to remediate issues before the report is finalized. If you encounter one, it deserves a conversation with the vendor about their remediation plan and timeline.

Also note the auditing firm itself. Established firms like Deloitte, EY, KPMG, PwC, Schellman, A-LIGN, and Coalfire have reputations to protect and maintain consistent standards. Smaller or less recognized firms may be perfectly competent, but if you're unfamiliar with the auditor, it's worth verifying they're a licensed CPA firm.

One of the most common mistakes in SOC 2 review is assuming the report covers everything the vendor does. It doesn't. The scope is defined in Section I (Management's Assertion) and Section III (System Description), and it can be narrower than you'd expect.

Look for three specific scope boundaries. First, which systems are covered. A vendor with multiple products may only have their primary product in scope. If you're using a different product — or a newly acquired product that hasn't been integrated into their control environment — the SOC 2 report may not apply to your deployment.

Second, which Trust Services Criteria are included. Security is always in scope (it's required), but Availability, Processing Integrity, Confidentiality, and Privacy are optional. If you're relying on a vendor for data processing but their SOC 2 only covers Security and Availability, there's no audited assurance around how they handle data accuracy or confidentiality.

Third, which infrastructure components are included. Vendors that run on cloud platforms like AWS or Azure often rely on subservice organizations. The report will either use the "inclusive" method (the vendor's report includes the cloud provider's controls) or the "carve-out" method (the cloud provider's controls are excluded and you need to review their SOC 2 separately). Most reports use the carve-out method, which means you may need to review the cloud provider's SOC 2 as well.

Document any scope gaps as part of your vendor risk assessment. A scope gap isn't necessarily a dealbreaker, but it should be noted and factored into your overall risk rating.

This is the section most teams skip — and it's the one that creates the most audit risk. Complementary User Entity Controls (CUECs) are controls that the vendor assumes you will implement. The vendor's controls are designed to work in conjunction with yours, and the auditor's opinion is predicated on the assumption that you're holding up your end.

Common CUECs include: managing user access and permissions within the vendor's platform, configuring security settings appropriately, monitoring your own logs and alerts, maintaining the confidentiality of API keys and credentials, and reporting security incidents promptly. If the vendor's SOC 2 assumes you're enforcing multi-factor authentication for all administrator accounts, and you're not, there's a control gap — regardless of what the vendor's report says.

When you review a SOC 2 report, extract the CUECs and map them to your own control environment. For each CUEC, ask: do we have this control in place? Is it documented? Can we demonstrate it during our own audit? If the answer to any of these is no, you've identified a gap that needs remediation.

This exercise serves double duty — it satisfies your SOC 2 CC9.2 requirements for vendor risk management, and it strengthens your own control environment by ensuring you're not relying on assumptions.

Section IV of the report lists the auditor's tests and results. When a control didn't operate as designed during the examination period, it's reported as an exception or deviation. These are the specific instances where something went wrong.

Not all exceptions are equal. A single exception in a population of 200 test samples — like one access review that was completed a day late — is a minor issue. Five exceptions in the same control area, or exceptions in critical areas like access management, change management, or incident response, suggest a systemic problem.

When evaluating exceptions, consider four factors. Frequency: one exception is noise; a pattern is a signal. Severity: an exception in a logging control is different from an exception in access provisioning. Remediation: did the vendor acknowledge the issue and describe corrective actions? Relevance: does the exception affect controls that are relevant to your specific use case?

There's no universal threshold for "too many exceptions." The context matters more than the count. A report with three exceptions in areas unrelated to your deployment may be perfectly acceptable. A report with one exception in a critical control area may require additional due diligence.

Document your evaluation of each exception and your rationale for accepting or escalating the risk. This documentation is precisely what your auditors want to see — not that you blindly accepted every report, but that you applied judgment and made informed decisions.

Reading a SOC 2 report without documenting your review is like conducting a vendor assessment without saving the results — the work happened, but you can't prove it. Your own auditors will want evidence that you reviewed vendor SOC 2 reports, identified relevant risks, and took appropriate action.

A SOC 2 review summary should capture: the vendor name and the product in scope, the report period and auditing firm, the type of opinion (unqualified or qualified), the Trust Services Criteria covered, any exceptions noted and your evaluation of their severity, the CUECs identified and your compliance status for each, any scope gaps and your risk mitigation approach, and the date of your review and the reviewer's name.

Keep these summaries organized by vendor and by review period. When your auditor asks how you evaluated Vendor X's SOC 2 compliance during the examination period, you should be able to produce the summary within minutes, not days.

For teams managing more than a handful of vendors, automating parts of this process is essential. Tools like ThirdProof can flag when vendor certifications change or expire, ensuring your documentation stays current between review cycles. The goal is a system where every vendor has a documented compliance status, and that status is refreshed on a defined schedule — not just when someone remembers to check.