How to Define Your SOC 2 Audit Scope

Key Takeaways

Point	Summary
Scope determines effort	Broader scope means more systems, controls, and evidence to manage
Start focused	Many organizations begin with their core product and primary infrastructure
Customer requirements matter	Let your customers' needs guide what you include
Systems, not just criteria	Scope includes which systems, services, and infrastructure are covered
Document thoroughly	Clear scope documentation helps avoid surprises during the audit

Quick Answer: SOC 2 scope defines which systems, services, and Trust Services Criteria are included in your audit. Starting with a focused scope covering your core product and primary customer data handling is often the most effective approach for first-time audits.

What Is SOC 2 Scope?

Your SOC 2 scope has two main dimensions:

1. Trust Services Criteria (TSC)

Which criteria are included:

• Security (required for all SOC 2 audits)
• Availability (optional)
• Processing Integrity (optional)
• Confidentiality (optional)
• Privacy (optional)

See our Trust Services Criteria guide for details on each criterion.

2. Systems and Infrastructure

Which systems, services, and infrastructure are covered:

• Production applications and databases
• Cloud infrastructure (AWS, GCP, Azure accounts)
• Supporting services and integrations
• Internal tools that process customer data
• People and processes

Why Scope Matters

For Your Audit

Scope Impact	Consideration
Complexity	More systems = more controls to document and test
Timeline	Broader scope can extend implementation time
Cost	More comprehensive scope typically increases investment
Evidence burden	More systems mean more evidence to collect and maintain

For Your Customers

Scope Impact	Consideration
Coverage	Scope should cover what customers care about
Credibility	Scope should meaningfully address your service
Questions	Customers may ask why certain things are excluded

Common Scope Patterns

Pattern 1: Core Product Focus

Includes:

• Primary customer-facing application
• Production database
• Supporting cloud infrastructure
• CI/CD pipeline
• Employee systems that access production

Excludes:

• Internal tools not touching customer data
• Development and staging environments
• Marketing and sales systems

Best for: First-time SOC 2, focused product companies

Pattern 2: Full Platform Coverage

Includes:

• All customer-facing products and services
• All supporting infrastructure
• Data processing pipelines
• Analytics and reporting systems
• Internal tools accessing customer data

Best for: Mature organizations with multiple products, enterprise customers with comprehensive requirements

Pattern 3: Specific Service Focus

Includes:

• One specific service or product line
• Only the infrastructure supporting that service
• Relevant employee access

Excludes:

• Other products or services
• Unrelated infrastructure

Best for: Organizations with multiple distinct products serving different markets

How to Determine Your Scope

Step 1: Understand Customer Requirements

Start by understanding what your customers actually need:

• Review security questionnaires you've received
• Identify common themes in customer security requirements
• Consider which systems customers are most concerned about
• Note any specific criteria customers request

Step 2: Map Your Data Flows

Document how customer data moves through your systems:

• Where does data enter your systems?
• Where is it stored?
• What processes access it?
• Where does it leave your systems?
• What third parties are involved?

Step 3: Identify Critical Systems

Determine which systems are essential to include:

System Category	Questions to Ask
Applications	Which applications handle customer data?
Databases	Where is customer data stored?
Infrastructure	What cloud accounts and services support production?
Integrations	What third-party services process customer data?
People	Who has access to customer data and systems?

Step 4: Define Boundaries

Create clear boundaries for what's in and out of scope:

In scope:

• Systems that store, process, or transmit customer data
• Infrastructure supporting those systems
• People with access to those systems
• Third parties that handle data on your behalf

Potentially out of scope:

• Development environments (unless they have production data access)
• Internal tools not accessing customer data
• Marketing and sales systems
• Corporate systems unrelated to service delivery

Scope Considerations by Criterion

Security (Required)

Always included. Covers:

• Access controls
• Change management
• Vulnerability management
• Incident response
• Physical and environmental controls

Availability

Consider including if:

