How do I scope my SOC 2 audit to keep it manageable?
How Do I Keep SOC 2 Scope Small?
SOC 2 scope determines how much work you do. A larger scope means more controls, more evidence, and a longer audit. The key is including only what matters — the systems and criteria that your customers and auditor actually need to see.
Scoping Decisions
| Decision | Smaller Scope | Larger Scope |
|---|---|---|
| Trust Services Criteria | Security only | Security + Availability + Confidentiality |
| Systems included | Production environment only | Production + staging + internal tools |
| Cloud accounts | One AWS/GCP account | Multiple accounts across regions |
| Applications | Customer-facing app only | All internal applications |
| People | Engineering + leadership | Entire company |
Three Rules for Scoping
-
Include only systems that touch customer data. Your internal Slack, HR tools, and marketing stack are typically out of scope. Focus on your production infrastructure, application, and the SaaS tools that access customer data.
-
Start with Security only. Do not add Availability, Processing Integrity, Confidentiality, or Privacy unless a specific customer requires it in writing.
-
Draw your boundary at the infrastructure level. If you use Vercel or AWS, your boundary starts at your configuration layer — not at the physical data center. Reference your cloud provider's SOC 2 report for infrastructure controls below your boundary.
Common Scoping Mistakes
- Including staging and development environments (rarely needed)
- Adding every SaaS tool the company uses (only include those that touch customer data)
- Scoping to all five Trust Services Criteria on the first audit
- Including employee personal devices beyond basic MDM requirements
How to Document Your Scope
Create a simple system description that lists:
- Which cloud accounts are in scope
- Which applications process customer data
- Which third-party tools are included
- Which Trust Services Criteria you are auditing against
- Which teams and roles are in scope
Screenata helps define your scope by analyzing your codebase and infrastructure to identify which systems process customer data and which controls apply.