SOC 2 Report Example: How to Read a SOC 2 Report (Anatomy & Sample)

What Does a Real SOC 2 Report Look Like?

A SOC 2 report is an official 50 to 120-page attestation document prepared and signed by an independent licensed CPA firm. It details the operational and security posture of a service organization, structured into five standardized sections mandated by AICPA attestation guidelines.

When an enterprise customer requests your SOC 2 report—or when a third-party vendor transmits their SOC 2 report to your risk committee—you do not receive a certificate or an executive summary slide deck. You receive a dense, legally binding technical document authored in accordance with AICPA Statement on Standards for Attestation Engagements No. 18 (SSAE 18), specifically AT-C Section 205.

Because real SOC 2 reports contain sensitive architectural blueprints, employee operational guidelines, database configurations, and subservice dependencies, they are classified as restricted-use documents and distributed exclusively under strict Non-Disclosure Agreements (NDAs). Understanding how to navigate this document quickly allows security leads, engineering directors, and procurement managers to extract critical risk indicators without getting lost in bureaucratic accounting prose.

To understand the broader foundations of compliance and how reports differ between operational and financial controls, see our guides on what SOC 2 is and SOC 1 vs. SOC 2 differences.

The Five Standard Sections of a SOC 2 Report

Every standardized AICPA SOC 2 attestation report is organized into five distinct sections: the Auditor’s Report (Section I), Management’s Assertion (Section II), System Description (Section III), Controls & Testing Matrix (Section IV), and Supplementary Information (Section V).

Each section serves a specific legal and technical assurance function:

Section I: Independent Service Auditor’s Report (The Opinion Letter)

Authored and signed exclusively by the independent CPA firm (typically 2 to 4 pages). This section represents the legal core of the deliverable. It outlines the scope of the examination, the time window evaluated, the responsibilities of management versus the auditor, and delivers the CPA’s formal professional opinion (Unqualified, Qualified, Adverse, or Disclaimer). If you only have five minutes to review a vendor’s report, Section I is where you start.

Section II: Management’s Assertion

Authored by executive management of the service organization being audited (1 to 2 pages). In this formal representation, the CEO, CTO, or VP of Security formally asserts that the system description in Section III fairly depicts the operational environment and that internal controls were suitably designed (and operated effectively, in a Type 2 report) to satisfy the specified Trust Services Criteria.

Section III: Description of the System (The Technical Narrative)

The most detailed descriptive section (typically 15 to 40 pages). Written by management, it provides an in-depth operational blueprint of the company and service. AICPA guidelines mandate that Section III address nine specific disclosure components:

• Types of Services Provided: The specific SaaS products, APIs, and cloud applications included within the boundary of the examination.
• Principal Service Commitments & System Requirements: Contractual commitments made to customers regarding uptime SLAs, data encryption standards, access controls, and privacy disclosures.
• System Components: Comprehensive inventories of cloud infrastructure (e.g., AWS EC2, S3, RDS, Kubernetes clusters), software applications, human personnel, operational procedures, and data types processed.
• System Boundaries & Exclusions: Explicit delineation of what is in scope versus excluded (e.g., production environments are in scope, while internal staging or internal marketing blogs are excluded).
• System Incidents & Operational Disruptions: Mandatory disclosure of any significant security incidents, unauthorized data access, or unplanned service outages experienced during the observation period, including impact assessments.
• Subservice Organizations & Reporting Method: Third-party infrastructure providers (such as AWS, Google Cloud, Datadog, or Stripe) whose functions are essential to the service. Management must explicitly state whether subservice entities were evaluated using the Carve-Out Method (where the third party’s controls are excluded from testing and relied upon via their own SOC reports) or the Inclusive Method (where the auditor directly tests the third party’s controls). In modern cloud SaaS, virtually all companies use the Carve-Out Method.
• Complementary User Entity Controls (CUECs): Essential security controls that customer organizations must implement within their own environments for your service’s controls to function effectively (e.g., managing client-side user credentials, enforcing strong client passwords, and configuring IP allowlists).
• Complementary Subservice Organization Controls (CSOCs): Controls expected to be implemented by subservice providers (e.g., AWS maintaining physical data center biometric security, environmental fire suppression, and redundant utility power).

Section IV: Trust Services Criteria, Controls, and Auditor’s Tests of Operating Effectiveness

The largest section of the report (typically 30 to 80 pages). Structured as a multi-column matrix, Section IV details every individual control activity mapped to AICPA criteria, the exact testing procedure performed by the CPA firm, and the testing results—including any deviations or exceptions observed during fieldwork.

Section V: Other Information Provided by the Service Organization

An optional, un-audited addendum provided by management. Common Section V disclosures include disaster recovery drill summaries, planned future infrastructure upgrades, or formal management responses to exceptions identified in Section IV. Note that the independent CPA firm explicitly disclaims an opinion on Section V content.

