SOC 2 Report Explained: What It Contains and How to Read It

At Agency, we review dozens of SOC 2 reports each year — both helping our clients prepare to receive their own reports and advising procurement teams on how to evaluate vendor reports. The most common question we hear from both sides is: what should I actually be looking at in this document? A SOC 2 report is the deliverable produced by a licensed CPA firm at the conclusion of a SOC 2 attestation engagement. The report contains five major sections: the independent auditor's opinion, management's assertion, the system description, the description of criteria and related controls, and (for Type II reports) the results of testing. Understanding how to read each section is essential for two audiences — security reviewers and procurement teams evaluating vendor SOC 2 reports, and organizations preparing to receive their own report for the first time. The auditor's opinion is the single most important element — it tells you whether the controls met the Trust Service Criteria — but the details in the system description, control descriptions, and test results provide the context needed to make an informed risk decision.

This guide walks through each section of a SOC 2 report, explains what to look for, how to interpret the auditor's opinion, what exceptions and findings mean, and how to evaluate whether a report demonstrates adequate controls for your vendor risk management program.

SOC 2 Report Structure

The Five Sections

Every SOC 2 report follows a standardized structure defined by AICPA attestation standards:

Section	What It Contains	Who Writes It
Section 1: Independent Auditor's Report	The auditor's opinion on whether controls meet the Trust Service Criteria	The CPA firm (auditor)
Section 2: Management's Assertion	Management's statement that the system description is fairly presented and controls are suitably designed (and operating effectively for Type II)	The service organization's management
Section 3: System Description	Detailed description of the service, infrastructure, software, people, procedures, and data	The service organization (reviewed by auditor)
Section 4: Description of Criteria, Controls, Tests, and Results	Trust Service Criteria mapped to specific controls; for Type II, includes test procedures and results	Controls described by management; tests and results by auditor
Section 5: Other Information	Optional section for additional context provided by management	The service organization

Type I vs Type II Report Differences

Element	Type I Report	Type II Report
Opinion scope	Controls are suitably designed at a point in time	Controls are suitably designed and operating effectively over a period
Test results	No testing of operating effectiveness	Detailed testing procedures and results for each control
Observation period	Single date (e.g., December 31, 2025)	Date range (e.g., January 1, 2025 through December 31, 2025)
Typical length	40-80 pages	80-200+ pages
Enterprise buyer acceptance	Limited — many buyers require Type II	Broadly accepted by enterprise procurement

Section 1: Independent Auditor's Report (The Opinion)

What It Contains

The auditor's report is the most critical section — it contains the CPA firm's professional opinion on whether the service organization's controls met the applicable Trust Service Criteria. The opinion letter typically includes:

• The scope of the engagement (which Trust Service Criteria were evaluated)
• The period covered (Type II) or date evaluated (Type I)
• The auditor's responsibilities and the standards used
• The opinion itself — unqualified, qualified, adverse, or disclaimer

The Four Opinion Types

Opinion	What It Means	How to Interpret
Unqualified (clean)	Controls are suitably designed and operating effectively; no material exceptions	The report meets the standard — proceed with vendor evaluation based on the details
Qualified	Material exceptions exist in specific areas, but the overall control environment is effective	Review the specific qualifications carefully; evaluate whether the exceptions affect controls relevant to your data
Adverse	Significant and pervasive control deficiencies; controls do not meet the Trust Service Criteria	The report indicates fundamental control failures — significant concern for vendor risk
Disclaimer	The auditor was unable to obtain sufficient evidence to form an opinion	The auditor could not complete the assessment — treat as a red flag

An unqualified opinion does not mean the report has zero findings. What we always explain to clients is that it means any exceptions identified were not material enough, individually or collectively, to prevent the auditor from expressing a clean opinion. Minor exceptions are common and expected, even in unqualified reports.

What to Look For

• Confirm the opinion is unqualified — this is the baseline expectation for enterprise procurement
• Check the Trust Service Criteria covered — does the report include the criteria relevant to your requirements (Security, Availability, Confidentiality, etc.)?
• Verify the observation period — for Type II, the period should be recent (ending within the last twelve months) and sufficiently long (six to twelve months preferred)
• Note the CPA firm — is it a recognized SOC 2 audit firm? Specialized firms (Schellman, A-LIGN, KirkpatrickPrice, BARR Advisory, Coalfire, Linford & Company) and regional CPA firms with SOC 2 practices produce credible reports

Section 2: Management's Assertion

What It Contains

Management's assertion is a formal statement from the service organization's leadership asserting that:

• The system description is fairly presented
• Controls are suitably designed to meet the applicable Trust Service Criteria (Type I and Type II)
• Controls operated effectively throughout the specified period (Type II only)

What to Look For

• Signed by management — typically the CEO, CTO, or VP of Engineering
• Consistent with the auditor's opinion — the assertion should align with the scope and period of the auditor's report
• No disclaimers or limitations — management should assert without significant caveats

