A SOC 2 Type 2 report is the artifact that closes enterprise deals. It is also a 40 to 100 page document most readers have never seen the inside of. This guide walks through the report section by section with illustrative excerpts, explains the four opinion types, and shows the red flags buyers should look for before they trust a vendor's controls.
If you are planning your own Type 2 audit rather than reading someone else's report, start with the SOC 2 Type 2 playbook.
A note on excerpts. The excerpts in this guide are illustrative, written to mirror standard AICPA report language. Real reports follow this structure but use the specific language of the issuing CPA firm and the audited company. Use these examples to learn what to look for, not as templates for your own report.
The five sections at a glance
Every SOC 2 Type 2 report is structured around the same five sections. The order and naming come from AICPA guidance.
Sections I and IV are written by the auditor. Sections II, III, and V are written by the company being audited. That distinction matters when you read each section.
Section I: Independent Service Auditor's Report
This is the section enterprise procurement reads first. It contains the auditor's opinion on whether your controls were suitably designed and operated effectively across the observation window.
Illustrative excerpt
Illustrative; based on standard AICPA SSAE 18 language.
Independent Service Auditor's Report
To the management of [Company]:
Scope. We have examined [Company]'s description of its [System Name] system throughout the period January 1, 2026 to June 30, 2026, and the suitability of the design and operating effectiveness of controls included in the description to provide reasonable assurance that [Company]'s service commitments and system requirements were achieved based on the trust services criteria for security set forth in TSP section 100A.
Opinion. In our opinion, in all material respects:
a. The description presents [Company]'s [System Name] system that was designed and implemented throughout the period January 1, 2026 to June 30, 2026, in accordance with the description criteria.
b. The controls stated in the description were suitably designed throughout the period to provide reasonable assurance that [Company]'s service commitments and system requirements would be achieved based on the applicable trust services criteria, if its controls operated effectively throughout that period.
c. The controls operated effectively throughout the period to provide reasonable assurance that [Company]'s service commitments and system requirements were achieved based on the applicable trust services criteria.
How to read it
- The observation window dates tell you when the controls were tested. A report dated today with a window ending six months ago means six months of unaudited operations have passed.
- The phrase "in all material respects" combined with all three (a)(b)(c) clauses is what an Unqualified Opinion looks like.
- If the opinion paragraph contains "except for" anywhere, you are reading a Qualified Opinion. Stop and read the basis for qualification before anything else.
The four opinion types
Most SOC 2 Type 2 reports you will encounter from established vendors are Unqualified. Qualified Opinions are not unusual for first-time audits and do not automatically disqualify a vendor; the question is whether the qualification is about something that affects your use case.
Section II: Management Assertion
This is the company's formal claim about its own controls. The auditor's opinion in Section I is an opinion on Section II.
Illustrative excerpt
Illustrative.
Assertion of [Company] Management
We have prepared the accompanying description of the [System Name] system based on the description criteria and the trust services criteria for security. The description is intended to provide report users with information about the [System Name] system that may be useful when assessing the risks arising from interactions with our system.
We confirm, to the best of our knowledge and belief, that:
a. The description presents the [System Name] system that was designed and implemented throughout the period January 1, 2026 to June 30, 2026.
b. The controls stated in the description were suitably designed throughout the period.
c. The controls operated effectively throughout the period.
How to read it
This section is short. Its main function is to put the company on record. If you are evaluating a vendor, you are reading this to understand what the company is committing to. The scope statements here ("the [System Name] system") should match what you need from the vendor. If the assertion is about a product line you are not using, or excludes the environment your data sits in, the report is not covering what you think it is covering.
Section III: Description of the System
This is the longest section, often 15 to 40 pages. It is the company's narrative description of what was audited. Buyers skim this and miss critical scope decisions.
What it covers
- Services in scope. Which products, modules, or environments. Verify this matches what you are buying.
- Infrastructure. Cloud providers, data centers, key software components.
- People. Functional groups responsible for the system.
- Procedures. How the company onboards customers, handles incidents, deploys changes, manages access, and so on.
- Data. What customer data flows through the system and how it is classified.
- Subservice organizations. Cloud providers and other vendors whose controls are relied upon (more on this below).
- Trust Services Criteria. Which were included (Security is mandatory; Availability, Confidentiality, Processing Integrity, Privacy are optional).
Illustrative excerpt: scope statement
Illustrative.
The scope of this report covers the [Product Name] platform, which provides [brief description of service]. This includes the production environment hosted on Amazon Web Services in the us-east-1 and us-west-2 regions, the customer-facing web application, the API gateway, and the data ingestion pipeline. The scope excludes [Product Name]'s development and staging environments, internal corporate IT systems unrelated to the production service, and the [Adjacent Product] platform, which is covered under a separate SOC 2 report.
How to read it
- Look for what is excluded. A vendor's "SOC 2 Type 2 report" can have a narrow scope. If your data flows through a system the report does not cover, the report does not protect you.
- Look for the criteria included. Many reports cover only Security. If your contract requires Availability or Confidentiality controls, the report should include those criteria. If it does not, ask why.
Subservice organizations: CSOCs
When the audited company relies on another vendor (typically the cloud provider), the report has to address how that reliance is handled. This is done either through the inclusive method (the subservice provider's controls are tested as part of this audit, rare) or the carve-out method (the subservice provider's controls are excluded from this audit and their own SOC 2 report is referenced).
If carve-out is used, the report will list Complementary Subservice Organization Controls (CSOCs): controls the subservice provider is expected to be operating. These read like:
Illustrative.
The Company assumes that the subservice organization (Amazon Web Services) maintains physical security controls over its data centers, restricting physical access to authorized personnel only. The Company does not test these controls as part of this examination and relies on AWS's own SOC 2 report dated [date] for assurance over these controls.
For your evaluation: if a vendor's report carves out the cloud provider, you should also have access to the cloud provider's SOC 2 report (publicly available for AWS, GCP, Azure). Otherwise there is a gap in your assurance chain.
User entity controls: CUECs
The report will also list Complementary User Entity Controls (CUECs): controls that the customer (you) must operate for the audited company's controls to be effective. These read like:
Illustrative.
User entities are responsible for managing the credentials they use to access the [Product Name] platform, including enforcing strong password policies and enabling multi-factor authentication for their administrative users.
For your evaluation: a long CUEC list means more responsibility shifts to you. For your own audit (if you are the audited company), CUECs are a defensible way to scope out controls that legitimately belong to your customers, but every CUEC you add narrows what the report claims for you.
Section IV: Tests of Controls and Results
This is where the auditor lists every control in scope, the test performed, and the result. It is typically a multi-page table. This is the section that distinguishes Type 2 from Type 1; in a Type 1 report this section does not exist.
Illustrative excerpt: a single control row
Illustrative.
How to read it
- Sample size and population. Auditors sample. The "25 of 142" pattern is normal. A sample size of 1 across a 6-month window is not.
- The Result column. "No exceptions noted" is what you want to see across the table. "Exception noted" is the line that matters.
- Reading exceptions. Every exception will have a description and, ideally, a management response describing remediation. An exception that has been remediated is materially different from one that has not.
Illustrative excerpt: a control with an exception
Illustrative.
For your evaluation: a single offboarding exception out of 12 with a documented remediation is materially less concerning than five offboarding exceptions with no remediation. Look at both the rate and the response.
Isolated minor exception vs systemic failure
Not all exceptions carry the same weight. The same word in the report ("Exception noted") can mean a one-off slip or a structural problem. The distinction is what changes a deal outcome.
For audited companies preparing your own report: anticipating which bucket your exceptions fall into lets you write the management response before procurement asks. For buyers: read the management response and the underlying pattern. A great response to a systemic failure is still a systemic failure.
Section V: Other Information
Section V is optional and not audited. Companies use it for context: their incident response narrative for an incident that happened during the window, additional security program detail, or commentary on the report.
How to read it: with appropriate skepticism. The auditor did not test anything in Section V. It is the company speaking to the reader directly. Useful for context, not for assurance.
Red flags buyers should look for
Run this checklist on any Type 2 report you are evaluating from a vendor.
- Stale window. Report's observation window ends more than 12 months ago and there is no bridge letter pointing to a new audit. The report is no longer current.
- Missing criteria. Your contract or use case requires Availability, Confidentiality, or Privacy controls and the report only covers Security.
- Scope exclusions that matter. The product or environment your data sits in is explicitly excluded from scope.
- Qualified Opinion in your area. A qualification on access controls is more concerning than a qualification on physical security if you are a SaaS buyer.
- Sample sizes that look perfunctory. A 6-month observation window with sample sizes of 1 or 2 across critical controls suggests light testing.
- Long CUEC list shifting responsibility. The report puts substantial responsibility on you that you were not expecting.
- Carve-out cloud provider with no reference report. The vendor relies on AWS / GCP / Azure but the report does not state that you can obtain the subservice provider's own SOC 2.
- No management response to exceptions. Exceptions exist but the company has not documented remediation.
How to use your own report in sales conversations
If you are the audited company and you are sharing the report with a prospect, do three things.
- Lead with Section I. Send the opinion paragraph excerpt in the deal communication, not the full PDF first. Most procurement reviewers want to confirm the Unqualified Opinion before they spend an hour on Section III.
- Anticipate Section IV questions. If your report has any exceptions, prepare a one-paragraph remediation note. Procurement will ask. Volunteering the answer accelerates the deal.
- Pair with a bridge letter once the report is past 90 days. Aging reports trigger renegotiation. A bridge letter pre-empts the question. See the bridge letter guide.
How SecureLeap Can Fast-Track Your Compliance Journey
SecureLeap provides cybersecurity compliance consulting tailored for fast-moving startups. We act as your dedicated internal security team, handling the heavy lifting of compliance so you can focus on growth and closing enterprise deals. Whether you are facing a strict deadline for a vendor security questionnaire or building a long-term security posture, we ensure you are audit-ready without the chaos.
Here is how we partner with you:
- SOC 2 Consulting: We scope your boundaries, identify gaps, and implement sustainable controls before the auditor arrives. We help you avoid the expensive delays companies face when they skip proper readiness planning.
- Expert Penetration Testing: We conduct manual, expert-led testing (Web, Mobile, API, or Cloud) designed to uncover real-world vulnerabilities, strengthen your systems, and satisfy strict enterprise procurement requirements.
- Compliance Automation Support: If you use platforms like Vanta, Drata, or Secureframe, we map your controls and configure continuous evidence collection so your data is always audit-ready. (Ask us about our 20% partner discount).
- Audit Facilitation: We handle the auditor relationship from start to finish. We schedule walkthroughs, compile evidence packages, and translate auditor-speak into clear engineering tasks so your team isn't distracted.
- Virtual CISO (vCISO): For companies without a dedicated security leader, our vCISO service delivers senior-level strategy, manages your compliance roadmap, and sits on calls with your enterprise prospects when you need executive backup.
👉 Book a Free Consultation and get a personalized compliance roadmap tailored to your business, budget, and timeline.
FAQ
Where can I see a real SOC 2 Type 2 report sample?
Real reports are typically NDA-protected. The excerpts in this guide are illustrative and follow AICPA standard structure, which is what every real report uses. The fastest way to see a real one is to request one from a vendor you are evaluating, under NDA, after they qualify the deal.
What is the difference between Section III and Section IV?
Section III is the company's narrative description of the system, written by the company. Section IV is the auditor's testing of each control, written by the auditor. Section III tells you what was audited; Section IV tells you whether each control passed.
Can I share a SOC 2 Type 2 report publicly?
No. Reports are typically distributed under NDA to current and prospective customers and are not made publicly available. SOC 3 reports, which are derived from SOC 2 audits and contain less detail, are designed for public distribution.
How is "operating effectiveness" actually tested?
Through sampling. The auditor selects a subset of times the control should have run across the observation window (a subset of access reviews, a subset of change tickets, a subset of vulnerability scans), inspects evidence for each, and notes exceptions. Sample sizes vary by control frequency and risk.
What does "Trust Services Criteria" actually mean in the report?
The Trust Services Criteria are the AICPA framework against which controls are evaluated. Security (Common Criteria) is required; Availability, Confidentiality, Processing Integrity, and Privacy are optional. The criteria included in scope are listed in Section III and tested in Section IV. For more, see the SOC 2 compliance guide.
%20(10)%20(1).png)
%20(4)%20(1).avif)
%20(3)%20(1).avif)