Scope is the most consequential decision in SOC 2 planning. It determines which systems and services the auditor will test, which personnel are subject to auditor interviews and control testing, how long the audit engagement will take, and ultimately what value the resulting report delivers to clients. A poorly scoped audit can be too narrow to satisfy client requirements, or too broad to be completed efficiently. Getting scope right — before engaging an auditor — is the first step in a well-executed SOC 2 program.
What Scope Means in SOC 2 Terms
In SOC 2, scope is expressed through the System Description — a formal document that describes the system in scope for the audit. The AICPA defines the system as “the infrastructure, software, people, procedures, and data necessary to provide the service organization’s service commitments and system requirements.” The scope boundary must include everything that contributes materially to those service commitments.
| System Component | What It Includes in Scope | Scoping Consideration |
|---|---|---|
| Infrastructure | Servers, cloud environments, networks, data centers, and storage that support the in-scope services | Cloud accounts hosting production workloads are in scope; development/sandbox accounts may be excluded if fully separated from production data |
| Software | Applications, APIs, databases, and tools that process, store, or transmit client data as part of the service | Third-party SaaS tools that process client data are typically addressed as subservice organizations, not fully in scope |
| People | Employees and contractors with roles relevant to the security of the system | Personnel with administrative access, security responsibilities, or regular access to client data are in scope; unrelated departments may be excluded |
| Procedures | The documented policies and operational processes that govern the system | All policies and procedures referenced in the system description must be current and implemented |
| Data | The data processed, stored, and transmitted by the system | Client data, authentication data, and configuration data are typically in scope; log data and operational metrics may be scoped partially |
Carve-Outs and Subservice Organizations
A carve-out is when a third-party service provider is explicitly excluded from the scope of the SOC 2 report because the auditor cannot audit them directly. Instead, the report notes that users should separately review the controls of those subservice organizations. Common carve-outs include cloud infrastructure providers (AWS, Azure, GCP), colocation data centers, and third-party SaaS tools that process in-scope data.
| KEY IDEA | Carving out a subservice organization does not eliminate the risk — it shifts the responsibility for verification to the report user. Enterprise clients reading your SOC 2 report will see the carve-out and will separately request your cloud provider’s SOC 2 report. The alternative is inclusive scope — where you rely on your cloud provider’s controls and include them via a complementary subservice organization (CSO) description, which requires you to obtain and review their SOC 2 report and map it to your control environment. |
Scope Boundary Decisions: Strategic Trade-offs
| Scope Decision | Narrower Scope | Broader Scope |
|---|---|---|
| Services included | One product / one service line only | All customer-facing services |
| Infrastructure | Production cloud environment only | Production + DR + staging (if staging handles production data) |
| Personnel | Core engineering and security team | All employees who access client data or systems |
| Trust Services Criteria | Security only | Security + Availability (+ others) |
| Audit duration | Shorter observation period; faster audit | Longer observation period; more evidence; more testing |
| Audit cost | Lower — fewer systems, simpler evidence collection | Higher — more systems, more complex evidence requirements |
| Report value to clients | Narrower assurance; clients may question coverage | Broader assurance; more credible to enterprise buyers with complex requirements |
Common Scoping Mistakes
The most damaging scoping mistake is defining scope too narrowly to satisfy client requirements. A SOC 2 report that covers only your “Development Platform” service when clients are asking about your “Enterprise Suite” creates a gap that clients will identify during due diligence — and which may require a second audit to close. Before finalizing scope, review your actual enterprise client requirements and map them to the proposed system boundary.
| IMPORTANT | Never let the scope be defined by what is “easy to audit” rather than what is relevant to your service commitments. Auditors will highlight any material service commitments that fall outside the system description. A scope that appears to exclude high-risk components — intentionally or not — undermines the credibility of the resulting report. |
The second common mistake is failing to include personnel with relevant responsibilities. If your infrastructure team uses a cloud console with elevated privileges and they are excluded from scope, auditors will raise a scope qualification. The system description must accurately reflect the people who operate the system — including outsourced or contract personnel with material responsibilities.
Building the System Description
The system description is not just a scope statement — it is a narrative document that an enterprise client’s security team will read carefully. It should describe: the nature and purpose of the service, the principal service commitments (uptime, confidentiality, availability), the infrastructure components with technology stack, the software and key applications, the people and organizational structure, the procedures for key control activities, and any relevant contractual or regulatory requirements.
A well-written system description runs 8–15 pages. It is typically drafted by the service organization before the audit engagement, reviewed and edited by the auditor, and finalized as part of the audit report. Common errors in system descriptions include: describing infrastructure that no longer exists, omitting third-party tools that process client data, and using vague language about procedures that auditors will need to test specifically.