SOC 2 Scoping Guide: How to Define Your System Boundary (Without Over-Scoping)
The most expensive SOC 2 mistake startups make isn’t failing the audit—it’s scoping too broadly. When you include unnecessary systems, you multiply evidence collection effort, inflate audit costs by 2–3x, and extend preparation timelines by months.
This guide provides a systematic framework for defining your SOC 2 system boundary, selecting appropriate Trust Services Criteria, and documenting exclusions in a way auditors accept. You’ll learn exactly what to include, what to exclude, and how to justify your decisions using our SOC-002 Scoping Questionnaire.
• Startups that over-scope typically collect 40–60% more evidence than necessary.
• Clear system boundaries documented upfront reduce auditor clarification requests by 50% or more.
• The average startup audit includes 8–12 in-scope systems and 15–25 out-of-scope exclusions.
Table of Contents
- Why Scoping Is Critical
- Step 1: Choose Trust Services Criteria
- Step 2: Define System Boundary
- Typical Startup Scope Examples
- Actual Scope Inventory Template
- Step 3: Map Your Data Flow
- Step 4: Identify Subprocessors
- Step 5: Document Exclusions
- Questions Auditors Ask
- The Hidden Risk: Scope Creep
- Common Scoping Mistakes
- Who Should Own Scoping
- Multi-Product Scoping
- Type I vs. Type II Differences
- Next Steps
- Frequently Asked Questions
Why Scoping Is the Most Critical SOC 2 Decision
Your system boundary determines:
- Which systems require evidence (screenshots, configs, logs)
- Which policies you must write (access control, change management, incident response)
- Which vendors need SOC 2 reports (AWS, Okta, Stripe, etc.)
- How much the audit costs (more systems = more testing = higher fees)
- How long preparation takes (each system adds 10–15 hours of work)
The scoping paradox: Most founders assume “better safe than sorry” and include everything. This backfires. Auditors prefer tight, well-documented boundaries over broad, vague ones.
Step 1: Choose Your Trust Services Criteria (TSC)
SOC 2 audits evaluate controls against one or more of five Trust Services Criteria. Your choice directly impacts scope.
Security (Common Criteria) — Always Required
What it covers: Protection against unauthorized access, system operations, and risk mitigation.
When to select: Always. Every SOC 2 audit includes Security (CC1–CC9).
Availability — Optional (Select Only If Contractually Required)
What it covers: System uptime, disaster recovery, and business continuity.
When to select:
- Your enterprise contracts guarantee specific uptime (99.9%, 99.99%)
- You operate in industries requiring availability commitments
- Customers explicitly request SOC 2 with Availability
Evidence impact: Adds 8–12 artifacts (backup restoration tests, DR procedures, uptime monitoring)
Confidentiality — Optional (Select for Sensitive Data)
What it covers: Protection of confidential information (trade secrets, IP, sensitive customer data).
When to select:
- You handle confidential customer data (financial records, proprietary algorithms)
- You’re a data processor for highly sensitive information
Evidence impact: Adds 5–8 artifacts (data classification, encryption key management, confidentiality agreements)
Privacy — Evaluate Carefully Before Selecting
What it covers: Collection, use, retention, and disposal of personal information (PII).
Most early-stage B2B SaaS companies begin with Security-only scope. However, Privacy may become relevant if you:
- Process consumer or employee personal data at scale
- Operate in regulated jurisdictions with strict data residency rules
- Contractually commit to privacy controls or data subject rights workflows
For many startups, Privacy is deferred until customer requirements or regulatory exposure justify the additional operational overhead.
Evidence impact: Adds 10–15 artifacts (privacy notices, consent mechanisms, retention schedules, data subject request procedures)
Processing Integrity — Almost Never Needed
What it covers: System processing is complete, valid, accurate, timely, and authorized.
When to skip: You’re a standard B2B SaaS application. Processing errors don’t materially impact customers.
Security only for your first SOC 2 audit. Add Availability or Confidentiality only if contractually required. Privacy and Processing Integrity are rarely necessary for early-stage B2B SaaS.
Step 2: Define Your System Boundary
Your system boundary is the line between what’s in scope for the audit and what’s out of scope. This is where most startups make costly mistakes.
The Golden Rule of SOC 2 Scoping
Include systems that:
- Store, process, or transmit customer data
- Are required to deliver your core service
- Could impact security if compromised
Exclude systems that:
- Don’t touch customer data
- Are purely internal/administrative
- Wouldn’t affect security if breached
Typical Startup Scope Examples
Founders often benefit from comparing their architecture against real-world baselines. Here are two common startup scoping patterns:
Example 1: Lean SaaS on Vercel + Supabase
Typical preparation timeline: 4–6 weeks
Typical evidence count: 15–20 artifacts
| In Scope | Out of Scope |
|---|---|
| Vercel production project | Marketing website (static) |
| Supabase production database | Notion workspace |
| GitHub organization | Staging environment (synthetic data only) |
| Google Workspace (admin/SSO) | Founder personal devices |
| Stripe (billing) | Analytics tools (anonymized data) |
Example 2: AWS Multi-Service SaaS
Typical preparation timeline: 8–12 weeks
Typical evidence count: 25–40 artifacts
| In Scope | Out of Scope |
|---|---|
| AWS production account | Sandbox/dev AWS accounts |
| RDS PostgreSQL | Internal analytics dashboards |
| ECS/Fargate containers | Finance/accounting systems (QuickBooks) |
| S3 production buckets | HRIS platform (employee records only) |
| CloudFront (CDN) | Marketing CMS (WordPress/Webflow) |
| Okta (SSO/MFA) | |
| GitHub Actions (CI/CD) |
Note: These are baselines. Your exact scope depends on data flows, access patterns, and contractual obligations. Use our SOC-003 Control Scoping Worksheet to map your specific architecture.
Actual Scope Inventory Template
Before submitting to an auditor, formalize your decisions in a simple inventory table. Auditors use this to validate boundary consistency across your System Description, policies, and evidence.
| System | Environment | In Scope? | Reason / Justification |
|---|---|---|---|
| AWS Prod Account | Production | Yes | Hosts customer workloads and databases |
| GitHub Org | Production | Yes | Stores production code, PRs, deployment configs |
| Vercel Preview Deployments | Staging | No | Synthetic test data only, isolated network |
| HubSpot | Internal | No | Marketing operations, no customer data access |
| Stripe | Production | Yes | Processes billing data, PCI-compliant subprocessor |
| AWS Dev Account | Development | No | No production data, separate IAM roles |
| Notion | Internal | No | Documentation only, no production secrets stored |
Freeze this table before beginning evidence collection. Any changes after fieldwork starts require auditor notification and may extend timelines.
Step 3: Map Your Data Flow
Before finalizing scope, create a simple data flow diagram showing:
- Where customer data enters your system
- Where it’s stored
- Where it’s processed
- Where it exits (reports, exports, APIs)
What this reveals:
- In scope: ALB, Vercel, RDS, S3, SendGrid (all touch customer data)
- Out of scope: Marketing site, internal tools, staging environment
Step 4: Identify and Categorize Subprocessors
Your subprocessors (third-party vendors) are part of your system boundary. You’re responsible for documenting their security posture, even though you don’t control their infrastructure.
Critical Subprocessors (Always Document)
- Cloud hosting: AWS, GCP, Azure (collect SOC 2 Type II report)
- Database hosting: Supabase, MongoDB Atlas, Neon (collect SOC 2 report, encryption docs)
- Identity management: Okta, Google Workspace, Auth0 (collect SOC 2 report, MFA config)
- Payment processing: Stripe, Braintree (collect SOC 2 report, PCI DSS certification)
- Email delivery: SendGrid, SES, Postmark (collect SOC 2 report or security questionnaire)
Non-Critical Subprocessors (List but Don’t Audit)
- Analytics: Mixpanel, Amplitude (privacy policy, data processing terms)
- Marketing: HubSpot, Mailchimp (DPA if processing EU data)
- Internal tools: Slack, Notion, Zoom (generally excluded from scope)
Document all subprocessors in your System Description, but focus evidence collection on critical vendors that touch production customer data.
Step 5: Document Exclusions (The Most Important Step)
Auditors don’t expect you to scope everything. What they do expect is clear documentation of what’s excluded and why.
For each out-of-scope system, document:
- System name (e.g., “Marketing Website”)
- URL or location (e.g., “www.example.com”)
- Reason for exclusion (e.g., “No customer data, read-only content”)
- Risk justification (e.g., “Cannot impact production security if compromised”)
Example exclusion documentation
System: Marketing Website (www.example.com)
Exclusion rationale: Static marketing site with no authentication, no customer data storage, and no connection to production infrastructure.
Risk assessment: Compromise would not impact customer data confidentiality, integrity, or availability.
Auditor acceptance: Accepted (standard exclusion)
Questions Auditors Commonly Ask During Scoping
Expect your auditor to clarify these points during kickoff or early fieldwork. Preparing answers reduces delays and prevents late-stage scope expansion:
- Which environments contain production customer data?
- Are staging and development logically isolated from production?
- Which vendors can access customer information or production systems?
- How are contractors provisioned and removed upon project completion?
- Which systems could directly impact confidentiality, integrity, or availability?
- Are any subprocessors shared across multiple products?
- How is customer data separated in multi-tenant environments?
Document your responses in the System Description or supporting scoping notes. Auditors reference these when validating control boundaries.
The Hidden Risk: Scope Creep During Audit Prep
Many startups begin with a lean Security-only scope, then gradually expand boundaries during preparation:
- Adding staging environments “just to be safe”
- Including internal tooling unnecessarily
- Introducing Availability or Confidentiality criteria mid-project
- Expanding into multiple AWS accounts without documenting the boundary
This creates cascading evidence requirements and often delays audits by 2–4 weeks.
Before collecting evidence, freeze your scope in writing, validate it with your auditor, and resist adding systems unless a contractual or architectural change mandates it.
Common Scoping Mistakes (And How to Avoid Them)
Mistake #1: Scoping Marketing Websites
- Why founders do it: “It’s part of our company, so it should be in scope.”
- Why it’s wrong: Marketing sites don’t store customer data or impact production security.
- Fix: Explicitly exclude with justification: “Static marketing site, no authentication, no customer data, hosted separately from production.”
Mistake #2: Including Staging/Development Environments
- Why founders do it: “We want to be thorough.”
- Why it’s wrong: Staging uses test data, not production customer data. Including it doubles evidence collection.
- Fix: Exclude staging/dev: “Uses synthetic test data only, logically isolated, cannot access customer information.”
Mistake #3: Forgetting Subprocessors
- Why founders do it: “AWS/Stripe handles their own compliance.”
- Why it’s wrong: You’re responsible for documenting subprocessor security posture.
- Fix: List all critical subprocessors in your System Description and collect their SOC 2 reports or security documentation.
Mistake #4: Scoping Employee Devices
- Why founders do it: “Employees access production from their laptops.”
- Why it’s wrong: Individual devices are managed via MDM policies, not audited individually.
- Fix: Document MDM enrollment and device encryption policies, but exclude individual devices from scope.
Mistake #5: Inconsistent Boundaries
- Why founders do it: “We mentioned GitHub in one policy but not another.”
- Why it’s wrong: Auditors cross-reference your System Description, policies, and evidence. Inconsistencies trigger findings.
- Fix: Define scope once, then reference it consistently across all documentation.
Who Should Own Scoping Internally?
For early-stage startups, scoping is typically coordinated by:
- CTO or technical founder (owns infrastructure knowledge)
- Engineering lead (manages deployment pipelines, access controls)
- Operations/Compliance lead (documents exclusions, manages vendor inventory)
Important: The CPA auditor validates scope decisions but does not define your architecture for you. Management remains responsible for the final system boundary definition. Auditors rely on your technical team to accurately map environments, data flows, and subprocessor relationships.
Multi-Product Company Scoping
Question: “We have 3 SaaS products. Do we scope all of them?”
Answer: It depends on your audit strategy and architecture.
Option 1: Scope All Products (Comprehensive Audit)
When: All products share infrastructure (same AWS account, same database) or you want one SOC 2 report covering everything.
Evidence impact: 2–3x more systems, 2–3x more evidence.
Option 2: Scope One Product First (Phased Approach)
When: Products are independent, you’re doing SOC 2 for the first time, or only one product has enterprise requirements.
How: Define Product A as in-scope. Explicitly exclude Products B and C: “Products B and C operate on separate infrastructure, independent codebases, and do not share customer data.”
Option 3: Shared Infrastructure, Separate Applications
When: Multiple products share AWS account, databases, or identity provider.
How: Scope shared infrastructure + all applications. Document logical separation controls (database schemas, IAM roles, network segmentation).
Type I vs. Type II: Scoping Differences
For SOC 2 Type I
- Define scope as of the audit date
- Point-in-time validation
- Can adjust scope for Type II if needed
For SOC 2 Type II
- Scope must remain consistent throughout observation period
- Cannot add/remove systems mid-audit without auditor approval
- Changes require formal documentation and may restart the observation period
Key difference: Type II locks in your scope for 3–12 months. Be certain before you start.
Next Steps
Once you’ve defined your scope:
- Document it formally using our System Description Workbook (SOC-004)
- Collect evidence for in-scope systems using our Evidence Collection Checklist
- Write aligned policies using our Information Security Policy Guide
- Review costs with our SOC 2 Readiness for Bootstrapped Startups
Frequently Asked Questions
Can we change scope between Type I and Type II?
Yes. Type I is point-in-time. You can refine scope for Type II based on lessons learned. Document changes in your System Description update.
Do we need to re-audit if we add a new feature?
Not necessarily. If the new feature uses existing infrastructure (same AWS account, same database), it’s already in scope. If it requires new systems, document them and notify your auditor.
What if we accidentally excluded something?
Disclose it immediately. Auditors may require a scope amendment or note it as a limitation. Hiding it is worse than the mistake itself.
Can we scope just one AWS region?
Yes, if customer data is only in that region. Document: “Production infrastructure is hosted exclusively in AWS us-east-1. Other regions are not used for customer data processing.”
What if we use serverless (Vercel, Supabase)?
Same scoping rules apply. Include production services, exclude staging. Document: “Application hosted on Vercel with Supabase PostgreSQL. Infrastructure is PaaS-managed with shared responsibility.”
Download SOC-002 Scoping Questionnaire
Use our structured framework to document your system boundary — includes in-scope inventory, exclusion templates, subprocessor matrix, and data flow diagrams.
Download SOC-002 →