How to Read a SOC 2 Report: The Gaps Tell You More Than the Controls

Learning how to read a SOC 2 report is less about checking what is covered and more about identifying what is not. Most vendor risk teams accept a clean audit as evidence of security. It is not. It is evidence that the vendor met the controls they defined for themselves, and the controls they did not define are exactly where the real risk lives. This guide walks through the specific gaps that matter most.

Key Takeaways

• A clean SOC 2 audit means the vendor passed the controls they chose to include, not that they are comprehensively secure

• Scope decisions (what is included and what is carved out) often reveal more about security posture than the controls themselves

• Five criteria areas (CC6.1, CC7.1, CC9.2, subservice carve-outs, exception logs) are most commonly gapped or scoped narrowly

• Zero exceptions in a SOC 2 report is a red flag, not a green one

• SOC 2 is a starting point for vendor due diligence, not an endpoint. The conversation it opens matters more than the document itself

Why the Pass/Fail Model Broke Down

System and Organization Controls 2 (SOC 2) was built around a principle of flexibility. Organizations define control objectives within the Trust Services Criteria (TSC), an external auditor verifies whether those objectives were met, and the resulting report is a statement of what was evaluated and whether the organization passed.

That flexibility is also how the framework gets gamed.

There is no external body that mandates what must be in scope. A company with a privileged access management gap can define its CC6.1 criteria narrowly enough that the gap does not appear. A company with unmonitored production environments can write CC7.1 language that covers only "selected systems." An audit firm comes in, verifies the evidence, and issues a clean opinion, because the controls were met, exactly as defined.

Qualified opinions, where an auditor flags something that was not done, are rare in practice. Not because organizations are universally secure, but because organizations have learned to scope around their weaknesses. The market penalizes a qualified opinion harshly; the result is that companies optimize for scope management rather than security maturity.

A decade ago, having a SOC 2 at all was a meaningful signal. Few companies had one, and the investment required to obtain one implied a real security program. Today a five-person startup can get a clean SOC 2 in a few months. The credential is now table stakes, which means the signal has migrated entirely to what is not in the report.

Five Gaps That Signal a Scoped-Out Program

Knowing how to read a SOC 2 report for gaps requires knowing the TSC well enough to notice when something is conspicuously absent. These five areas are where scope decisions most commonly hide real risk.

CC6.1: Logical Access Controls

CC6.1 governs the logical access security controls an organization implements over protected information assets. In practice, this is where multi-factor authentication (MFA) enforcement, privileged access management (PAM), and just-in-time (JIT) access patterns should appear.

When a CC6.1 section makes no mention of privileged credential management, administrative access workflows, or MFA enforcement specifics, that section was probably scoped to exclude them. The criteria is present because it is required, but the coverage is surface-level.

The follow-up question to ask a vendor: how are privileged accounts provisioned and deprovisioned, what approval workflow governs administrative access, and who reviews it? If the answer requires significant explanation that is absent from the SOC 2, you know where the gap lives.

CC7.1 and CC7.2: System Monitoring and Anomaly Detection

CC7.1 covers detection procedures for identifying configuration changes that introduce new vulnerabilities. CC7.2 covers ongoing monitoring for anomalies that could indicate malicious activity or errors.

Both criteria are frequently satisfied at a level of abstraction that hides the actual monitoring scope. Look at how "the entity's systems" are defined in the report. If the scope description is vague or references a subset of the production environment, the monitoring coverage may describe a carefully selected environment rather than the full stack.

This becomes especially important when the vendor's core infrastructure runs on a cloud provider that is handled via carve-out. More on that below.

CC9.2: Vendor and Third-Party Risk

CC9.2 covers how an organization manages risks associated with its own vendors and business partners. A company with an extensive third-party vendor chain and a shallow CC9.2 section is acknowledging a risk surface without actually accounting for it.

Look for specifics: 

• How frequently are sub-vendors assessed?

• What is the criteria for re-assessment when a sub-vendor's posture changes?