Management's assertion is analogous to a company's representation letter in a financial audit — it establishes management's accountability for the accuracy of the information in the report.

Section 3: System Description

What It Contains

The system description is the longest section and provides detailed context about the service organization's environment. Key components include:

Component	What It Describes	Why It Matters
Services provided	The specific services covered by the SOC 2 report	Confirms the report covers the services you use
System boundaries	The infrastructure, software, people, procedures, and data within scope	Defines what was evaluated and what was excluded
Infrastructure	Cloud providers, data centers, network architecture	Confirms appropriate infrastructure for your data
Software	Applications, databases, operating systems used to deliver the service	Identifies the technology stack and potential risk areas
People	Organizational structure, roles, and responsibilities	Shows who is responsible for security and compliance
Procedures	Key operational procedures (change management, incident response, backup)	Describes how the organization operates day-to-day
Data	Types of data processed, data flows, data storage	Confirms whether your data types are in scope
Complementary User Entity Controls (CUECs)	Controls the customer must implement for the overall control environment to be effective	Identifies your responsibilities as a customer
Complementary Subservice Organization Controls (CSOCs)	Controls performed by subservice organizations (cloud providers, data processors)	Identifies dependencies on third parties

What to Look For

• Service coverage — does the system description cover the specific service or product you use? Some organizations have multiple products but only include certain services in their SOC 2 scope
• Infrastructure alignment — is data stored in regions and on infrastructure appropriate for your requirements?
• CUECs — what controls are you expected to implement? Common CUECs include MFA configuration, access management for your users, and data encryption settings. If you do not implement the CUECs, there may be gaps in the overall control environment
• Subservice organizations — who are the critical dependencies? If the organization relies on AWS, GCP, or other subservice organizations, those organizations should have their own SOC 2 reports (carve-out method) or be included in the service organization's scope (inclusive method)
• Carve-out vs inclusive method — if subservice organizations are carved out, their controls are not tested in this report; you may need to review the subservice organization's own SOC 2 report separately

Section 4: Criteria, Controls, Tests, and Results

What It Contains

This section maps the applicable Trust Service Criteria to the service organization's specific controls and (for Type II) includes the auditor's test procedures and results:

Element	Description
Trust Service Criteria	The specific criterion being evaluated (e.g., CC6.1 — logical access security)
Control description	How the organization addresses the criterion (e.g., "MFA is required for all production system access")
Test procedure (Type II only)	What the auditor did to test the control (e.g., "Inspected MFA configuration for all in-scope systems")
Test result (Type II only)	Whether the control operated effectively or whether exceptions were identified

Understanding Exceptions

Exceptions are findings where a control did not operate as designed during the observation period. Exceptions are documented in the report regardless of their severity.

