How to Scope Systems for SOC 2 (Without Over-Auditing)

What "scope" actually means in SOC 2 — the system boundary and five components

In a SOC 2 examination, "scope" is not a list of controls — it is the system boundary: the specific set of things your report describes and your auditor tests. That boundary is defined in the AICPA's DC section 200 (2018 Description Criteria, with revised implementation guidance — 2022), the criteria your Section 3 system description must satisfy. Get the boundary right and everything downstream — control selection, evidence requests, cost — follows cleanly. Get it wrong and every phase inherits the error.

DC section 200 frames the description around required disclosures: the types of services provided, the principal service commitments and system requirements, the components of the system, and the period covered. Two of those disclosures do the heavy lifting during scoping. The system components (criterion DC3) tell you what is in the boundary; the service commitments and system requirements tell you which Trust Services Categories the boundary must satisfy. Naming both explicitly is what separates a defensible scope from a guess.

The five system components: infrastructure, software, people, procedures, data

DC3 defines a system as five interacting components. Scoping means drawing the boundary around specific instances of each one — this production database, that identity provider, these on-call engineers — rather than around the abstract category. The table maps each component to a concrete SaaS example.

The pattern is consistent: a component instance is in scope when it touches customer data or supports a service commitment, and out of scope when it does neither.

Production environment vs corporate environment — where founders draw the line

The most common founder question is whether laptops, HR tools, and the marketing site are "in scope." The clean line is your production environment — the systems that deliver the service and hold customer data — plus the corporate systems that govern access to production (identity, code, and endpoint management). Your Okta or Google Workspace tenant, your GitHub organization, and your MDM are in scope because they control who reaches production. A corporate finance tool that never touches production or customer data usually is not. Scope also has boundary dimensions beyond production-versus-corporate: which product lines, regions, legal entities, and data centers are inside the boundary. A multi-product company can scope one product now and expand later, but the report must say exactly which.

Step-by-step: how to define your SOC 2 scope

The workflow below is the seven-step method we run in a scoping session — the same sequence reflected in our audit methodology. Each step produces an artifact that feeds the next.

Step 1 — Inventory what stores, processes, or transmits customer data

Start with data, not systems. List every place customer data lives or moves: application databases, object storage, message queues, data warehouses, backups, and logs. Add the systems that operate on that data — the application itself, batch jobs, and integrations. This inventory is the raw material for the boundary; anything that stores, processes, or transmits customer data is a candidate for in-scope.

Step 2 — Map the data flow, then map each asset to the five components

Before you assign components, draw the data-flow diagram — the single most useful scoping artifact. Trace customer data through four stages: how it enters (APIs, web app, file uploads), where it is stored (primary database, caches, backups), how it is processed (application services, pipelines, analytics), and how it exits (exports, webhooks, third-party integrations). The trust boundary is the line around everything in that flow plus the systems that govern access to it. Once the flow is clear, tag each asset against the five DC3 components (infrastructure, software, people, procedures, data). Any asset that appears in the flow but you intend to exclude needs a documented reason.

Step 3 — Classify every vendor: subservice organization or ordinary vendor?

Not every third party belongs in scope. The test from the AICPA guidance is whether the vendor's controls are necessary, in combination with your own controls, to meet one or more applicable trust services criteria. If yes, it is a subservice organization (e.g., your cloud host). If no, it is an ordinary vendor that can stay out of scope entirely. This single question prevents both over-scoping (auditing your CRM) and under-scoping (ignoring your hosting provider). It sits at the heart of good vendor management and third-party risk.

The takeaway: classification is driven by necessity to a criterion, not by how "important" a vendor feels.

Step 4 — Choose carve-out vs inclusive for each subservice organization

For every subservice organization, pick a method (detailed in the comparison below). In nearly all cases you will use the carve-out method: the provider's controls are excluded from your description and testing, but you name the provider, describe its services, and list the complementary controls you assume. The inclusive method — describing and testing the provider's controls inside your report — is technically available but requires the provider's cooperation and written assertion, which cloud providers do not offer.

Step 5 — Select your Trust Services Categories

Scope is not only which systems but which categories. Under TSP section 100, Security (the Common Criteria, CC1–CC9) is mandatory; Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected from your service commitments and system requirements. Each added category brings its own criteria and expands the controls mapped to each Trust Services Criterion, along with the evidence you must produce.

Step 6 — Document CUECs and CSOCs

A complete scope names the controls you do not operate but rely on. Complementary user entity controls (CUECs) are controls you assume your customers implement — configuring SSO, managing their own admin accounts — for your controls to meet the criteria. Complementary subservice organization controls (CSOCs) are the equivalent for carved-out providers. Both are disclosures your Section 3 description must include, and defining them during scoping draws the responsibility line cleanly.

Step 7 — Write the scope statement and lock it before fieldwork

