SOC 2 Report Example 

Most teams lose 12 weeks every year to compliance tasks, often because their reports lack the “real-world” evidence auditors now require. In 2025, your SOC 2 report must be more than a checkbox; it must be a narrative of verified trust.

Using the example below, we illustrate how to document penetration testing and human-led validation to satisfy modern audit requirements and protect your firm from the rising costs of data breaches.

What Is a SOC 2 Report?

A SOC 2 report is a formal review written by an independent CPA. It explains whether a company has the right security and operational controls in place to protect customer data and run its systems reliably. The CPA looks at how those controls are set up and, in some cases, how well they work in real day-to-day operations.

There are two types of SOC 2 reports:

• Type 1: Shows whether the company’s controls are properly designed at a specific moment in time. It describes what controls exist but does not test how they perform over time. You can think of it as a snapshot.
• Type 2: Reviews controls over a longer period, usually 6 to 12 months. It confirms that the controls were not only well designed but also worked effectively in practice. This report includes the auditor’s testing steps, results, and any issues found.

SOC 2 Report Structure 

Although the exact layout varies slightly between auditors, most SOC 2 reports follow a standard structure with five sections. The summary below reflects common guidance: 

1. Independent Auditor’s Report

This section presents the independent auditor’s opinion and explains whether the company’s controls satisfied the selected SOC 2 criteria. The opinion can confirm the controls met requirements, note exceptions, identify significant deficiencies, or state that evidence was insufficient to form a conclusion. It also describes the audit scope and general approach.

2. Management’s Assertion

This section provides a formal statement from management confirming the system description is fairly presented and that controls were designed appropriately. In a Type 2 report, management also asserts the controls operated effectively throughout the audit period. It typically summarizes the services in scope, the systems involved, and any criteria not fully satisfied.

3. System Description

This section explains what was audited and how the organization operates. It describes the services provided, key commitments such as availability or uptime, and primary system components, including infrastructure, software, people, processes, and data. It may also cover significant incidents, material changes during the audit period, relevant third-party services, and customer-operated controls.

4. Controls, Criteria, and Test Results

This section documents control performance and links each control to the applicable Trust Services Criteria. It lists the controls, explains the criteria each supports, and describes the auditor’s testing procedures. In a Type 1 report, it generally lists the controls without operating effectiveness results. In a Type 2 report, it includes test details, results, and exceptions, which makes this section central for assessing risk.

5. Information or Appendices

This optional section adds management context and supporting detail. It may describe remediation plans, future improvements, risk management or business continuity activities, and additional information about vendors and third-party dependencies.

SOC 2 Report Example

As a fintech business, ABC Company depends on protecting customer data and maintaining reliable systems. Its SOC 2 report documents how the company’s controls align to the AICPA Trust Services Criteria, which cover areas such as security, availability, processing integrity, confidentiality, and privacy.

SOC 2 reports often exceed 100 pages. Instead of walking through every exhibit, the overview below focuses on the sections readers use most and the details that tend to drive vendor and customer decisions.

Section I: Independent Auditor’s Report

This is typically the most referenced section. The auditor summarizes the engagement, identifies the period under examination, and provides a high-level description of the system in scope.

Below is an excerpt taken from an example SOC 2 system description:

A SOC 2 system description snippet usually gives readers a clear snapshot of ABC Company’s environment, such as core infrastructure, key applications, data flows, and relevant service providers. After the system description, the auditor outlines:

• Auditor’s responsibilities (what the auditor did and the standards followed)
• Management’s responsibilities (what the company is accountable for)
• Inherent limitations of the examination (what a SOC 2 report does and does not prove)
• The auditor’s opinion (the conclusion decision-makers look for first)

The auditor’s opinion is the headline result. In this example, the report states that ABC Company’s controls operated effectively throughout the examination period. That language indicates the auditor issued a clean opinion for the in-scope criteria and period. 

Even with a positive opinion, the report can still surface items worth attention elsewhere, such as minor exceptions, complementary user entity controls, or recommended improvements that do not rise to the level of a qualification.

Section II: Management’s Assertion

Section II of a SOC 2 report is Management’s Assertion, which is a signed statement where company leadership takes responsibility for the system included in the report and states that the system description and related controls meet the applicable Trust Services Criteria for the stated time period.

This section is usually short, but it serves as the company’s formal accountability statement and sets the boundaries for what the auditor reviews. Management confirms that the SOC 2 examination focuses on controls tied to one or more trust services categories, such as security, availability, processing integrity, confidentiality, and privacy.

A typical management assertion includes the following elements.

