SOC 2 Report Example: What's Inside & How to Read One

SOC 2 Report Example: What's Inside & How to Read One

If you're preparing for SOC 2 compliance — or reviewing a vendor's report as part of your own due diligence — you've probably asked: what does a SOC 2 report actually look like?

SOC 2 reports follow a standardized structure set by the AICPA, but the content inside is unique to the organization being audited. What you'll see depends on the company's systems, controls, and the scope of the audit. This guide walks through a real SOC 2 report section by section, in the order it actually appears, with example language for each — so you know exactly what to expect whether you're reading one or preparing your own.

The Structure of a SOC 2 Report

A complete SOC 2 report generally includes, in this order:

1. Independent Service Auditor's Report (the Opinion)

2. Management's Assertion

3. System Description

4. Description of Tests of Controls and Results of Testing

5. Subservice Organizations

6. Complementary User Entity Controls (CUECs)

7. Restricted-use notice

We'll walk through each.

1. The Auditor's Opinion (Independent Service Auditor's Report)

This is the section most people flip to first, and it's technically the first substantive section of the report. It's where the independent audit firm states its conclusion on whether your controls were designed appropriately (Type I) and, for a Type II report, whether they also operated effectively over the audit period.

A clean, unqualified opinion typically reads something like:

"In our opinion, based on the criteria described, the controls were suitably designed and operated effectively throughout the period to provide reasonable assurance that the Trust Services Criteria were met."

If the auditor identified exceptions during testing — a missed log review, an incomplete backup restoration test — those don't necessarily block a clean opinion, but they'll be referenced here and detailed further in the testing section. A qualified opinion, by contrast, signals the auditor found a control that didn't operate effectively enough to support an unqualified conclusion — a much bigger flag for anyone evaluating the report.

2. Management's Assertion

Immediately following the opinion is Management's Assertion — the organization's own leadership formally confirming that the system description is accurate and that appropriate controls were in place to meet the relevant Trust Services Criteria.

Example language:

"We assert that our system was designed and implemented to provide reasonable assurance that the Security, Availability, and Confidentiality criteria were met during the audit period."

This section exists to show that leadership is directly accountable for the compliance program, not just delegating it to auditors and hoping for the best. Auditors are attesting to management's assertion — they didn't write the underlying claim themselves.

3. System Description

The system description gives context on the organization and exactly what was in scope for the audit. This is often the longest section of the report, and it's where a lot of the substance lives.

Example narrative:

"The XYZ Cloud Platform provides data processing services to customers in the financial services industry. The system consists of AWS-based infrastructure, a microservices architecture, and a web-based customer portal."

This section typically covers:

• The services covered by the report

• System boundaries (what's in scope, what isn't)

• Key data flows

• Infrastructure and technology used

• Critical third-party dependencies

An accurate, specific system description matters more than most people realize — auditors test controls against this description, so vague or inflated claims here create risk elsewhere in the report.

4. Description of Tests of Controls and Results of Testing

This is the core of the report, and usually the longest. For each control, you'll see the control description, what the auditor did to test it, and the result.

Under the Security criterion, for example:

"Logical access to production systems is restricted to authorized personnel using single sign-on and multi-factor authentication. User access is reviewed quarterly by the Security team."

Followed by the auditor's testing result:

"We inspected access control logs and evidence of quarterly reviews and found no exceptions during the audit period."

If an exception was found, it's disclosed plainly rather than buried:

"During Q3, one user's access was not reviewed in accordance with policy."

This is the section that gives customers real visibility into how a vendor's controls actually performed — not just what's written in a policy document. It's also where most of the substance a security reviewer cares about lives, so if you're evaluating a vendor, this is the section worth reading closely rather than skimming.

5. Subservice Organizations

Most SaaS companies rely on other vendors — AWS, GCP, a payroll processor, a customer support platform — to deliver part of their service. The Subservice Organizations section identifies these and specifies whether the report uses the inclusive method (the subservice organization's controls are tested directly as part of this audit) or the carve-out method (the subservice organization's controls are excluded, and the report relies on that vendor's own SOC 2 report instead).

Example language:

"This report uses the carve-out method with respect to Amazon Web Services (AWS). AWS's controls over the physical security and environmental protections of the underlying infrastructure are excluded from this report and are the responsibility of AWS."

This matters because it tells the reader exactly where the audit's coverage ends — and where they'd need to separately review a subservice organization's own report to get full assurance.

6. Complementary User Entity Controls (CUECs)

CUECs are controls that the audited organization assumes its own customers will implement. They're easy to miss but important — a SOC 2 report isn't a guarantee that security is fully handled on the vendor's side alone.

Example:

"User entities are responsible for maintaining appropriate access controls over their own accounts, including managing user credentials, enabling multi-factor authentication where offered, and promptly notifying [Company] of any suspected unauthorized access."

If you're evaluating a vendor's report, the CUEC section tells you what you're still responsible for on your end — it's not just a formality.

7. Restricted-Use Notice

Nearly every SOC 2 report closes with a restricted-use notice, since the report contains sensitive detail about internal controls and infrastructure. It typically limits distribution to the organization's management, customers, and their auditors — not the general public, which is part of why SOC 2 reports are usually shared under NDA rather than published openly.

A Few Practical Takeaways

• The report is narrative-driven, not a checklist. Every section is written prose describing specific systems and specific test results, not a pass/fail table.

• The language targets a professional audience — security, compliance, and procurement teams are the intended readers, which is why the writing is dense and specific rather than marketing-friendly.

• Findings are disclosed transparently, even minor ones. A report with zero exceptions ever mentioned across every control is actually less common — and less trustworthy — than one that shows a few isolated exceptions with clear remediation.

• Read the Subservice Organizations and CUEC sections, not just the opinion. These tell you where the audited company's responsibility ends and where yours begins — critical if you're evaluating a vendor rather than preparing your own report.

• Mapping your SOC 2 program to frameworks like ISO 27001 or GDPR can strengthen your overall posture and reduce duplicate audit work across standards.

If you're preparing your own report for the first time, understanding this structure ahead of the audit — rather than seeing it for the first time in a draft — makes the review process with your auditor considerably smoother.