Exception Severity	What It Means	How to Evaluate
Minor / isolated	A single instance where a control did not operate as designed (e.g., one employee's access was deprovisioned two days late)	Low concern — isolated instances are common; check whether the issue was remediated
Pattern	Multiple instances of the same control failure (e.g., five of twenty-five sampled terminations had deprovisioning delays)	Medium concern — indicates a systemic weakness in the control; evaluate whether the pattern affects your data
Pervasive	Control failures across a significant portion of the observation period or across multiple control areas	High concern — may indicate fundamental program weaknesses; evaluate carefully

What to Look For

• Exception count and severity — how many exceptions were identified? Are they isolated or patterns?
• Exception areas — which control domains had exceptions? Access management exceptions are more concerning than documentation gaps
• Remediation — did the organization remediate the exceptions? Some reports note corrective actions taken during the observation period
• Controls relevant to your data — focus your review on controls that protect the data you entrust to the vendor (access controls, encryption, monitoring, incident response)

Section 5: Other Information

What It Contains

This optional section includes additional context that management wants to provide but is not part of the auditor's evaluation. Common content includes:

• Remediation plans for identified exceptions
• Future control improvements planned
• Additional certifications or compliance efforts (ISO 27001, HIPAA, etc.)
• Business context about the organization

Important Distinction

The auditor's opinion does not cover Section 5. Information in this section is management's representation only — not independently verified. We always advise clients to treat it as supplementary context, not audited evidence.

How to Evaluate a Vendor's SOC 2 Report

Evaluation Checklist

Evaluation Step	What to Check	Red Flag
1. Verify the opinion	Is the opinion unqualified?	Qualified, adverse, or disclaimer opinion
2. Check the period	Is the report current (ending within the last twelve months)?	Report period ended more than twelve months ago
3. Verify criteria	Does the report include the Trust Service Criteria you require?	Missing criteria that are relevant to your use case
4. Review system description	Does the report cover the service you use?	The specific service or product you use is not in scope
5. Review CUECs	What controls are you responsible for implementing?	Extensive CUECs that shift significant control responsibility to you
6. Review exceptions	Are exceptions minor and isolated, or systemic and concerning?	Multiple exceptions in access management or data protection
7. Check subservice organizations	Are critical dependencies (cloud providers) addressed through carve-out or inclusive method?	Critical subservice organizations not addressed at all
8. Assess relevance	Do the controls described actually protect your data in the way you need?	Controls are generic and do not address your specific data handling requirements

Common Evaluation Mistakes

Mistake	Why It Is a Problem
Only checking the opinion without reading the details	An unqualified opinion can coexist with exceptions in areas relevant to your data
Accepting a Type I report when you need Type II	Type I only assesses design, not operating effectiveness
Not reviewing CUECs	You may have control responsibilities you are not fulfilling
Ignoring the observation period dates	A report from two years ago does not reflect the current control environment
Treating SOC 2 as a binary pass/fail	SOC 2 is nuanced — the details matter more than the opinion alone
Not checking whether your specific service is in scope	Organizations with multiple products may only include certain services

Complementary User Entity Controls (CUECs)

CUECs deserve special attention because they define your responsibilities as a customer of the service organization.

Common CUECs

CUEC	Your Responsibility
Implement MFA for user accounts	Enable and enforce MFA for all users accessing the vendor's platform
Manage user access appropriately	Provision and deprovision user access according to your own access management policies
Protect authentication credentials	Ensure API keys, passwords, and tokens are securely managed
Monitor your usage	Review access logs and activity within the vendor's platform
Maintain your own security controls	Implement security controls for systems and data under your control that interact with the vendor
Report security incidents	Notify the vendor of any security incidents that may affect the shared environment

If you do not implement CUECs, there is a gap in the overall control environment — even if the vendor's controls are operating effectively. We always advise our clients that their SOC 2 report review should include an assessment of whether their organization is fulfilling the specified CUECs.

Key Takeaways

• A SOC 2 report contains five sections: auditor's opinion, management's assertion, system description, criteria/controls/tests/results, and other information
• The auditor's opinion is the most important element — an unqualified (clean) opinion means controls met the Trust Service Criteria
• What we consistently emphasize to clients is that an unqualified opinion does not mean zero exceptions — minor exceptions are common and do not prevent a clean opinion
• The system description defines what is in scope — we always advise verifying that the specific service you use is covered
• Complementary User Entity Controls (CUECs) define your responsibilities as a customer — failing to implement CUECs creates control gaps
• For Type II reports, we recommend focusing your review on the test results section for exceptions — especially exceptions in access management, data protection, and areas relevant to your data
• The report should be current (ending within the last twelve months) and the observation period should be at least six months for Type II
• Subservice organizations (cloud providers, processors) should be addressed through the carve-out or inclusive method — verify that critical dependencies have their own SOC 2 coverage
• Section 5 (Other Information) is not covered by the auditor's opinion — treat it as supplementary context, not audited evidence
• We help our clients understand that SOC 2 reports are not pass/fail — the details in the system description, control descriptions, and test results provide the context needed for informed vendor risk decisions

Frequently Asked Questions

How long is a typical SOC 2 report?

What we tell clients to expect is that SOC 2 Type I reports are typically forty to eighty pages. SOC 2 Type II reports are typically eighty to two hundred or more pages, depending on the number of Trust Service Criteria included and the complexity of the service organization. The additional length in Type II reports comes from the test procedures and results for each control. Reports covering multiple Trust Service Criteria (Security, Availability, Confidentiality, Privacy) are longer than reports covering Security alone.

Can I share a vendor's SOC 2 report with my auditor?

The guidance we give here is straightforward: SOC 2 reports are restricted-use documents, meaning they can be shared with management of the service organization, user entities (customers), and user entities' auditors. You can share a vendor's SOC 2 report with your own auditor as part of your vendor risk assessment and compliance program. You should not post the report publicly or share it with parties outside the intended audience without the vendor's permission.

What if a vendor refuses to share their SOC 2 report?

Based on what we see in our client engagements, if a vendor has a SOC 2 report but will not share it, ask whether they can share it under an NDA. Some vendors share reports only with existing customers or advanced-stage prospects. If the vendor does not have a SOC 2 report at all, request alternative evidence — security questionnaire responses, penetration test summaries, or ISO 27001 certification. The absence of a SOC 2 report is not disqualifying, but it means you will need to evaluate their security through other means.

How often should I request updated SOC 2 reports from vendors?

Our recommendation is to request updated reports annually. SOC 2 Type II reports are typically issued once per year, covering a twelve-month observation period. When a vendor issues a new report, review it for any changes — new exceptions, scope changes, or modifications to the system description. We also advise some of our clients to conduct interim vendor reviews between annual report cycles, particularly for critical vendors.

What is the difference between an exception and a qualified opinion?

What we explain to clients is that an exception is a specific finding where a control did not operate as designed. Exceptions are documented in every report where they occur, regardless of severity. A qualified opinion occurs when exceptions are material enough — individually or collectively — that the auditor cannot issue an unqualified opinion. An organization can receive an unqualified opinion with multiple minor exceptions. Qualifications are reserved for material and pervasive control failures that affect the overall control environment.