Why Scope Matters

Your SOC 2 scope defines exactly what's being examined. Get it right, and the report accurately represents your security posture. Get it wrong, and you face problems:

  • Too narrow: Customers question why certain systems aren't covered
  • Too broad: Unnecessary cost and complexity, more potential findings
  • Unclear boundaries: Confusion about what the report actually covers
Key Principle

SOC 2 scope should cover the systems and services that customers rely on - the things that matter to the trust they place in you.

Scope Components

SOC 2 scope includes several interconnected elements:

1. Services

What services are you providing to customers? Examples:

  • SaaS application (e.g., "Company X's project management platform")
  • Cloud infrastructure (e.g., "Managed Kubernetes hosting services")
  • Data processing (e.g., "Payroll processing services")

2. Trust Services Criteria

Which of the five criteria apply?

  • Security (required)
  • Availability
  • Processing Integrity
  • Confidentiality
  • Privacy

3. Systems

What infrastructure, software, and components support the services? This is where boundaries come in.

4. People

Who operates, develops, and manages the in-scope systems?

5. Procedures

What processes and controls govern the systems and services?

6. Data

What types of data do the systems process, store, or transmit?

System Boundaries

System boundaries define where your scope starts and ends. Think of them as a line around everything that's "in" your SOC 2.

What's Typically In Scope

  • Production infrastructure: Servers, databases, storage, networking
  • Application code: The software that delivers your service
  • Supporting systems: CI/CD, monitoring, logging, alerting
  • Identity systems: Authentication, authorization, SSO
  • Security tools: Firewalls, WAF, SIEM, endpoint protection
  • Backup systems: Backup infrastructure and processes
  • Corporate systems: Email, identity provider, HR systems (as they relate to in-scope controls)

What's Typically Out of Scope

  • Development environments: Often excluded if properly isolated from production
  • Internal tools: Systems that don't process customer data
  • Marketing systems: Website, marketing automation (unless they handle customer data)
  • Legacy products: Sunset products not offered to new customers

Boundary Decisions

System Include If... Exclude If...
Staging environment Contains customer data, uses production credentials Isolated with synthetic data only
Corporate laptops Have direct access to production systems Access only via hardened jump boxes
Third-party integrations Process or store customer data Only used for internal purposes
Customer-managed systems You're responsible for them Customer responsibility (document as User Entity Controls)

Subservice Organizations

A subservice organization is a third party whose services are part of your system. Common examples:

  • Cloud providers: AWS, Azure, GCP
  • Data centers: Colocation facilities
  • SaaS tools: Auth0, Okta, Datadog
  • Managed services: Managed database, managed Kubernetes
  • Payment processors: Stripe, Adyen

Identifying Subservice Organizations

Ask: "Which third parties perform functions that are part of my service delivery?"

A vendor becomes a subservice organization when:

  • Their controls are necessary for your system to operate
  • They process, store, or transmit customer data on your behalf
  • Failures in their controls would affect your ability to meet Trust Services Criteria

Not All Vendors Are Subservice Organizations

General suppliers (office supplies), professional services (legal, accounting), or internal tools (Slack, Notion) are typically not subservice organizations unless they directly impact your service delivery to customers.

Carve-Out vs Inclusive Method

When you have subservice organizations, you must choose how to present them in your SOC 2 report.

Carve-Out Method

The subservice organization's controls are excluded from your report. You describe what the subservice organization does, but the auditor doesn't test their controls.

When to use:

  • The subservice organization has their own SOC 2 (e.g., AWS, Azure, GCP)
  • You can't access their systems for testing
  • Most common approach

What you must do:

  • Describe the subservice organization in your system description
  • List "Complementary Subservice Organization Controls" (CSOCs) - controls you expect them to have
  • Monitor their SOC 2 reports
  • Implement controls over the relationship

Inclusive Method

The subservice organization's controls are included in your report. Your auditor tests their controls as part of your examination.

When to use:

  • You have access to the subservice organization's systems
  • They don't have their own SOC 2
  • Rare in practice

Requirements:

  • Auditor needs access to their systems and evidence
  • Coordination with subservice organization
  • Additional audit scope and cost
Practical Reality

Almost everyone uses carve-out for major cloud providers (AWS, Azure, GCP) because they have their own SOC 2 reports. You rely on their SOC 2 and implement controls over your use of their services.

Complementary Subservice Organization Controls (CSOCs)

When using carve-out, you must list controls the subservice organization is expected to have. For example, if AWS is carved out:

  • "The subservice organization has controls over physical access to data centers."
  • "The subservice organization has controls over environmental protections."
  • "The subservice organization has controls over network security."

Customers reviewing your report understand these controls are AWS's responsibility, documented in AWS's own SOC 2.

Common Scoping Questions

Should we include all products?

Not necessarily. Focus on products customers are asking about. You can have a SOC 2 covering your main product while excluding a new beta product or legacy system being sunset.

What about acquired companies?

Acquisitions create complexity. Options include:

  • Integrating them into your scope (requires control alignment)
  • Excluding them initially with a plan to integrate
  • Maintaining separate SOC 2 reports

Can we exclude certain data types?

Scope is by system, not data type. If a system processes both in-scope and out-of-scope data, the system is in scope.

What about multi-tenant architecture?

Your SOC 2 typically covers the entire platform, not individual customer tenants. Controls should address tenant isolation and multi-tenancy security.

How do we handle User Entity Controls (UECs)?

UECs are controls your customers must implement for the system to operate securely. Document them in your report so customers understand their responsibilities. Examples:

  • "User entities are responsible for managing user access to their account."
  • "User entities are responsible for protecting their API credentials."
  • "User entities are responsible for configuring security features appropriately."

Scope definition is a business decision supported by audit requirements. Include what customers need covered, exclude what's genuinely separate, and be transparent about boundaries.

SOC 2 Scope Subservice