Back to Blog
SOC 2 7 min read

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.

Key Takeaways
  • 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.

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?
A typical SOC 2 Type II report for a SaaS company scoped to Security only is 50–80 pages. Reports covering multiple Trust Service Criteria (Security + Availability + Confidentiality) are typically 80–150 pages. The length is driven primarily by the size of the controls table in Section 4 and the number of test entries in Section 5. Very short reports (under 30 pages) may indicate a narrow scope or a limited control framework.
Can we share our SOC 2 report publicly?
SOC 2 reports are confidential documents issued under NDA between the service organization, the auditor, and the intended recipients. They are shared with prospective and current customers under mutual NDA and are not intended for public distribution. Posting your SOC 2 report publicly on your website would violate the confidentiality provisions of most engagement agreements. If you want public evidence of your SOC 2 status, a SOC 3 report is the public-facing summary designed for that purpose.
What is the difference between a bridge letter and a SOC 2 report?
A SOC 2 report covers a specific historical observation period. A bridge letter (also called a gap letter) is an interim document from the service organization's management stating that no material changes to their control environment have occurred since the SOC 2 report's end date. Enterprise customers request bridge letters when a vendor's SOC 2 report is more than a few months old and they need assurance that controls are still operating while the new report is being prepared.
We are a startup reviewing a vendor's SOC 2. What are the most important things to check?
In order: (1) Is the opinion unqualified? (2) Does the report period cover a recent 12 months? (3) Does the scope cover the systems and services you are relying on? (4) Are your data and workloads in the environments described in Section 2? (5) What exceptions appear in Section 5, and were they remediated? (6) What CUECs in Section 2 require action from you? These six questions capture the most decision-relevant information without requiring a full legal review.
What is an "explanatory paragraph" in the auditor's report?
An explanatory paragraph is additional language the auditor adds to Section 1 outside the standard opinion paragraphs to draw attention to a specific matter. Common explanatory paragraph subjects include: a going concern indicator for the service organization, a scope limitation (the auditor was unable to perform a specific test), or context about a significant change in the system during the period. Explanatory paragraphs are not automatically qualifications — read them to understand what the auditor is flagging and whether it is material to your assessment.

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