If you’re responsible for vendor security, you’ve probably received a lot of SOC 2 reports.
You’ve also probably noticed that most people, including most people in vendor review processes, treat the SOC 2 certificate as the whole story. Certificate present, box checked, review complete.
This approach misses most of what a SOC 2 report actually contains.
A SOC 2 report is a detailed document. The certificate on the cover page tells you an audit happened. The rest of the report tells you what the audit actually found, and that’s where the useful information lives.
Here’s how to read a SOC 2 report properly.
What Is a SOC 2 Report and What Are Its Types?
SOC 2 is a third-party audit of a service organization’s controls, conducted against the AICPA’s Trust Services Criteria. It covers five potential criteria: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy.
Two types:
- Type I : Assesses whether controls are suitably designed at a point in time.
- Type II : Assesses whether controls were operating effectively over a defined period, typically 6 to 12 months.
For vendor security purposes, Type II is significantly more meaningful. Type I tells you controls exist. Type II tells you they actually worked.
A SOC 2 report covers a specific scope, a specific time period, and specific criteria. Understanding all three is essential before you interpret anything else in the report.
Section 1: The Independent Auditor’s Report
This is what most people read: the auditor’s opinion on whether the vendor’s controls meet the relevant Trust Services Criteria.
What to look for:
Opinion type. An unqualified opinion (“in our opinion…”) means the auditor found controls suitably designed and operating effectively. Any qualified language, such as “except for” or “subject to,” signals exceptions you need to understand.
Periods are covered. When did the audit period start and end? A report with a period ending eight months ago tells you considerably less about today’s posture than one from last quarter.
Criteria covered. Which Trust Services Criteria are included? Security is always in scope. Availability, confidentiality, and privacy may or may not be, depending on what the vendor elected to include.
Section 2: Management’s Description of the System
This is the section most people skip. It’s also one of the most important things.
The system description is written by the vendor. It describes what is included in the scope of the audit, not what the company does overall, but specifically what was included in the audit.
Common issues to look for:
- Scope exclusions. The description may explicitly exclude certain products, environments, or data types from the audit scope. If the service you’re using, or the data environment relevant to you, is excluded, the SOC 2 certification doesn’t apply to your use case.
- Infrastructure inclusions. Does the description include the cloud infrastructure the vendor runs on? If they use AWS or Azure, are those environments included or excluded?
- Subservice organizations. This section should identify third-party organizations whose services are part of the vendor’s system. Understand who they are and whether they’re carved out or included.
Read this section carefully. It defines the actual meaning of the certification that follows.
Section 3: Complementary User Entity Controls
This section is almost universally skipped. It’s also critically important.
Complementary User Entity Controls, known as CUECs, are controls that the SOC 2 report assumes you, the customer, are implementing. The vendor’s audit opinion is only valid if these controls are in place on your side.
Common CUECs include:
- You are responsible for managing user access and terminating access when employees leave
- You are responsible for encrypting data in transit between your environment and the vendor’s
- You are responsible for notifying the vendor of relevant incidents on your side
If your organization isn’t implementing the CUECs listed in a vendor’s SOC 2, the assurance the report provides is partially undermined. The audit tested the vendor’s side of the control environment. Your side was assumed.
This section is worth reading every time.
Section 4: Control Exceptions in SOC 2 Reports
This is the section that contains the most actionable information, and the one that requires the most careful reading.
When a control doesn’t operate effectively during the audit period, the auditor documents an exception. Exceptions are not automatically disqualified. Auditors expect to find some, and a report with exceptions and documented remediation can actually demonstrate more transparency than one with no exceptions at all.
What to look for:
Nature of the exception. Is it a process of failure (a control wasn’t followed consistently), a design gap (a control wasn’t designed to catch a specific risk), or a technical failure (a system didn’t behave as intended)?
Frequency. A control that failed once is different from a control that failed 30 times.
Remediation. Has the vendor acknowledged the exception and documented what they’ve done to fix it? An exception with clear remediation is materially different from one that’s acknowledged without a response.
Relevance to your use case. Not every exception affects every customer. An exception in a data center physical access control matters differently if your vendor hosts your data there versus if your integration is purely API-based.
Section 5: The Controls Testing Results
The main body of a SOC 2 report is a control-by-control breakdown: what each control is, how the auditor tested it, and whether it was found effective.
You don’t need to read every line of this section for every vendor. But for critical vendors, and for controls most relevant to your use case, it’s worth reviewing.
Useful things to look for:
- Controls that are “not tested” or “not applicable.” If a control area that matters to you, such as encryption, access management, or incident response, has controls that weren’t tested, understand why.
- Testing methods. Some controls are tested by inquiry only (the auditor asked the vendor and took their word for it). Others are tested by inspection (the auditor looked at actual documentation or systems) or by observation (the auditor watched a process happen). Inquiry-only testing provides less assurance than inspection or observation.
- Consistency between the system description and the testing results. If the system description claims a control exists that doesn’t appear in the testing results, that’s worth understanding.
What a SOC 2 Report Can’t Tell You
Even a well-reviewed SOC 2 has inherent limitations worth keeping in mind.
It’s historical. The audit period ended on a specific date. What happened after that date, including new vulnerabilities, infrastructure changes, personnel changes, and incidents, isn’t reflected.
It’s scoped. What’s outside the scope isn’t covered. The certification says nothing about the parts of the vendor’s environment that weren’t included.
It’s periodic. A SOC 2 audit happens once a year. Controls that were effective during the audit period may not be effective today.
It’s self-described. The system description is written by the vendor, not the auditor. The auditor tests the controls. They don’t independently verify everything the vendor says about their own environment.
A SOC 2 report is one of the best tools available for vendor security assessment. It’s also a starting point, not the end of the conversation.
How to Use This in Practice
For critical vendors, a structured SOC 2 review should cover:
- Confirm it’s a Type II report covering the Security criterion
- Check when the audit period ends. Is it current?
- Read the system description. Is your use case in scope?
- Read the CUECs. What are you assumed to be doing on your side?
- Scan the exception section. Are there any material exceptions relevant to your use case?
- For key control areas including access management, encryption, and incident response, review the testing results
This takes time. For high-risk vendors, it’s worth the time. For lower-risk vendors, a lighter review covering period, opinion, and major exceptions may be proportionate.
The goal isn’t to become an SOC expert. It’s to get meaningful signal from a document that most vendor security processes treat as a box to check.
Frequently Asked Questions About SOC 2 Reports
What is a SOC 2 report? A SOC 2 report is a third-party audit of a service organization’s security controls, conducted against the AICPA’s Trust Services Criteria. It documents whether the organization’s controls are suitably designed and, for Type II reports, whether those controls operate effectively over a defined audit period.
What is the difference between SOC 2 Type I and Type II? SOC 2 Type I assess whether controls are suitably designed at a point in time. SOC 2 Type II assesses whether those controls operate effectively over a period of typically 6 to 12 months. For vendor security assessment purposes, Type II provides significantly more assurance.
What are Complementary User Entity Controls (CUECs)? CUECs are controls listed in a SOC 2 report that the customer, not the vendor, is assumed to be implementing. The vendor’s audit opinion is only fully valid if these controls are in place on the customer’s side. Common CUECs cover access management, data encryption, and incident notification responsibilities.
What does it mean if a SOC 2 has exceptions? Exceptions mean a control didn’t operate as intended during the audit period. They are not automatically disqualified. What matters is the nature of the exception, how frequently it occurred, and whether the vendor has documented remediation. A report with clear exceptions and responses can demonstrate more transparency than one with none.
How current does a SOC 2 report need to be? Generally, a SOC 2 report should cover an audit period that ended no more than 12 months ago. Reports older than that may not reflect the vendor’s current security posture, particularly if significant changes have occurred in their environment.
At 3rdComply, SOC 2 review is part of every vendor assessment we conduct. We read the report, not just the certificate, and surface the findings that matter for your specific use case. If you'd like to understand what a vendor SOC 2 actually says about your exposure, that's a conversation we're good at.