SOC 2 Report Structure: How to Read an Audit Report
A SOC 2 Type II report has five distinct sections. Learn how each section is structured, what to look for when reading one, and what the key red flags are.
- A SOC 2 Type II report has five sections: the independent service auditor's report (Section 1), the service organization's system description (Section 2), the service organization's assertion (Section 3), the description of criteria (Section 4), and the auditor's test results and exceptions (Section 5).
- Section 1 contains the auditor's opinion — this is the first thing enterprise security teams read.
- Section 2 describes the system scope, subservice organizations, and CUECs — critical for understanding the boundaries of the audit.
- Section 5 lists every control tested, the testing procedure, and any exceptions found — the most detailed and important section for security teams.
- An "unqualified" opinion means the auditor found no material deviations; a "qualified" opinion flags significant issues.
In this guide
Report Overview
A SOC 2 Type II report is a formal document produced by a licensed CPA firm that attests to the design and operating effectiveness of a service organization's controls over a defined observation period. Despite the "Type II" shorthand, the report itself is titled "Report on [Entity Name]'s Description of Its [Product/Service] System and the Suitability of the Design and Operating Effectiveness of Controls."
Reports are typically 40–150 pages depending on the number of criteria in scope, the complexity of the system description, and the number of controls tested. Enterprise security teams review reports as part of vendor due diligence. Understanding the structure allows you to navigate directly to the sections most relevant to your assessment without reading cover to cover.
Reports are issued under NDA and are not publicly available (unlike ISO 27001 certificates or SOC 3 public notices). Customers request reports through the vendor's trust portal, security team, or sales process. Auditors issue one report per engagement period — there is no partial report or milestone document during fieldwork.
Section 1: The Auditor's Opinion
Section 1 is the independent service auditor's report — the formal opinion letter. This is typically 3–5 pages and contains the most important information in the document. The auditor states: the scope of the engagement (which system, which criteria, which period); the responsibilities of the service organization and the auditor; the standards used (AICPA AT-C Section 205, TSP Section 100); and the opinion.
The opinion paragraph is the section to read first. An unqualified opinion states that the service organization's system description fairly presents the system, the controls are suitably designed, and they operated effectively throughout the period. A qualified opinion states that except for the matters described, the description and controls are fair — the exceptions are then described explicitly.
Adverse opinions (the controls are not suitably designed or did not operate effectively) and disclaimers (the auditor cannot express an opinion) are rare in practice — a service organization would typically withdraw from the audit or correct material issues before the report was finalized. In practice, the real question is whether the report is unqualified or qualified.
Section 2: System Description
Section 2 is the service organization's description of its system — the company's own narrative of how its product works and how it is secured. This section describes: the nature of the services provided; the infrastructure components (cloud environment, databases, networking); the software components; the people involved in security operations; the data flows and what data is processed; relevant aspects of the control environment; subservice organizations and the method used to account for their controls (carve-out or inclusive); and Complementary User Entity Controls.
When reviewing a vendor's SOC 2 report, read Section 2 carefully to understand the system boundaries. What is in scope? If the vendor's report covers only their US-hosted environment and you are storing data in their EU region, the audit may not cover the systems you care about. Scope boundaries are described in the first few pages of Section 2.
The CUEC section (usually near the end of Section 2) lists the controls that you, as the customer, must implement. This section generates action items for your own compliance program. Read it and cross-reference against your current control implementation.
Section 3: Management Assertion
Section 3 is a one-to-two-page statement signed by senior management of the service organization (typically the CEO and CISO) asserting that the system description in Section 2 fairly presents the system, the controls are suitably designed, and the controls operated effectively throughout the period. This is management's formal attestation.
The management assertion is addressed to the service organization itself (not to customers) and is separate from the auditor's opinion in Section 1. It establishes legal accountability — management is making a formal representation to the auditor that the description is accurate. If management makes a false assertion, they are exposed to professional and potentially legal consequences.
For customers reading the report, Section 3 provides limited additional information beyond confirming that management stands behind the report. The auditor's Section 1 opinion is the authoritative view of what the audit actually found.
Section 4: Trust Service Criteria
Section 4 presents the Trust Service Criteria against which the controls were evaluated. For a Security-only SOC 2, this section contains the AICPA's full text of the Common Criteria (CC1.1 through CC9.2) along with the service organization's specific controls that address each criterion.
The format of Section 4 is a table: the left column lists the criterion and its description; the right column lists the related controls implemented by the service organization. This mapping shows how the service organization claims to satisfy each requirement. The density and specificity of the controls listed is a quality indicator — vague controls ("management reviews security posture") indicate a less mature program than specific controls ("IAM access reviews are conducted quarterly by the system owner; access to production databases is restricted to three named administrators").
Section 4 is useful for enterprise security teams doing vendor due diligence — the controls table tells you exactly what the company does, not just that they passed an audit. A thorough review of Section 4 can reveal controls that are present, controls that seem incomplete, and criteria where the coverage appears thin.
Section 5: Tests of Controls
Section 5 is the longest and most detailed section — it contains the auditor's description of each test performed and the results. For each control in Section 4, the auditor describes: the test procedure used (inquiry, observation, inspection, re-performance), the sample size, the testing period, and whether exceptions were identified.
Exceptions are described in Section 5 alongside the test result. A typical exception entry: "Control: All production deployments require PR approval from a reviewer other than the author. Test: Inspected a sample of 25 production deployments during the period. Result: One exception was identified — deployment on [date] was performed without a PR approval. Management Response: The exception was investigated and found to be a one-time incident due to a branch protection misconfiguration that was corrected on [date]."
The management response to exceptions (included in Section 5) is your opportunity to read whether the company treated the exception seriously, understood the root cause, and implemented a fix. Multiple exceptions with no management response indicate a less mature control environment than one exception with a detailed root cause analysis and corrective action.
How to Read for Exceptions
When conducting vendor due diligence with a SOC 2 report, start with Section 1 to confirm the opinion type (unqualified vs. qualified). Then skip to Section 5 and search for "exception" — reading each exception entry to understand which controls failed and how many times. Count the exceptions by control area: one exception in change management and two in vulnerability remediation is a different risk profile than seven exceptions in access management.
Assess each exception on materiality: Does the exception affect a control that directly protects your data? Was it a one-time incident or a recurring pattern? Was the root cause identified and fixed? Is the fix documented in the management response? An exception that was caught, analyzed, and remediated tells you that the company's control environment is capable of self-correction — a more positive indicator than a perfect report from a company that clearly has not been tested.
For enterprise procurement, the security team typically asks the vendor to walk through their exceptions in a call — the vendor's ability to explain what happened, what they did, and how they verified the fix gives additional confidence beyond what the written management response provides. A vendor who is defensive or evasive about exceptions is a more concerning signal than the exceptions themselves.
Frequently Asked Questions
How long is a typical SOC 2 Type II report?
Can we share our SOC 2 report publicly?
What is the difference between a bridge letter and a SOC 2 report?
We are a startup reviewing a vendor's SOC 2. What are the most important things to check?
What is an "explanatory paragraph" in the auditor's report?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free