Scope is the single decision that determines everything else about a SOC 2 audit. Before an independent auditor tests a single control, the boundaries of the examination must be drawn: which services, which systems, which Trust Services Criteria, and which third parties fall inside the audit perimeter. Get those boundaries wrong and the resulting SOC 2 audit report either overstates or understates the security posture customers are relying on.

This guide explains how service organizations define SOC 2 audit scope, drawing on the AICPA's Description Criteria and real-world scoping patterns, so that when an independent CPA firm conducts the SOC 2 audit, the examination is precise, defensible, and commercially useful.

Schedule a Meeting with CertPro
TL;DR

Concern

Service organizations often underestimate how much a poorly defined scope damages a SOC 2 audit. Scope too narrow and the SOC 2 audit report fails to satisfy enterprise customers; scope too broad and audit complexity multiplies unnecessarily, raising cost and risk of findings.

Overview

SOC 2 audit scope encompasses five elements: the services examined, the Trust Services Criteria selected, the systems and infrastructure in play, the people who operate them, and how subservice organizations are presented. The AICPA's Description Criteria govern what must appear in the system description that anchors every SOC 2 audit.

Solution

Organizations should document scope decisions including products, environments, geographies, and subservice org treatment before fieldwork begins. An independent CPA firm then conducts the SOC 2 audit against that defined boundary, issuing a SOC 2 audit report that accurately represents the examined system.

What SOC 2 Audit Scope Actually Means

The AICPA defines the subject of a SOC 2 audit as a "system" — the infrastructure, software, people, procedures, and data that together deliver a service to customers (Source: AICPA Trust Services Criteria, 2017, with 2022 points of focus). Scope, therefore, is the formal boundary around that system. The boundary identifies the system components relevant to the controls included in the examination.

Key Elements of a SOC 2 Audit Scope

SOC 2 audit scope has five interconnected components:

  • Services: the specific customer-facing offerings under examination
  • Trust Services Criteria: the applicable categories from the five available
  • Systems: the infrastructure, application code, supporting tools, and data repositories that deliver the services
  • People: the roles and teams that operate, develop, and manage those systems
  • Procedures: the policies and operational processes that govern them
Key Elements of a SOC 2 Audit Scope
Key Elements of a SOC 2 Audit Scope

Scope, System Description, and the Audit Opinion

Critically, management's system description presents the system within the SOC 2 examination scope, and the service auditor expresses an opinion on whether it is fairly presented. If the description omits a material system component, the auditor may require a correction or modify the opinion. This is why scope decisions made before fieldwork have direct consequences for the SOC 2 audit report that customers will read.

A SOC 2 audit does not require full organizational coverage. The AICPA allows organizations to limit examination to specific products, environments, or legal entities, provided the rationale is documented and the excluded components genuinely do not affect the security, availability, or other criteria relevant to customers (Source: AICPA AT-C Section 205).

Defining System Boundaries: What Goes In and What Stays Out

System boundaries answer a precise question: which components are necessary for the service organization to deliver its commitments and system requirements to customers?

Systems and components that store, process, or transmit customer data, or that control access to those systems, may fall within the SOC 2 examination scope when they support the services and system being described.

Production infrastructure (servers, databases, networking), application code, identity and access management systems, CI/CD pipelines with production deployment rights, monitoring and logging tools, and backup systems are typically in scope for a SOC 2 audit. Development environments isolated from production with synthetic data only, and marketing tools that never touch customer data, are commonly excluded.

Boundary decisions that auditors scrutinize most closely: corporate identity providers (Active Directory, Okta) that control production access are almost always in scope; staging environments that share credentials with production should be included; and corporate laptops with direct production access may not be excluded.

Geographic Scope and Fieldwork Implications

Under geographic scoping, if engineering teams in a second region access production systems or customer data, that region is in scope regardless of where the data physically resides. Excluding a location is defensible only when it has no pathway to in-scope systems.

One underappreciated risk is scope creep during fieldwork. An independent auditor conducting a SOC 2 audit will test the system description against evidence gathered during the examination period. If in-scope systems were not fully documented, the auditor must expand testing or flag the description as incomplete. Preventing this requires a thorough system inventory before the SOC 2 audit begins.

Common Scope Boundary Decisions

  • Production Environment

    Typically in scope: Yes, always. Typically out of scope: Never.

  • Staging / QA Environment

    Typically in scope: Yes, if it uses production data or credentials. Typically out of scope: Yes, if fully isolated with synthetic data.

  • Corporate Identity Provider

    Typically in scope: Yes, if it controls production access. Typically out of scope: Only if production uses a separate IdP.

  • CI/CD Pipeline

    Typically in scope: Yes, if it deploys to production. Typically out of scope: No, if limited to non-production environments.

  • Marketing Automation

    Typically in scope: Only if it processes personally identifiable information (PII) of customers in scope. Typically out of scope: Yes, if it holds no in-scope data.

  • International Offices

    Typically in scope: Yes, if staff access production systems. Typically out of scope: Yes, if limited to sales/marketing functions.

