Defining Your SOC 2 Audit Scope

How to Define Your SOC 2 Audit Scope (Without Over- or Under-Scoping It)

Your SOC 2 audit scope defines exactly which systems, processes, and services get tested — get it wrong in either direction and you either leave customers with unanswered security questions, or take on audit time and complexity you didn't actually need. Scoping is one of the most consequential decisions in SOC 2 preparation, and it's also one of the most commonly misunderstood.

This guide walks through how to define a scope that's both defensible to customers and manageable for your team.

Why Scope Matters

Your scope shapes how customers interpret your entire compliance program. If a critical system or customer-facing service is left out, security-conscious buyers will notice the gap and ask why — a report that covers your core API but excludes the mobile app processing the same customer data invites exactly that question. If the scope is too broad and pulls in systems that aren't well-controlled (an internal HR tool with no customer data exposure, for instance), you risk generating audit exceptions on systems that never needed to be tested in the first place.

The goal is a scope that's clear, defensible, and aligned with what your customers actually expect — covering the systems and data that matter to them, and nothing that doesn't.

Starting Point: Map Your Services and Data Flows

Before drawing scope boundaries, map out what you actually provide and how data moves through it. Work through these questions concretely:

• What products or services are covered by your customer contracts?

• Where is customer data stored and processed — which databases, which regions, which vendors?

• What systems support core service delivery, versus internal tooling that never touches customer data?

• Which teams and processes interact directly with in-scope data?

This mapping exercise is what lets you define a scope that matches how customers actually experience your platform, rather than one that matches your internal org chart.

What Typically Falls Within Scope

For most SaaS companies, audit scope includes:

• The cloud infrastructure hosting your production services

• The software components that process or store customer data

• The processes used to deploy, maintain, and secure those systems — CI/CD pipelines, deployment approvals, monitoring

• The teams directly responsible for managing and supporting in-scope systems

Handling Subservice Organizations

Critical third parties your product depends on — cloud providers, payment processors, vendors handling sensitive data on your behalf — are called subservice organizations, and you have two options for handling them:

Carve-out method (most common for SaaS companies): You exclude the subservice organization's own controls from your report and instead rely on their existing compliance documentation. Most SaaS companies carve out AWS or GCP this way — you're not re-testing their physical data center security or hypervisor isolation; you're relying on their own SOC 2 report for that layer, and your report focuses on what you control on top of their infrastructure.

Inclusive method: You bring the subservice organization's controls directly into your own audit, which requires their cooperation and typically applies when you have deep operational dependency on a smaller vendor that doesn't maintain its own SOC 2 report.

For most companies, carve-out is simpler and sufficient — just be prepared to document how you monitor and manage the risk of whatever you carve out, since your auditor and your customers will both expect to see that oversight even if the vendor's internal controls aren't directly tested. [Note: could not verify the URL for DSALTA's vendor-risk-automation content referenced in the source draft — confirm the correct slug and I'll add the link back with proper anchor text.]

How to Right-Size Your Scope

A well-defined scope balances two failure modes:

Too narrow. Excluding a system customers reasonably expect to be covered — a customer-facing mobile app, a support portal that stores tickets with sensitive data — triggers exactly the kind of questions that slow down enterprise sales cycles, since a security reviewer will ask why it's missing rather than assume it's fine.

Too broad. Including systems with no real customer data exposure — internal analytics dashboards, HR systems, marketing tools — adds audit time and cost without adding customer trust, and increases your surface area for exceptions on controls that were never customer-relevant in the first place.

Validate your scoping decisions with your auditor early, ideally before you've built out controls for systems that might not need to be in scope at all. They can help calibrate based on your specific customer base and risk profile, not just a generic template.

Aligning Scope Across Frameworks

If you're pursuing SOC 2 alongside HIPAA, ISO 27001, or PCI DSS, defining consistent system boundaries and data flow diagrams once — rather than re-scoping from scratch for each framework — saves real time and reduces the risk of contradictory scope decisions across audits covering the same systems.

FAQ

What is a subservice organization? A third-party vendor whose systems or controls support your service delivery — commonly a cloud provider (AWS, GCP, Azure) or a payment processor. You decide whether to test their controls directly (inclusive method) or rely on their own compliance documentation instead (carve-out method).

Should I include or carve out my cloud provider? Most SaaS companies carve out major cloud providers like AWS and GCP, relying on the provider's own SOC 2 report for infrastructure-level controls, while their own audit covers what they control on top of that infrastructure.

Can I change my SOC 2 scope after the first audit? Yes — scope commonly expands as a company grows, adding new products, criteria, or systems in later audit cycles. Just be aware that expanding scope typically means the newly added systems need their own readiness work before the next audit.

Does a broader scope make my SOC 2 report more impressive to customers? Not inherently. A tightly scoped report that clearly covers everything customers care about is more useful than an unnecessarily broad one — what matters is that scope matches customer expectations, not that it's maximized.