SOC 218 April 2026 7 min read

SOC 2 Scope Definition: How to Pick What Gets Audited

Scope definition is the highest-leverage decision in SOC 2. Learn how to draw a defensible system boundary that keeps costs low and the audit clean.

Key Takeaways

Scope defines which systems, services, and environments are covered by the SOC 2 audit — everything in scope must have controls and evidence.
The narrowest defensible scope for most SaaS companies is: production application, cloud hosting account, identity provider, and source code management.
Development and staging environments can typically be excluded with written justification — but only if they have no access to production customer data.
Every system added to scope multiplies the evidence requirements multiplicatively — scope decisions have exponential, not linear, cost consequences.
The system description in the SOC 2 report (Section III) must accurately and completely describe what is in scope.

In this guide

What SOC 2 Scope Actually Means
Systems Typically In Scope
What Can Legitimately Be Excluded
Carve-Out vs Inclusive Method for Vendors
Writing the System Description
Scope Creep: The Hidden Cost Driver

What SOC 2 Scope Actually Means

SOC 2 scope — formally called the "system" in SSAE 18 terminology — is the bounded set of infrastructure, software, people, processes, and data that are subject to the Trust Service Criteria evaluation. Everything inside the boundary must be addressed by controls; everything outside the boundary is not evaluated by the auditor.

Scope is defined by the system description: Section III of your SOC 2 report written by your management (not the auditor). It describes the service commitments and system requirements, the system components (infrastructure, software, people, processes, data), and the system boundaries — what is included and what is explicitly excluded and why.

Your auditor validates that the system description is fairly presented — meaning it accurately represents what you've described and doesn't omit systems that should be included. An auditor who discovers systems outside your stated boundary that process customer data will either require you to expand scope or note the limitation in the report.

Systems Typically In Scope

For a typical B2B SaaS product, in-scope systems include: (1) The production application servers and containers hosting your product. (2) The cloud hosting environment — typically the specific AWS accounts, GCP projects, or Azure subscriptions containing production workloads. (3) The production databases containing customer data. (4) The identity provider managing production system access (Okta, Google Workspace). (5) The source code management system (GitHub, GitLab, Bitbucket) because it controls what code reaches production. (6) The CI/CD pipeline that deploys to production.

Supporting systems that interact with in-scope systems also typically come in scope: your secrets management system (AWS Secrets Manager, HashiCorp Vault), your logging and monitoring platform (Datadog, CloudWatch) if it processes customer data, and your customer support system if support agents access customer data to resolve tickets.

People in scope include all personnel with access to in-scope systems — typically your engineering team, DevOps/SRE team, security team, and any support staff with production access. Contract employees and offshore development teams with production access are also in scope, which can significantly expand HR documentation requirements.

What Can Legitimately Be Excluded

Development and staging environments can be excluded if they are strictly isolated from production customer data. "Strictly isolated" means no production database credentials are used in staging, staging environments cannot access production APIs, and no real customer data is used in testing (synthetic or anonymized data only). If your staging environment connects to a production database for "realistic testing," it is in scope.

Internal tools that don't process customer data can typically be excluded: your Slack instance, your HR platform, your marketing automation, your internal wiki. The test is whether a compromise of that system would expose customer data or impair your ability to deliver the service. If yes, it belongs in scope.

Corporate IT systems (employee laptops, internal network) can sometimes be excluded through a network segmentation argument — if employee devices can't reach production systems directly and access is mediated through the in-scope identity provider (which enforces device compliance), the laptops themselves may be out of scope. This exclusion requires strong evidence of network segmentation and device management controls.

Carve-Out vs Inclusive Method for Vendors

When your in-scope systems rely on a third-party vendor (like AWS), you have two options for handling their portion of the controls. The carve-out method excludes the vendor's controls from your report entirely — your report says "the controls at AWS are not covered in this report; users should review AWS's own SOC 2 report." The inclusive method includes the vendor's controls in your report, requiring you to test and vouch for those controls.