• You have SLAs with customers
• Uptime is critical to your service
• Customers ask about availability

Adds:

• Capacity planning
• Disaster recovery
• Business continuity
• Performance monitoring

Processing Integrity

Consider including if:

• You process transactions or calculations
• Data accuracy is critical
• Customers depend on correct processing

Adds:

• Data validation
• Processing accuracy controls
• Error handling
• Reconciliation procedures

Confidentiality

Consider including if:

• You handle sensitive business information
• Customers share proprietary data
• Confidentiality commitments exist

Adds:

• Data classification
• Confidentiality agreements
• Data handling procedures
• Disclosure controls

Privacy

Consider including if:

• You process personal information
• GDPR or similar regulations apply
• Customers require privacy attestation

Adds:

• Privacy notice requirements
• Consent management
• Data subject rights
• Privacy impact assessments

Common Scope Mistakes

Mistake 1: Over-Scoping

Problem: Including too many systems or criteria creates unnecessary complexity.

Solution: Start focused. You can expand scope in subsequent years based on customer feedback.

Mistake 2: Under-Scoping

Problem: Excluding systems that customers expect to be covered.

Solution: Ensure scope covers your core service and primary customer data handling. Check customer requirements.

Mistake 3: Unclear Boundaries

Problem: Ambiguous scope creates audit issues and customer confusion.

Solution: Document scope clearly with specific systems named. Review with your auditor before starting.

Mistake 4: Ignoring Subservice Organizations

Problem: Third parties that process data on your behalf aren't considered.

Solution: Identify all subservice organizations. Either include their controls or rely on their SOC 2 reports (carve-out method).

Subservice Organizations

If you use third-party services that handle customer data, you have two approaches:

Inclusive Method

You take responsibility for the third party's controls:

• More complex
• Requires testing their controls
• Greater assurance to customers

Carve-Out Method

You rely on the third party's own SOC 2 report:

• More common approach
• Simpler to manage
• Reference their report in yours

Most organizations use the carve-out method for major cloud providers (AWS, GCP, Azure) and other SOC 2-certified vendors.

Documenting Your Scope

Your scope documentation should include:

System Description

• Overview of services provided
• Components of the system
• Principal service commitments
• System requirements
• Applicable trust services criteria

Boundaries

• Specific systems and applications included
• Infrastructure covered
• Types of data in scope
• Subservice organizations and method used
• What is explicitly out of scope

Trust Services Criteria

• Which criteria are included
• Rationale for inclusion/exclusion

Scope Changes Over Time

Expanding Scope

Common reasons to expand:

• Customer requests for additional criteria
• New products or services
• Regulatory requirements
• Competitive considerations

Process:

• Identify what's being added
• Implement additional controls
• Update documentation
• Include in next audit cycle

Narrowing Scope

Be cautious about narrowing scope:

• Customers may question removed elements
• May require explanation
• Consider timing carefully

Working with Your Auditor

Before the Audit

• Review proposed scope with auditor
• Confirm auditor understanding of your systems
• Agree on boundaries
• Clarify subservice organizations

During Scoping

• Walk through system architecture
• Identify data flows
• Confirm system boundaries
• Document any assumptions

Scope Changes Mid-Audit

• Communicate changes promptly
• Understand impact on timeline
• Update documentation accordingly

The Bastion Approach to Scoping

We help you define the right scope through:

• Customer requirements analysis - Understanding what your customers actually need
• System mapping - Documenting your data flows and critical systems
• Criteria recommendation - Advising on which Trust Services Criteria make sense
• Boundary definition - Creating clear, defensible scope boundaries
• Documentation - Preparing comprehensive scope documentation

Our goal is a scope that meaningfully addresses customer requirements without unnecessary complexity.

---

Have questions about defining the right scope for your SOC 2? Talk to our team

---

Sources

• AICPA Trust Services Criteria - Official criteria definitions and guidance
• AICPA SOC 2® Guide - Comprehensive guidance on scoping and system descriptions