Defining Your SOC 2 Scope: The Decision That Sets Everything Else

The Most Expensive Mistake You'll Make Without Knowing It

Orion HQ's first instinct was to include everything. Every AWS service. Every SaaS tool. Every third-party integration. Their reasoning: "If we're doing this properly, we should cover everything."

Their first auditor call fixed this fast. The auditor's reaction: "That scope would take 18 months and cost twice what you've budgeted. Let's talk about what actually matters."

Scope is the single most important strategic decision in your SOC 2 journey. It determines your cost, timeline, workload, and the ongoing compliance burden you carry every year. Let's get it right.

What "Scope" Actually Means

The system description in your SOC 2 report defines what systems, processes, and people are covered by your audit. It describes:

• The services you provide to customers
• The infrastructure those services run on
• The people who have access to that infrastructure
• The third-party vendors whose services you rely on

Everything inside the boundary gets audited. Everything outside the boundary is explicitly excluded — but the auditor will verify that your exclusions are defensible.

The Three Components of Scope

1. The In-Scope Service

Start with the customer-facing product. What are you actually selling? What does the customer rely on you to deliver securely?

For Orion HQ, this was their analytics SaaS platform. Not their internal HR system. Not their marketing tools. Not their internal documentation wiki. Just the platform customers paid for.

Practical question to ask: "If this system had a breach, would customers be harmed?" If yes, it's likely in scope.

2. The In-Scope Infrastructure

Everything that runs, stores, processes, or transmits data for the in-scope service. This typically includes:

• Production cloud infrastructure (AWS, GCP, Azure accounts used for the product)
• Production databases
• Customer data pipelines
• Authentication systems that protect the product

What's typically excluded:

• Development environments (if isolated from production)
• Internal business tools (Slack, Notion, Figma, etc.) unless they can reach production customer data
• Marketing and sales tools

3. Subservice Organizations (Your Key Vendors)

Any vendor that provides a service that's material to your in-scope service needs to be documented. These are called subservice organizations in SOC 2 language.

For most cloud-native companies, the key subservice organizations are:

• Cloud provider (AWS, GCP, Azure)
• Identity provider (Okta, Azure AD, Auth0)
• Payment processor (Stripe, Razorpay) — if applicable

The good news: your cloud provider (AWS, etc.) almost certainly has their own SOC 2 report. Your audit will note this and include it as a "carve-out" — meaning you rely on their controls, not yours, for the underlying infrastructure.

Orion's Scope Definition

After the auditor conversation, Priya and her team defined Orion's scope as follows:

In-scope service: Orion Analytics Platform — the multi-tenant SaaS analytics service provided to enterprise customers.

In-scope infrastructure:

• AWS production account (us-east-1 and ap-south-1 regions only)
• AWS RDS (customer data storage)
• AWS S3 (customer data lake)
• AWS EKS (application workloads)
• GitHub (code repository with production deployment permissions)
• Okta (identity and access management)

Explicitly excluded:

• AWS development and staging accounts
• Google Workspace (internal email/docs — no production data access)
• Notion (internal wiki — no production data access)
• HubSpot (CRM — no customer platform data)

Subservice organizations:

• Amazon Web Services (covered by AWS SOC 2 report — Type II, carve-out method)
• Okta (covered by Okta SOC 2 report — Type II, carve-out method)

The Carve-Out vs Inclusive Method

When your key vendors have their own SOC 2 reports, you have two options for how to handle them in your audit:

Carve-out method: You explicitly carve out the vendor from your scope and note that you rely on their SOC 2 report. This is the standard approach. You're not responsible for auditing AWS — AWS audits themselves.

Inclusive method: You include the vendor's controls in your own audit scope. This is rare and expensive, and typically only used when a vendor doesn't have their own SOC 2 report.

99% of companies use the carve-out method for major cloud providers and identity vendors.

The Scope Sizing Rule

Here's a practical heuristic I use when helping clients define scope:

The right scope is the smallest set of systems and processes that a reasonable customer would expect to be included when they receive your SOC 2 report.

If you exclude something that a customer would reasonably think was covered, that's under-scoping. If you include everything in your company, that's over-scoping and will drive unnecessary cost.

The test: could you defend this scope to your biggest customer's security team in a 30-minute call? If yes, you're in the right range.

What Comes Next

With scope defined, Orion knew what needed to be assessed. But how bad was their starting position? Before investing in remediation, they needed a clear picture. In the next post, we'll walk through how to run a proper SOC 2 Self-Assessment Checklist to understand where you actually stand before the audit clock starts.