• Management states that it prepared the system description for the defined scope and time period covered in the report.
• Management states that the system description is fairly presented, meaning it accurately explains how the system works and how controls support the stated commitments and requirements.
• Management states that the controls are suitably designed to meet the applicable criteria, meaning the controls should achieve their objectives if they operate as described.
• For a Type II report, management states that the controls worked effectively throughout the entire examination period, reflecting the SOC 2 focus on performance over time.

In practice, reviewers treat Management’s Assertion as the company’s signed confirmation that the scope, time period, and criteria are correct, then compare that claim to the system description and audit test results, since issues often appear as missing scope details, unclear boundaries, or controls that do not fully support the selected criteria.

Section III: System Description

Section III of a SOC 2 report is the System Description, which is a management written explanation of the services in scope, the system boundaries, and how information moves through the environment during the review period.

This section is usually the longest part of the report and gives readers practical detail about how the organization operates. It often includes background on the company, the services it provides, key processes, and visual diagrams. The System Description helps report users understand how data is handled and how controls and procedures address risks related to the company’s stated commitments and requirements.

The AICPA allows organizations to present this section in different formats as long as the required disclosures are included and follow DC Section 200.

A System Description commonly covers the following areas.

• The types of services provided and how customers use those services.
• The main service commitments and system requirements that determine which trust services categories apply.
• The system components, including infrastructure, software, people, procedures, and data.
• The system boundaries, including key third parties and subservice organizations, and whether they follow an inclusive or carve out approach.
• High level control themes related to the applicable trust services criteria, including how management approaches risk and control operation.
• Any significant system incidents that meet disclosure requirements, including what happened, when it occurred, the impact, and how it was addressed.
• Complementary user entity controls, which explain what customers are expected to do for the overall control structure to function as intended.

Section IV: Trust Services Criteria, Related Controls, Tests of Controls, and Results

Section IV of a SOC 2 report is the main testing section where the auditor lists the controls in scope, explains how each control was tested against the applicable Trust Services Criteria, and records the results for the examination period.

This section is where readers find evidence, not high level summaries, because it ties each criterion to specific controls and shows whether those controls worked as intended during the period. Many SOC 2 reports present Section IV as tables, sometimes called a testing matrix, that show the controls tested, what the auditor did to test them, when the testing occurred, and what the auditor found.

Section IV commonly includes the following elements.

• The trust services categories and criteria in scope, often shown as criterion identifiers mapped to related controls.
• The service organization’s control statements, usually listed with control numbers and control descriptions.
• For a Type II report, the auditor’s test procedures for operating effectiveness and the test results for each control.
• The key Type I versus Type II difference, where Type I lists controls without test results and Type II includes both controls and testing results for the period.
• A table format that often includes columns such as control number, control description, test of effectiveness, test result, and applicable trust services criteria.

When reviewing Section IV, reviewers usually start with controls that show exceptions or failures, then trace each issue back to the related criteria and control objective to understand the impact, since an overall clean opinion can still include isolated exceptions that matter for a specific customer situation.

Section V: Other Information Provided by the Service Organization

Section V of a SOC 2 report is an optional, unaudited section where management shares additional information that sits outside the auditor’s formal opinion and testing.

This section gives helpful context but does not serve as audit evidence because the auditor does not test or opine on its content. Auditors still read it to check for major inconsistencies with the audited sections, but responsibility for the information rests entirely with management.

Section V commonly includes the following types of information.

• Management explanations for control exceptions or deviations, including what occurred, what corrective actions were taken, and any follow up work that is planned.
• Operational updates management wants readers to understand, such as backup and recovery activities, system changes, or major technology updates.
• Information useful to customers but outside the audit scope, including services not covered in the report, future system plans, events that occurred after the report period, service level performance summaries, or mappings to other frameworks.
• Guidance for readers to treat this section as informational only, since it is not audited and the auditor does not provide an opinion on it, even though it is reviewed for consistency under attestation standards.

Bright Defense Offers SOC 2 Services

Bright Defense helps organizations prepare for SOC 2 audits through a clear, audit focused engagement that stays practical and aligned with assessor expectations. We support SOC 2 readiness assessments, gap analysis, and control design across the Trust Services Criteria, including security, availability, and confidentiality. Our team documents policies, implements controls, and organizes audit evidence so the audit trail remains complete and defensible. Whether an organization is pursuing SOC 2 Type I or SOC 2 Type II, Bright Defense reduces audit friction and builds confidence ahead of assessment timelines.

Frequently Asked Questions Regarding SOC 2 Examples