Trust Services Criteria Selection and Its Scope Implications

Every SOC 2 audit must include the Common Criteria for Security. The remaining four categories (Availability, Processing Integrity, Confidentiality, and Privacy) are selected based on the commitments the service organization makes to customers and the risks that matter to them (Source: AICPA Trust Services Criteria).

Selecting additional Trust Services Criteria expands scope. Adding Availability means the auditor will examine system uptime commitments, incident response, and disaster recovery controls. Adding Privacy triggers examination of personal information handling across the full data lifecycle. Each addition increases the number of controls tested and the evidence the auditor must collect.

Determining Applicable Trust Services Criteria

A practical test for TSC selection: if a customer's ability to trust the service would be materially damaged by a failure in a given category, that category belongs in the SOC 2 audit scope. For a payroll processor, Processing Integrity is not optional. Errors in calculation are the core risk.

SOC 2 certification conversations with enterprise customers often reveal which criteria matter most to that customer segment. Financial services buyers routinely demand Availability in addition to Security. Customers in regulated industries may require Confidentiality. Scoping TSC selection to match market expectations makes the SOC 2 audit report more commercially valuable without unnecessarily inflating examination scope.

Subservice Organizations, CSOCs, and CUECs in SOC 2 Scope

Most service organizations rely on third-party vendors whose services are integral to delivering their own. When a third party stores, processes, or transmits customer data, or provides controls necessary for the service organization's system to operate, they become a subservice organization under AICPA standards. How they appear in the SOC 2 audit scope is governed by a formal choice between two methods.

Carve-Out vs. Inclusive Method

Under the carve-out method, the subservice organization's controls are excluded from the auditor's testing. The service organization should describe what the subservice organization does, list Complementary Subservice Organization Controls (CSOCs) or the controls the service organization expects the subservice organization to maintain, and monitor the subservice organization's own SOC 2 audit reports. This is the standard approach for major cloud providers such as AWS, Azure, and GCP, which each maintain their own SOC 2 audit reports, which customers can review independently.

Under the inclusive method, the auditor tests the subservice organization's controls directly. This is rare and practical when the service organization has contractual access to the subservice organization's systems and the subservice organization has not obtained its own SOC 2 report.

What Are Complementary User Entity Controls?

Complementary User Entity Controls (CUECs) are controls the service organization expects its own customers to implement for the overall system to meet Trust Services Criteria. They appear in the SOC 2 audit report and explicitly allocate responsibility to the customer.

A SaaS provider, for example, might list that customers are responsible for managing their own user access provisioning. CUECs identify the controls that user entities need to perform to complement the service organization's controls and clarify the responsibilities that fall outside the SOC 2 examination.

Identifying subservice organizations and drafting CSOCs and CUECs before the SOC 2 audit begins is essential. Auditors rely on these lists to understand the full system and assess whether carve-out exclusions are appropriate.

Conclusion

Defining SOC 2 audit scope is a substantive technical exercise, not a preliminary checkbox. SOC 2 audit scope establishes the foundation for the examination. It identifies the service under examination, the applicable Trust Services Criteria, the system that delivers the service, and the relevant relationships with user entities and subservice organizations.

Understanding scope is not a compliance formality. The scope statement embedded in a SOC 2 audit report is the first thing a sophisticated customer or their auditor reads. It signals whether the report covers the systems that actually process their data, or whether it sidesteps them.

As an independent, licensed CPA firm, CertPro performs SOC 2 examinations under the applicable AICPA attestation standards. Our role centers on obtaining and evaluating evidence and expressing an independent opinion on the matters covered by the examination.

Frequently Asked Questions
SOC 2 audit scope covers five elements: the services under examination, the Trust Services Criteria selected, the systems and infrastructure that support those services, the people who operate them, and the procedures governing them.
No. The AICPA allows organizations to limit a SOC 2 audit to specific products, environments, or legal entities. Exclusions are acceptable when the excluded components have no impact on the security, availability, or other Trust Services Criteria relevant to customers.
Under the carve-out method, the subservice organization's controls are excluded from auditor testing; the service organization lists expected controls (CSOCs) instead. Under the inclusive method, the auditor tests the subservice organization's controls directly. Carve-out is standard for major cloud providers like AWS and Azure, which maintain their own SOC 2 audit reports.
CUECs are controls the service organization expects its customers to implement for the overall system to meet Trust Services Criteria. They appear explicitly in the SOC 2 audit report and define the boundary between the service organization's responsibilities and the customer's. A common example is requiring customers to manage their own user access provisioning.
Each additional Trust Services Criteria category beyond the mandatory Security category expands the audit scope. Adding Availability requires testing of uptime and disaster recovery controls; adding Privacy triggers examination of personal data handling across the full data lifecycle.