Decoding the Auditor’s Opinion: Unqualified vs. Qualified

An Unqualified Opinion is the gold standard of compliance, confirming that controls were fairly presented, suitably designed, and operated effectively without material misstatements. A Qualified Opinion alerts readers to significant control failures in specific areas.

When reading Section I of a vendor’s report, procurement leads must look for the formal opinion paragraph at the conclusion of the letter. The table below outlines how to interpret the four possible opinion types:

To understand the difference between point-in-time opinions and multi-month operational opinions, consult our detailed analysis of SOC 2 Type 1 vs. Type 2 reports.

Evaluating a Vendor’s Report: The 5-Step Procurement Rubric

When evaluating a vendor’s SOC 2 report, vendor risk management teams must follow a 5-step verification rubric: check report validity dates, verify CPA licensure, review scoping criteria, evaluate CUECs, and scrutinize Section IV testing exceptions.

Enterprise vendor risk management teams receive dozens of vendor reports annually. Reviewing each 80-page document line-by-line is practically impossible. By applying this structured 5-step evaluation rubric, security architects can thoroughly assess a vendor’s risk profile in under twenty minutes:

1. Check Dates & Demand Bridge Letters: Inspect Section I for the exact start and end dates of the observation period. SOC 2 reports reflect historical performance and carry a commercial validity window of 12 months. If the period ended more than 90 days ago, request a formal Bridge Letter (also called a Gap Letter). A valid bridge letter must:
   • Be authored on official company letterhead and signed by a C-level executive (CEO, CTO, or CISO).
   • Cover the interim gap period between the report end date and the current date (not exceeding 12 months total).
   • Explicitly state whether any material changes occurred in internal controls, personnel, or infrastructure that would adversely affect the achievement of the Trust Services Criteria.
   • Acknowledge that no significant security breaches or incidents occurred during the interim window.
2. Verify the Auditor’s CPA Credentials & Independence: Confirm that the report was issued by an accredited public accounting firm rather than an unaccredited cybersecurity consultancy or software vendor. Check that the CPA firm holds an active license with its state accountancy board and has received a "Pass" rating in its latest AICPA Peer Review public file.
3. Validate System Boundaries & In-Scope Criteria: Cross-reference Section III against the specific contract you are negotiating. Confirm that the specific SaaS application, API gateway, and hosting region storing your data are covered within the report boundaries. If you require high availability under an enterprise SLA, ensure the Availability criterion was actually audited, rather than relying on a Security-only report.
4. Inspect Complementary User Entity Controls (CUECs): Review the CUECs listed in Section III. Security in cloud SaaS is a shared responsibility model. CUECs specify the mandatory controls your organization must enforce internally. Typical CUECs mandate that user organizations:
   • Provision and maintain individual unique user credentials for all staff members.
   • Enforce corporate password complexity and mandate multi-factor authentication (MFA) on corporate Single Sign-On (SSO) connections.
   • Promptly de-provision terminated user accounts to prevent orphan access credentials.
   • Restrict administrative permissions within the SaaS portal to authorized, vetted personnel.
   If your organization fails to operationalize these customer-side controls, the vendor’s security controls cannot prevent unauthorized data access.
5. Scrutinize Section IV Exceptions & Management Responses: An unqualified opinion does not mean zero exceptions occurred during testing. Jump directly to Section IV and scan the right-hand column ("Test Results") for the words "Exception Noted" or "Deviation." When an exception is present, evaluate:
   • Sample Size vs. Failure Count: Did 1 out of 25 items deviate, or was it 8 out of 25? An isolated failure suggests minor human oversight, whereas multiple failures indicate an un-enforced or broken control.
   • Root Cause Analysis: Did the failure stem from an automated webhook timeout, an employee onboarding delay, or a lack of administrative oversight?
   • Compensating Safeguards: Did secondary controls catch the deviation before any customer data was compromised?
   • Management Remediation: Did management respond with concrete procedural or technical fixes deployed to prevent future recurrence?

What Gets Redacted in a SOC 2 Report and Why

Real SOC 2 reports are redacted to remove highly sensitive proprietary details, such as specific internal IP addresses, unmasked database passwords, internal vulnerability scan reports, and non-public customer identities.

While Section III provides a comprehensive architectural description, service organizations carefully balance transparency against exposure. Under AICPA guidelines, management is entitled to redact:

• Specific internal network IP ranges, VPN gateways, and subnet topologies that could assist threat actors in targeting network perimeters.
• Unmasked third-party customer names referenced in incident post-mortems or support escalations.
• Detailed source code snippets, proprietary cryptographic salt implementations, and API keys.

Because of the proprietary nature of this technical disclosure, service organizations strictly distribute SOC 2 reports under mutual non-disclosure agreements. If a vendor offers to email you an unredacted SOC 2 Type 2 report without requiring an NDA, this represents a significant operational red flag regarding their handling of confidential information.