How to Read a SOC 2 Report: A Section-by-Section Guide

A few months ago, at an ISACA event, a woman came up to me for help interpreting her organization's SOC 2 report. She had strong business acumen, but she'd been handed the vendor risk function with almost no background in how to actually read one. That conversation stuck with me, because it's a common gap. Not all SOC 2 reports are created equal. They vary by type, scope, and auditor opinion, and reading one without context can lead to misplaced confidence in a vendor that hasn't earned it.

This guide walks through what each part of a SOC 2 report is meant to tell you and how to read it with purpose. Before you get into the content, the first step is confirming you're even looking at the right report. There are different SOC report types, and they serve different purposes, cover different control domains, and are written for different audiences. Requesting the wrong one, or reading it without understanding what it can and can't tell you, means the assurance you think you're getting may not match the risk you're actually trying to cover.

Type 1 vs. Type 2: A Critical Distinction

SOC 2 reports come in two forms, Type 1 and Type 2, and the difference is frequently overlooked despite carrying real assurance implications.

• Type 1 report: assesses whether controls are suitably designed as of a specific point in time. It tells you controls exist on paper and are reasonably designed to meet the criteria, but it provides no evidence they were actually followed in practice.

• Type 2 report: assesses whether controls were suitably designed and operating effectively over a period, typically three, six, or twelve months. This is the gold standard, because it validates real-world operation over time rather than design on a single date.

What's Inside a SOC 2 Report

A complete SOC 2 report contains five sections. Knowing what each one contains, and reading them in the right order, is what turns the report from a stack of paper into something useful. The sections aren't equally important, and the order you read them in matters.

Section I: The Independent Service Auditor's Report

This is one of the most important sections in the report and should always be read first. It contains the auditor's formal opinion and serves as the foundation for everything that follows. It addresses whether the system description is fairly presented, whether the controls are suitably designed, and, for Type 2 reports, whether the controls operated effectively.

This section also tells you who prepared the report. A SOC 2 report only has value if it was prepared by an independent, licensed CPA firm, not a software platform or automated tool. SOC 2 examinations require a CPA firm to perform procedures such as inquiry, observation, examination of evidence, and reperformance. Confirm the report identifies a licensed independent CPA firm as the service auditor before you place any reliance on it.

The auditor's report also gives a high-level summary of the engagement scope and flags any issues found with the system description or controls. Pay attention to the audit period end date too. A report covering a period that ended more than six to twelve months ago may not reflect the vendor's current control environment, and you should consider whether it's still relevant for your purposes.

Sections II and III: Management's Assertion and Description of Services

Management's assertion is the service organization's own formal representation to the auditor that the system description is accurate. It exists so customers understand what the system is, how it runs, and what controls are in place to meet service commitments.

The system description is the vendor's narrative of the environment being examined. It defines the system boundary, what's in scope and what isn't, and the components that make it up. Per AICPA guidance, a complete system description is built on five components:

• Infrastructure: the physical and virtual hardware, network, cloud services, and facilities that support the system.

• Software: the applications and supporting systems in scope, often including a network diagram or data flow diagram showing how data moves through the system.

• People: the personnel, roles, and business functions involved in operating and overseeing the system.

• Procedures: an overview of the control environment, including risk assessment, monitoring, system operations, and change management.

• Data: the types of data the system processes, how it's used, and how it's shared.

Beyond those five components, the system description typically also covers the types of services in scope, the vendor's stated service commitments (data protection, uptime expectations, secure data destruction upon contract termination), any incidents during the audit period that rose to the level of a service commitment failure, and, for Type 2 reports, significant changes during the period such as new subservice organizations or major infrastructure changes. Read this section carefully to confirm the environment you're actually using falls within its boundary.

Section IV: Controls, Tests, and Results

This is the most important section in the report. It lists the controls management has identified, the testing procedures the auditor performed (Type 2 only), and the results of that testing (Type 2 only). It's organized around each applicable Trust Services Criteria, with controls mapped to the criteria they're designed to address.