Almost all SOC 2 reports use the carve-out method for IaaS providers like AWS, Google Cloud, and Azure. The inclusive method is used when you have direct visibility into and contractual control over the subservice organization's controls — typically in outsourcing relationships where you manage a vendor's environment.

Under the carve-out method, you list the subservice organization in your system description, describe what services they provide, and note that complementary subservice organization controls (CSOCs) are expected to be in place. Your enterprise customers can then review your report alongside AWS's SOC 2 report to get the complete picture.

Writing the System Description

The system description (Section III of the SOC 2 report) is written by management — not the auditor. Most CPA firms provide a template or guidance, but you are responsible for the content. The auditor's role is to evaluate whether the description is "fairly presented" — accurately describing the system without material omissions or misrepresentations.

The description typically includes: an overview of the service and its purpose, the infrastructure components (cloud environment, servers, databases, networks), the software components (application code, third-party libraries, operating systems), the people involved (roles, team structure, hiring and training practices), the processes (change management, access management, incident response), and the data (types of customer data processed, data flows, retention).

Write the description for an informed reader who is not familiar with your company. Enterprise security teams send your SOC 2 report to their auditors and legal teams — these readers need enough detail to understand what systems and data are covered. Vague descriptions ("our secure cloud-based platform") are insufficient and will trigger auditor comments.

Scope Creep: The Hidden Cost Driver

Scope creep — the gradual expansion of audit scope beyond the initial boundary — is one of the most common causes of SOC 2 cost overruns. It happens in two ways: intentional additions (adding systems to scope mid-engagement because a customer asks about them) and auditor-driven additions (the auditor discovers systems that should have been in scope and requires their inclusion).

Protect against scope creep by documenting your scope boundary explicitly before engaging the auditor. Define what is in scope, what is out of scope, and your written justification for each exclusion. Review this document with the auditor at engagement kickoff and get written agreement on the scope. If a customer asks about a system that is out of scope, respond that the SOC 2 covers the defined production environment and that the requested system is managed under a separate security assessment.

Adding systems to scope after the observation period has started requires extending the period for those systems or noting that they were added mid-period. Either outcome adds complexity and cost. Lock scope before the observation period begins and maintain it for the full year.

Frequently Asked Questions

Can we have different scopes for different customers?

No — a SOC 2 report has a single, defined scope. You cannot issue different versions of the same report with different scopes for different customers. If different customers have different needs, you would need separate SOC 2 engagements with different scope definitions — which is impractical. The standard approach is to define a scope that satisfies the majority of your enterprise customers' requirements.

Does the scope need to include all AWS accounts?

No — scope should include the specific AWS accounts that contain production customer data, not all accounts. If you have separate AWS accounts for development, staging, and production (which is best practice), only the production account needs to be in scope. Audit your account boundaries before starting: many startups discover they have production resources in accounts they thought were dev/test.

What if our scope changes between audits?

Scope changes between annual audits are normal — companies launch new products, migrate to new infrastructure, or add new services. Document the change in your updated system description and discuss with your auditor at the start of the new engagement. If the change is significant (new product, cloud migration), budget additional auditor time for the new systems. The auditor needs to understand new components before they can evaluate controls over them.

Does our mobile app need to be in scope?

If your mobile app processes customer data or connects to in-scope backend systems (which it almost certainly does), the app itself and its backend API must be in scope. The mobile app client code, app store release process, and API security are all subject to the relevant CC6 and CC8 criteria. Many companies fail to include mobile app change management records in their CC8 evidence, resulting in exceptions.

How does multi-tenancy affect scope?

Multi-tenant SaaS products — where multiple customers share the same infrastructure — are common and well-supported by SOC 2. The scope covers the shared infrastructure, and the controls evaluate whether customer data isolation is maintained. Evidence for multi-tenant isolation typically includes: tenant isolation architecture documentation, database-level row security or schema-per-tenant configuration, and testing records verifying that one tenant cannot access another's data.