• What happens when a sub-vendor fails to meet requirements? 

Vague language about "periodic assessments" or "contractual requirements" without evidence of how those are enforced is a signal that vendor risk management is documented but not operational.

The Subservice Organization Carve-Out

One of the most consequential scoping decisions in a SOC 2 report is how subservice organizations are handled. The AICPA allows two methods: the inclusive method, where the service auditor's scope extends to controls at the subservice organization, and the carve-out method, where it does not.

Carve-out is standard practice because it simplifies audit production. But it creates a meaningful assurance gap: if a vendor runs on Amazon Web Services (AWS) and AWS is carved out, the audit does not cover the infrastructure layer. The organization is responsible for controls above the cloud layer, but the layer itself (networking, compute, storage, physical security) sits outside the scope of the report you are reviewing.

This does not mean the vendor is insecure. AWS, Azure, and other major providers publish their own SOC 2 reports, and a thorough vendor risk review should include those alongside the vendor's own report. But it does mean the clean SOC 2 on your desk is not a statement about the full technology stack. Know where the scope boundary is, and evaluate what sits below it.

The Exception Log

A SOC 2 report with no exceptions, no qualifications, and no noted deviations is often more concerning than one with a few documented issues. Real security programs surface exceptions. Access reviews find accounts that were not deprovisioned on time. Change management tickets get filed a day late. Monitoring rules generate false positives that require manual review and documentation.

When a program is operating honestly and continuously, these surface in the report. When a program is scoped and evidenced carefully ahead of the audit window, they often do not appear, because the evidence was collected for a period where everything looked clean.

A single well-documented exception, with a root cause, remediation action, and timeline, is better evidence of a mature security program than 100 pages of unqualified controls. If you are reviewing a report with a zero-exception log, ask the vendor how exceptions are tracked internally and what the process is when a control deviation is found.

Why Rippling Automated Compliance is the Ideal Tool for SOC 2

Most SOC 2 tools track compliance after the fact. They sit on top of your stack, read data through integrations, and surface what your auditor is going to flag. The evidence is always downstream of the actual controls.

Rippling runs the systems SOC 2 depends on. Your people, devices, access, and training data are native to Rippling, which means compliance evidence is generated by the same systems that run your daily operations, not collected through integrations that silently drift and break two months before your audit window opens. Evidence is always current, always traceable to its source, and always auditor-ready without a manual export.

For the specific gaps this post covers, that changes what a compliance program looks like in practice. Access review evidence under CC6.3 is captured automatically as each campaign runs, with approval, revocation, and reassignment actions logged as auditor-ready records. Vendor assessment windows under CC9.2 are monitored in real time with expiration alerts before the deadline, not after. Monitors for CC7.1 are SLA-aware, surfacing issues as they happen rather than at audit time. When something needs remediation, Rippling guides you directly to the source in-platform with the context and action to fix it, rather than generating a ticket someone else has to interpret.

Compliance becomes an outcome of how you run the business, not a separate project running alongside it.

SOC 2 Is the Starting Line

Reading a SOC 2 report well means treating it as a map of accountability, not a certificate of security. The scope defines what the vendor agreed to be held to. The gaps define the rest of the picture.

For vendor risk teams, the most valuable use of a SOC 2 is as a structured conversation opener. Take the gaps, make them explicit, and ask the vendor to explain each one: what compensating controls exist, how the gap is managed operationally, and what the roadmap is for bringing it into scope.

Organizations with genuinely mature security programs welcome those questions. The answers come quickly and with specifics. The ones running compliance theater struggle, because there is no operational reality behind the documentation.

The goal is not a cleaner SOC 2 for next year. The goal is a vendor whose security posture you actually understand.

Start Evaluating Vendors on Posture, Not Paper

A SOC 2 built on automated, continuously monitored evidence looks different from one built on screenshots and point-in-time reviews. See how Rippling's automated compliance platform generates audit-ready evidence that reflects real security posture, not just audit-period behavior.