Most SOC 2 delays aren't caused by control failures. They're caused by scope decisions made at the beginning of the engagement that weren't thought through carefully enough. Systems get added because someone said "we should probably include that." Trust Service Criteria get added because a sales rep said enterprise customers want to see them all. The audit period drags, the evidence collection expands, and the first report takes eighteen months instead of nine.
Scope definition isn't a formality. It's the decision that determines how long readiness takes, what evidence you need to collect, and how useful the resulting report is to your customers.
What "In Scope" Means in SOC 2
A SOC 2 report covers a "system" — defined by the AICPA as the infrastructure, software, people, processes, and data that your service organization uses to provide its services to user entities (your customers). The scope of the audit is the scope of that system.
"System" doesn't mean your entire technology footprint. It means the components that are part of delivering the service being reported on. A SaaS company's SOC 2 covers the application, the infrastructure supporting it, the processes governing it, and the people who operate it — not the company's HR system, Slack workspace, or finance software unless those systems directly participate in delivering the service.
This trips people up: the question isn't "what systems does our company have?" It's "what systems are part of the service we're attesting to?"
The System Description
Your auditor will help you draft a System Description — the narrative document that defines what the audit covers. This document describes your service, the infrastructure and systems in scope, the boundaries of the system, and how the components interact.
The System Description determines the audit. Once it's finalized, everything in it is subject to testing. Everything outside it is not. Changes to the System Description mid-audit — adding a system that wasn't originally included — typically restart or extend the evidence collection period.
This is why scoping decisions need to happen early and with deliberate thought, not organically as the engagement progresses.
Choosing Your Trust Service Criteria
Security (the Common Criteria) is required for every SOC 2. The other four categories are optional and should be chosen based on what your customers care about and what claims you're making about your service.
Availability: Add this if uptime is a contractual commitment or a meaningful differentiator. If your customers have SLAs with you around availability, they'll want to see Availability criteria in your report. Availability adds controls around capacity management, redundancy, monitoring, and incident response related to service availability.
Confidentiality: Add this if customers share confidential information with you and need assurance about how you protect it. Many B2B SaaS companies handling sensitive business data or professional information include Confidentiality. It adds controls around the classification, handling, retention, and disposal of confidential information.
Processing Integrity: Add this if your service processes transactions or data where accuracy and completeness matter — financial calculations, medical records processing, order fulfillment. Processing Integrity is relevant when the accuracy of what your system does with data is as important as whether it's protected.
Privacy: Add this if you collect, use, retain, disclose, or dispose of personal information about individuals and your customers want assurance of your privacy practices. Privacy adds significant scope — it maps to the AICPA's Privacy Management Framework and touches data classification, consent, collection practices, retention, and individual rights.
The practical guidance: start with Security, add Availability if you have uptime commitments, add Confidentiality if customers are sharing sensitive business data, and evaluate Privacy only if customer demand specifically drives it. Each criterion adds scope, evidence requirements, and audit duration.
What Belongs In Scope
These are the system components that typically belong in scope:
The application itself: Your customer-facing service — the web application, API, mobile apps. If customers interact with it as part of the service you're attesting to, it's in scope.
The infrastructure supporting the application: Cloud environments (AWS, Azure, GCP), databases, application servers, networking components. If the application runs on it, it's in scope.
Identity and access management systems: Your identity provider (Okta, Microsoft Entra ID (formerly Azure AD), Auth0), SSO configurations, privileged access management tools. How people authenticate to and within the system is core to the Common Criteria.
Supporting processes: Change management, vulnerability management, incident response, access provisioning and deprovisioning, vendor management. These are organizational processes, not just technology — but they're in scope because they govern how the system operates.
People: The individuals who operate, maintain, and support the in-scope systems. Their access, training, and adherence to policies is subject to testing.
What Typically Stays Out of Scope
Internal business systems: HR systems, accounting software, project management tools, internal wikis. Unless these systems process customer data or directly support the delivery of the service, they don't belong in scope.
Development environments: If your development and staging environments are isolated from production and don't contain real customer data, they can often be excluded. If developers have production access for debugging or if production data is used in test environments, that's a scope conversation.
Legacy or deprecated systems: If you're migrating away from a system during the audit period, carefully consider whether to include it. Including a system you're actively replacing means producing evidence for it throughout the period.
Subservice Organizations
Vendors who provide components of your system that customers rely on — your cloud provider, payment processor, email delivery service — are "subservice organizations." You have two options for handling them:
Carve-out method (standard): The subservice organization is identified in your System Description but excluded from the scope of your audit. Your report notes that the subservice organization has its own controls and its own SOC 2 report that users can review. This is how most companies handle AWS, Azure, and major SaaS dependencies.
Inclusive method: The subservice organization's controls are included in your audit scope. This is rarely done because it requires the subservice organization to be audited as part of your engagement, which adds significant complexity and cost.
Carve-out is the standard approach. The important obligation it creates: your report must describe what complementary user entity controls are expected of your customers for the carve-out to be valid. Auditors check that these are defined and that your controls are appropriate given that you're relying on subservice organization controls for certain layers.
How Scope Creep Happens
Scope creep in SOC 2 typically follows one of three patterns:
The "might as well" pattern: A system is added to scope because it touches customer data in some way, even if it's peripheral. A customer support tool that displays some user information gets added. An internal analytics system that processes usage data gets added. Each addition is defensible in isolation; collectively, they expand the audit beyond what's needed.
The criteria accumulation pattern: All five Trust Service Criteria are included because sales said enterprise customers want all of them. Privacy is added before the organization has a mature data governance program. The audit takes twice as long and the report covers criteria the organization isn't ready to test.
The mid-audit addition pattern: A new system is deployed during the audit period. Someone decides it should be in scope. The System Description is updated. The evidence collection period needs to cover this new system, which means either extending the period or having a qualified opinion.
Lock scope early, resist additions unless a customer requirement specifically drives them, and defer uncertain systems to a future audit period when they're stable.
The Right Size
A well-scoped first SOC 2 covers your core service, the infrastructure it runs on, and the Security criteria (with Availability if relevant). It excludes peripheral systems that don't directly affect what customers receive. It identifies major subservice organizations and carves them out.
This produces a report that's credible and useful to the customers asking for it, an audit that takes nine to twelve months instead of eighteen, and a foundation you can build on in subsequent years as scope expands deliberately.
SOURCES
- AICPA, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy: aicpa-cima.com
- AICPA, Trust Services Criteria (2017, updated 2022): aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
- AICPA, Illustrative Type 2 Report: aicpa-cima.com
Figuring out what belongs in scope for your SOC 2 audit? Schedule a consultation to talk through your system boundaries and which criteria make sense for your customer base.