This section is where the vendor communicates that its controls are in place, working as intended, and protecting data within the system. Every reader has to independently judge whether the testing performed is adequate for their own purposes and risk tolerance, since the auditor's opinion alone doesn't tell you that.

Test Result Language

Results in this section fall into one of three categories:

• No deviations or exceptions noted: the control operated as intended across all sampled instances.

• Deviations or exceptions noted: one or more instances where the control didn't operate as designed.

• No instances of occurrence: the control couldn't be tested because the triggering event didn't happen during the period, such as a disaster recovery test that wasn't scheduled in the audit window.

Complementary User Entity Controls (CUECs)

Complementary user entity controls describe what the service organization's customers need to have in place on their own end for the vendor's controls to function as intended and for service commitments to be met. They define the shared responsibility boundary between vendor and client. In practice, they're a list of what you need to be doing on your side to actually benefit from the assurance the report provides.

Complementary Subservice Organization Controls (CSOCs)

CSOCs break down which controls the service organization relies on its own subservice organizations to perform. This functions as a responsibility matrix between the vendor and the vendors it depends on, which matters if you're trying to understand the full chain of custody over your data.

Section V: Other Information Provided by the Service Organization

This section is optional and not audited. It's provided by management and reviewed by the auditor only to confirm it isn't misleading or inconsistent with the rest of the report. It commonly includes management's responses to exceptions noted in Section IV, which matter because they explain why the exception occurred, what's being done about it, and whether compensating controls are in place. It may also include a mapping to other frameworks, such as NIST CSF, HIPAA, ISO 27001, CSA STAR, or PCI DSS, to help you assess alignment with your own compliance requirements. Its absence doesn't mean the report is incomplete, but its presence can be genuinely useful.

How Clients Should Read a SOC 2 Report

For the organization receiving a vendor's SOC 2 report, reading it is a risk management activity, not a formality. It should be repeatable, documented, and built into your vendor risk program rather than a one-time skim when the file lands in your inbox.

Start with the Opinion and Verify Currency

Before reading anything else, confirm the opinion type and the audit period end date. A qualified opinion warrants deeper attention to the details behind it. A report that ended more than six to twelve months ago provides no current assurance and needs either a renewal report or a bridge letter covering the gap.

Match the Scope to Your Risk

Confirm the Trust Services Criteria in scope actually align with your engagement with the vendor. A vendor storing and processing your customer data should have Confidentiality in scope. A vendor supporting a high-availability application should have Availability. A vendor processing personal data of EU residents may need Privacy in scope. If the report's scope doesn't address your actual risk exposure, the assurance it provides is incomplete no matter how clean the opinion looks.

Read the System Description to Confirm Applicability

Verify that the services you're using and the data you're sharing actually fall within the system description boundary. Check the five components, infrastructure, software, people, procedures, and data, against what you know about the vendor's operations. Look for the network diagram or data flow diagram to assess data handling and third-party dependencies at a glance.

Also check the incidents section. If a security event during the audit period resulted in a failure to meet service commitments, this disclosure tells you what happened and how it was addressed. You'll still need to independently decide whether that incident changes your assessment of the vendor.

Evaluate Testing Methodology in Section IV

Don't stop at whether exceptions were noted, look at how the controls were tested. In a SOC 2 engagement, auditors should be doing more than asking questions. Substantive testing through observation, examination of evidence, and sampling is expected for key controls.

When exceptions do show up, work through them deliberately: Is the excepted control relevant to your data or the services you're consuming? Is it an isolated instance or does it reflect a recurring failure? What does management say in Section V, and is there a credible remediation plan? Were compensating controls identified that partially close the gap? A report with a well-documented exception and a solid remediation plan can tell you more about a vendor's maturity than a report with no exceptions at all.

Getting More Out of Every Report You Read

A SOC 2 report is only as useful as the read you give it. Skimming to the opinion letter and calling it done skips most of the information the report was built to provide. At Compass, we work with organizations on both sides of this, helping vendors prepare reports that hold up to real scrutiny, and helping clients build a vendor risk process that gets real value out of every report they collect.

If you need help interpreting a vendor's SOC 2 report, or building a repeatable process for your own vendor risk reviews, contact us and we'll help you get there.