SOC 2 scope refers to the system description, the specific products, services, infrastructure components, people, and processes included in your SOC 2 audit. Everything within scope is tested by the auditor. Everything outside scope is not. A SOC 2 report is only as credible as its scope, if critical systems are excluded, enterprise buyers will notice and push back.

How do I define my SOC 2 system description?

Your system description documents the five components of your system: infrastructure (cloud accounts, servers, networks), software (applications, code, databases), people (employees with system access), procedures (processes for managing the system), and data (types of data processed). The description should be specific enough that an auditor can test controls against it and a customer can understand what is covered.

Can I exclude parts of my product from SOC 2 scope?

Yes, but exclusions must be documented and defensible. You can exclude systems that do not process customer data, development environments that are properly isolated from production, and products that are genuinely separate systems. However, if you exclude something important, like your primary production database or a security-critical component, enterprise buyers will flag it during security reviews. Scope carve-outs are visible in the report.

Do third-party services count as in scope for SOC 2?

Third-party services you rely on (AWS, Okta, GitHub, etc.) are subservice organizations. They are not in scope for your audit, but your auditor will verify that you have appropriate vendor management controls (CC9.1) and that you rely on their SOC 2 reports or equivalent assurance. The key question is: are the controls at your subservice organization complementary to your controls, and have you reviewed their assurance reports?

What happens if my SOC 2 scope is too narrow?

Overly narrow scope creates credibility problems with enterprise buyers. If your SOC 2 report covers only one of your three products, or excludes your primary cloud infrastructure, a security-savvy procurement team will notice. They may ask for a broader report, require compensating controls documentation, or disqualify your report entirely. Scope decisions made to minimize audit cost often backfire in the sales cycle.

SOC 2 scope definition: how to define your system and avoid audit surprises

Scope is the first major decision in a SOC 2 audit, and it is one that most teams underestimate. Get it wrong in either direction, too broad or too narrow, and you either face an unmanageably large audit or a report your enterprise customers will not accept.

Poor SOC 2 scope definition wastes $40K on out-of-scope systems

This guide explains how to define your SOC 2 scope correctly.

What scope actually means

SOC 2 scope is your system description: the specific set of products, services, infrastructure, people, and processes that your auditor will evaluate. The system description is included in your SOC 2 report and is visible to every customer and prospect you share it with.

When an enterprise buyer's security team reviews your SOC 2 report, the first thing they read is the system description. They are looking for:

Does this report cover the product we are buying?
Does it include the infrastructure where our data lives?
Are there obvious exclusions that create gaps?

A report that covers "Product A and its associated AWS us-east-1 infrastructure" when you are selling them Product B and running it in eu-west-1 is not useful to them.

The five components of your system

AICPA's framework defines a system as five components:

01Infrastructure

Your cloud accounts, servers, networks, and physical facilities. For a SaaS company, this typically means:

Cloud provider accounts (AWS, GCP, Azure), specify regions
Production environment (accounts, VPCs, subnets)
Development and staging environments (typically excluded if properly isolated)
Office network and physical facilities (if employees access systems from office)
CDN, DNS, and other infrastructure services

02Software

The applications, code, and databases that make up your service:

Production application code (specify repositories or services)
Databases containing customer data
Third-party software running in your infrastructure
Internal tools that employees use to manage production

03People

Everyone with access to in-scope systems:

Engineering team with production access
DevOps and SRE teams
Customer support with access to customer data
Executives with admin access
Contractors with relevant access

04Procedures

The documented processes governing your system:

Change management process
Incident response procedures
Access provisioning and deprovisioning
Vulnerability management process
Business continuity and disaster recovery

05Data

Types of data your system stores and processes:

Customer data (categorize: personal information, transaction data, content data)
Employee data
Configuration and operational data
Logs and audit data

Document these five components before your readiness assessment. Your auditor will use this description to define what gets tested.

Common scope decisions

What to include

Always include:

Your primary production environment (the one where customer data lives)
All infrastructure components that production depends on (databases, caches, queues, CDN)
All products that customers of your target market use
All employees with production system access
Your security and DevOps tools (SIEM, vulnerability scanner, MDM)

Usually include:

The identity provider used for production access (Okta, Azure AD)
Your code repository and CI/CD pipeline (GitHub, GitLab, CircleCI)
Your support tooling if it provides access to customer data (Zendesk, Intercom)
Your cloud monitoring tools (Datadog, CloudWatch, PagerDuty)

What you can reasonably exclude

Development and staging environments: If development and staging are properly isolated from production (separate accounts, separate networks, no production data in staging), they can be excluded. Document the isolation.

Products in early beta or sunset: If a product is genuinely separate, has no production customer data, or is being shut down, you can carve it out. Be prepared for a customer to ask why.

Acquired products not yet integrated: If you acquired a company and their product runs on separate infrastructure under separate controls, it may be appropriate to exclude during the transition period. This requires a clear plan for future inclusion.

The subservice organization approach

Many critical dependencies are not in scope because they are subservice organizations, third parties that provide services your system depends on. AWS, GCP, Azure, Okta, GitHub, and similar providers are subservice organizations. Your auditor will not audit them, but you must:

Identify them in your system description: List your subservice organizations and what they provide
Obtain their assurance reports: Review their SOC 2 reports annually (AWS, GitHub, Okta all publish theirs)
Document complementary controls: Your controls that compensate for what you cannot control at the subservice organization (e.g., your encryption is your control, not AWS's)

Scope creep and scope management

Expanding scope mid-audit

The most common scope mistake is expanding scope mid-audit without thinking through the implications. This happens when:

Engineering deploys a new service mid-observation period that accesses customer data
A new third-party integration creates a data flow that was not in the original scope
A new cloud region is added mid-period

All material changes to your system during the audit period must be disclosed in your system description. Major changes that occur mid-period can require the auditor to expand testing or note the change as a scope consideration.

To avoid scope surprises: define scope before your observation period begins and communicate it to your engineering team. Changes to production that affect customer data should go through a process that includes notifying your compliance function.

Writing your system description

The system description in your SOC 2 report is written by you (or your compliance platform) and reviewed by your auditor. It is part of management's assertion, you are representing that the description accurately reflects your system.

A good system description:

Specifies the products and services covered ("the Acme web application, including the customer dashboard, background processing pipeline, and public API")
Names the infrastructure ("AWS us-east-1, including EC2, RDS PostgreSQL, ElastiCache Redis, and S3")
Identifies the data types processed ("Compliance evidence data, audit log records, and organization configuration data for B2B customers")
Lists principal subservice organizations ("AWS for infrastructure hosting, GitHub for source code management and CI/CD, Okta for identity and access management")
Notes any carve-outs and why

Your auditor will help refine the system description, but you should draft it, you know your system better than they do.

Keeping evidence aligned to your defined scope as the stack changes is ongoing work a fractional CISO owns for you, so scope creep never surprises your auditor. Book a call to pin down your scope.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.