Finally, write a scope statement that names the in-scope services, the system boundary and its components, the subservice organizations and method for each, the selected categories, the CUECs and CSOCs, and the period covered. This becomes the scope paragraph of your report and the boundary in Section 3 — the exact text a buyer reads. Lock it before the observation period begins. Because a Type II tests operating effectiveness across a defined window, mid-period scope changes create testing gaps: add a system or acquire a company mid-period and that change may not be fully testable until the next cycle (which is why scope interacts closely with your choice of Type I vs Type II and observation period). With scope locked, move to a SOC 2 readiness checklist.

“Scoping is the single most impactful decision in a SOC 2 engagement. Over-scope and you burn budget auditing systems no buyer cares about; under-scope and you leave a gap that fails enterprise diligence. The right boundary covers exactly what your customers rely on — nothing more.”

— Sébastien Ruosch, CPA, Director of Audits at Auditsuisse

In-scope vs out-of-scope: a decision matrix

The two questions that settle almost every scope decision are: does it touch customer data, and does it support a service commitment? The matrix below applies them to common assets.

When staging genuinely holds no production data, excluding it is both correct and defensible — but document that it uses synthetic data, or an auditor will ask.

Carve-out vs inclusive method explained

Once a vendor is a subservice organization, DC section 200 (criterion DC7) gives you two ways to treat it in the report. The choice affects report length, cost, and who has to cooperate.

Why AWS, GCP, and Azure are always carved out in practice

Major cloud providers are, as a matter of near-universal practitioner practice, treated as carved-out subservice organizations. This is not an AICPA rule — the inclusive method is technically permitted for any subservice organization — but it is what happens in reality: hyperscalers will not participate in a customer's audit, provide a written assertion, or open their controls to your auditor. Instead they publish their own SOC 2 report, which you obtain and rely on. You disclose the provider, describe the services it supplies, and document the CSOCs you assume (for example, that AWS enforces physical data-center security).

When the inclusive method makes sense (rarely)

The inclusive method is worth considering only when you have influence over the subservice organization — for instance, a wholly owned affiliate or a small, closely partnered processor — and a buyer wants a single report covering both. Even then, it requires the subservice organization's written assertion and adds testing scope, so most teams still carve out. The CUEC/CSOC quick reference below keeps the complementary-control vocabulary straight.

Choosing Trust Services Categories and how they change scope

Category selection is a scope decision with real cost consequences: each optional category adds criteria and evidence. Anchor the choice to your service commitments and system requirements — the DC-defined concept that governs which categories apply — rather than adding categories speculatively.

Most B2B SaaS start with Security plus Availability; healthtech handling personal data often adds Confidentiality and Privacy and pairs SOC 2 with a HIPAA assessment.

Worked example — a Series A B2B SaaS on AWS (with a healthtech PHI variant)

Here is an anonymized scope statement of the kind that becomes the boundary in Section 3 of a report.

In-scope system. The production SaaS application hosted on AWS (us-east-1), its application database, object storage, and supporting data pipelines; plus the corporate systems that govern access to production — the Okta identity tenant, the GitHub organization for production code, and endpoint management for engineers with production access.

Subservice organizations (carved out). AWS (hosting/infrastructure) and the payment processor. Each is named, its services described, and the CSOCs assumed are documented; the company relies on each provider's own SOC 2 report.

Out of scope. Staging and development environments (synthetic data only), the marketing website, and internal tools that do not touch customer data (HR, expense management).

Categories. Security and Availability.

Healthtech PHI variant. If the same platform handles protected health information, the data component now includes PHI, so the boundary adds the systems that store and transmit it, and the category selection typically adds Confidentiality and Privacy. The PHI-handling systems are scoped jointly with the HIPAA analysis so one boundary serves both examinations.

Compliance-automation platforms such as Vanta, Drata, and Secureframe can auto-discover in-scope infrastructure and monitor for scope drift between periods — useful for keeping the boundary current. They accelerate inventory, but they do not replace the judgment calls above: whether a vendor is truly a subservice organization, which categories your commitments require, and where the production/corporate line sits are decisions a qualified auditor validates.

Common scoping mistakes (and how to avoid them)

Over-scoping. Including non-critical systems and unneeded categories inflates auditor effort, evidence volume, and cost without improving buyer trust. Start from the data flow and add only what touches customer data or a service commitment.

Under-scoping. Excluding a system that quietly processes customer data (a logging pipeline, an analytics sink) creates a gap that enterprise procurement diligence will find. Trace the full data flow, including egress, before excluding anything.

Misclassified vendors. Treating an ordinary vendor as a subservice organization wastes effort; missing a real subservice organization (your host) undermines the report. Apply the necessity-to-a-criterion test consistently.

Scope drift between periods. Adding products, regions, or entities mid-observation-period breaks testability. Lock scope before the window opens and manage changes deliberately. Many scope-related exceptions surface in our roundup of common SOC 2 findings, and scope directly drives your audit timeline. For definitions of the terms used here, see the compliance glossary.