# SOC 2 Scope: Systems, People, and Processes. The Complete Guide

Source: https://truvocyber.com/blog/soc-2-scope-systems-people-processes
Published: 2026-06-20
Topic cluster: SOC 2

> Learn how to define SOC 2 scope across systems, people, and processes, and the scoping mistakes that cost audit time.

SOC 2 scope answers three questions: which systems the audit covers, which people, and which processes. Systems are one third of the answer.

SOC 2 scope covers three areas:

- 

systems (the technology stack and infrastructure)

- 

people (employees, contractors, and subservice organizations)

- 

processes (the policies and procedures that govern how the service operates)

First-time audits can go sideways when the company over-scopes one area, under-scopes another, or finds the mismatch only when the auditor starts asking questions.

**SOC 2 Scope Covers Systems, People, and Processes**

We often see teams define scope once, around systems. A sound scope covers systems, people, and processes before any controls work starts, so the auditor samples from a settled boundary.

 

## What SOC 2 Scope Means

A SOC 2 report is issued under the AICPA's Trust Services Criteria. The audit assesses a specific service and whether the controls protecting that service meet the criteria in the report.

The System Description, a formal section at the front of the SOC 2 report, describes the service. The System Description answers five questions: what the service does, which systems support the service, who has access, how the service is operated, and which controls are in place. Everything in scope appears in the System Description with controls mapped to each component. Everything out of scope needs no audit evidence.

For a system split between a cloud account and on-prem hardware, the guide to [SOC 2 scoping and the system description for hybrid and on-prem infrastructure](https://truvocyber.com/blog/soc-2-hybrid-on-prem-scoping) covers where the boundary goes and what the description must show on each side.

The auditor tests whether controls were designed appropriately and, for a Type 2 audit, whether the controls operated effectively over the audit period. Testing covers only what falls inside the scope boundary. Scope decisions therefore set how much evidence the team collects, how many people go through access reviews, and how many systems need to meet configuration baselines.

A scope that is too broad puts the team on compliance work for systems and people outside the service. A scope that is too narrow leads the auditor to undisclosed gaps, and those gaps can end up in the audit opinion.
 

## SOC 2 Systems Scope: Infrastructure, Applications, and Data

Systems scope covers every component of the technical stack that supports the in-scope service: production infrastructure, application code, data stores, cloud provider accounts, networking, and third-party integrations that handle production data.

For a typical SaaS application, the in-scope system includes:

- Production cloud accounts and regions (AWS, GCP, Azure, or equivalents)

- Application servers and managed services (compute, containers, serverless functions)

- Databases and storage that hold customer data

- Identity and access management infrastructure (IdP, SSO, MFA enforcement)

- Logging and monitoring infrastructure (SIEM, CloudTrail, audit logs)

- CI/CD pipeline components with production deployment access

- Networks and firewalls governing production traffic

- Email and productivity tools such as Microsoft 365 and Google Workspace

WHAT CAN BE EXCLUDED FROM SOC 2 SYSTEMS SCOPE

**Development and test environments**

Dev and test environments can be excluded when isolated from production: no production data in test, no shared credentials between environments, and no access path from dev tooling into production. When developers use the same credentials for dev and production, the environments are connected and the exclusion fails under audit.

**Backup and disaster recovery**

Backup and disaster recovery systems are typically in scope because they hold copies of production data. When a third party operates backups entirely, the company still documents the third party's controls, so the exclusion moves the documentation work to vendor oversight.

**Internal tooling, HR, finance, and marketing platforms**

Internal tools and HR, finance, and marketing platforms are out of scope by default when they have no access path to the in-scope service's data or infrastructure. The test for any system: can the system access, modify, or disrupt production data or the production environment? If the answer is no, the system is a candidate for exclusion.

 

## SOC 2 People Scope: Who Is in the Compliance Population

People scope covers everyone whose role or access affects the in-scope service. At a SaaS company of under 50 people, everyone on staff is usually in scope, because nearly every role at that size touches production, customer data, or the identity and HR systems that control access. At larger companies, people scope depends on which teams support the service.

SOC 2's people controls focus on who has access to in-scope systems and data. CC6.1 addresses logical and physical access to systems. CC6.2 and CC6.3 cover how access is granted, reviewed, and removed. These criteria apply to the in-scope system.

**The SOC 2 Compliance Population Depends on Company Size**

Below about 50 people, the compliance population is usually the whole company. In a 200-person company where 60 people (30%) work in a separate consulting practice with no access to the SaaS product or customer data, those 60 are out of scope for system controls and the other 140 are in.

**What applies company-wide:**

- Policy acceptance (security policy, acceptable use, confidentiality agreements)

- Security awareness training

- Background checks at hire

Policy acceptance, training, and background checks apply organization-wide as baseline commitments for every person in the company, regardless of system access.

**What larger companies can limit to the compliance population:**

- Device management and endpoint compliance (only devices that access in-scope systems need to meet the configuration baseline)

- Access reviews (only accounts with production or sensitive data access are sampled)

- User-specific audit testing (the auditor samples from people who are material to the in-scope service)

**How larger companies draw the people boundary:**

Identity groups in the IdP give the clearest boundary. A group that maps to the compliance population creates an auditable line: users in the group get the full control set, and users outside the group are excluded from device management, access reviews, and user-level testing.

An internal engineering team that releases code to production stays in scope, as the guide to [leaving an internal team out of SOC 2 scope](https://truvocyber.com/blog/soc-2-scope-internal-teams) explains.

Group membership needs technical enforcement as well as documentation. When someone outside the compliance group can still get production access through an informal request, the boundary fails. Auditors check that the boundary is technical and demonstrable. The [SOC 2 people scoping guide](/blog/soc-2-scoping) covers employees, contractors, and vendors by company size and role.

**Subservice organizations:**

Subservice organizations are third parties that perform functions material to the service: cloud infrastructure providers, database-as-a-service vendors, CDNs. Subservice organizations appear in the System Description because their controls are part of the overall control environment.

A neocloud hosting GPU workloads is one more subservice organization, and the guide to [SOC 2 on a neocloud](https://truvocyber.com/blog/soc-2-neocloud) covers how a neocloud changes the system description and the controls the company owns.

The System Description treats subservice organizations in one of two ways. Under the **carve-out method**, the report notes that the subservice organization performs certain functions but excludes their controls from the audit scope. The reader is directed to the subservice organization's own SOC 2 report for those controls. Under the **[inclusive method](https://truvocyber.com/blog/soc-2-csocs-inclusive-method)**, the subservice organization's controls are included in the audit scope, which means the auditor tests them directly. The inclusive method is uncommon. The auditor needs cooperation and access from the third party, and a provider's published Type 2 report already covers those controls.

AWS, GCP, Azure, and most major infrastructure providers publish Type 2 reports. When using the carve-out method, the company obtains those reports, notes in the System Description that AWS operates the infrastructure under a carve-out arrangement, and directs relying parties to review AWS's own SOC 2 report alongside the company's. No additional testing is required.
 

## SOC 2 Process Scope: Policies and Procedures Auditors Test

Process scope covers the policies and procedures that must be formally documented, maintained, and evidenced as operating during the audit period.

In-scope processes are the formal governance commitments that auditors test: policies that define what the company does, procedures that describe how the work gets done, and controls that show the work happened. Day-to-day operational procedures outside those commitments stay out of scope.

For a baseline SOC 2 audit against the Security criteria (CC1 through CC9), the in-scope processes typically include:

- **Access management:** how access is granted, reviewed, modified, and revoked (CC6.1, CC6.2)

- **Change management:** how changes to the production environment are reviewed, approved, and tracked (CC8.1)

- **Risk management:** how risks are identified, assessed, and monitored over time (CC3.2, CC4.1)

- **Incident response:** how security incidents are detected, contained, and resolved (CC7.3, CC7.4)

- **Vendor management:** how third-party risk is assessed and tracked (CC9.2)

- **Business continuity:** how the service recovers from disruptions (A1.2, if Availability is in scope)

- **Security monitoring:** how the environment is watched for threats and anomalies (CC7.1)

Each in-scope process needs a governing policy that states the company's commitments, plus evidence that the company followed those commitments during the audit period. The policy states what the company commits to. The evidence shows the company did the work.

**Policies vs. Procedures: Keep Them Separate**

Policies state the company's commitments. Procedures describe how to carry them out. When system-specific steps and dashboard instructions live inside a policy document, every infrastructure change triggers a formal policy update with acknowledgment cycles. With procedures in separate documents, procedures change with the environment and the policy stays stable between reviews.

 

## How Trust Services Categories Change SOC 2 Scope

The Security category (the Common Criteria, CC1-CC9) is the only mandatory category for a SOC 2 report. All other Trust Services Categories are optional, and each one added expands the scope of what auditors assess.

Trust Services Category
What it covers
When to add it

**Security (required)**
Access control, risk management, monitoring, change management
Always

**Availability**
Uptime commitments, capacity management, recovery
When customers have contractual uptime requirements

**Confidentiality**
How confidential data is identified, stored, and disposed of
When handling data customers have designated as confidential

**Processing Integrity**
Completeness and accuracy of data processing
When the product processes transactions, calculations, or transforms data

**Privacy**
Handling of personal information under privacy frameworks
When handling consumer PII with stated privacy commitments

Each additional category introduces criteria that must be addressed in the System Description and evidenced during the audit. Adding Availability means the auditor tests uptime monitoring, capacity planning, and recovery testing. Adding Processing Integrity means defining correct processing for the service and proving correct processing with evidence.

For neoclouds, GPU clouds and AI platforms, correct processing describes the compute job itself. The guide to [Processing Integrity for compute and AI infrastructure providers](https://truvocyber.com/blog/soc-2-processing-integrity-compute-providers) covers each criterion.

For a first SOC 2, we usually see Security only, or Security plus Availability for SaaS businesses with uptime SLAs written into customer contracts. Additional categories are easier to add on subsequent renewals once the Security controls are operating cleanly. The [Trust Services Criteria guide](/blog/soc-2-trust-services-criteria-guide) breaks down what each criterion requires.
 

## Common Scoping Mistakes That Cost Extra Audit Time

**Common Mistake: Treating Isolation as a Declaration**

Dev and test environments can only be carved out when they are demonstrably isolated from production: no shared credentials, no production data in test, no access paths that cross the boundary. The boundary must be technically enforced as well as stated in the scope document. Auditors verify the technical boundary.

**Leaving complementary user entity controls undefined.** For multi-tenant SaaS products, the System Description must address what customers are expected to manage on their end. Under CC6.3, when the service delegates user management to tenant administrators, that delegation needs to be explicit. When a tenant admin can grant excessive permissions to a user within the tenant, the System Description should state that managing those permissions is a customer responsibility. An unstated customer responsibility becomes an audit finding.

**Waiting until the audit to explain the team structure.** Auditors draw their testing sample based on the scope communicated at engagement kickoff. If the scope definition comes after initial evidence requests, the auditor has already cast a wider net that includes people and systems outside the intended scope. A clear scope at kickoff keeps the sample to the intended boundary and avoids rework.
 

## How to Document SOC 2 Scope for the Auditor

For a readiness engagement or Type 1 audit, the scope documentation needs to cover five elements:

**The Five Elements of a Complete Scope Statement**

- **The system boundary:** name every in-scope component, cloud accounts, environments, key services, and how they connect. Pair the written description with an architecture diagram the auditor uses as a reference throughout the engagement.

- **The compliance population:** identify who is in scope, employees, contractors, and roles with access to in-scope systems. Name the mechanism enforcing the boundary, whether IdP groups, access policies, or a combination.

- **Subservice organizations:** list every third party performing functions material to the service, specify whether carve-out or inclusive method applies, and note where their own SOC 2 report can be obtained.

- **Complementary user controls:** state explicitly what customers are responsible for, configuring their own user permissions, enabling MFA, maintaining access reviews for their tenant.

- **Out-of-scope exclusions with justification:** an excluded development environment needs the reason the environment is isolated, and an excluded business unit needs the reason the unit has no access to in-scope systems. An exclusion without justification invites the auditor to question the exclusion.

A well-documented scope statement at the beginning of an engagement reduces auditor back-and-forth across multiple review rounds. When the auditor knows what is in and out before sampling begins, testing stays focused on the boundary. The [SOC 2 readiness assessment guide](/blog/soc-2-readiness-assessment-guide) covers how readiness assessments work.
 

## SOC 2 Scoping Comes First in Readiness

SOC 2 scope decisions made at the start of an engagement decide the work that follows. Over-scope systems and the team builds controls for infrastructure outside the service. Over-scope people at a larger company and access reviews cover the wrong headcount. Under-scope processes and the auditor finds governance gaps during fieldwork.

A sound scope covers systems, people, and processes together with the Trust Services Categories in the report, and the team settles scope before building any controls.

A [SOC 2 consultant](https://truvocyber.com/services/soc-2-compliance) can lead this scoping work with the team as the first step of readiness.

### Scope Your SOC 2 Correctly

We build effective security programs around the scope your service and your auditor need.

[Book Your Strategy Call](/contact-us)

 

## Frequently Asked Questions

### What does SOC 2 scope cover?

SOC 2 scope covers three areas: systems (the production infrastructure and technology stack supporting the in-scope service), people (employees, contractors, and subservice organizations with access to in-scope systems), and processes (the policies, procedures, and controls governing how the service operates). The audit evaluates controls within that defined boundary.

### Can I exclude some employees from SOC 2 scope?

At a SaaS company of under 50 people, everyone is usually in scope. Larger companies can limit device management, access reviews, and user-specific audit testing to employees with access to in-scope systems and data. Organization-wide requirements, including policy acceptance, security training, and background checks, still apply to all employees. The boundary should be enforced through IdP groups or access policies as well as stated in the scope document.

### Do dev and test environments need to be in scope?

Dev and test environments can be excluded when isolated from production: no shared credentials, no production data in test, and no access paths that cross the boundary. When any of those conditions fails, the auditor expects controls on the dev and test environments.

### What is the carve-out method for subservice organizations?

Under the carve-out method, the SOC 2 report acknowledges that a subservice organization, such as AWS or a database vendor, performs functions material to the in-scope service but excludes their controls from the audit scope. The reader is directed to the subservice organization's own [SOC 2 Type 2](https://truvocyber.com/blog/what-is-a-soc-2-type-2-report-and-why-is-it-important) report for those controls. The carve-out method is the standard approach for major cloud providers that publish their own reports.

### How many Trust Services Categories should I include?

First-time SOC 2 audits typically cover Security only (CC1-CC9), or Security plus Availability when customer contracts include uptime SLAs. Each additional category expands the audit scope and the evidence required. Additional categories are typically easier to add on renewal once the Security controls are operating cleanly.

### How do I document SOC 2 scope for my auditor?

A complete scope statement covers five elements: the system boundary (all in-scope components and their connections), the compliance population (who is in scope and the mechanism enforcing the boundary), subservice organizations (listed with carve-out or inclusive method specified), complementary user controls (what customers are responsible for), and out-of-scope exclusions with justification. Providing the scope statement before the auditor begins sampling reduces back-and-forth and prevents unnecessary scope expansion.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does SOC 2 scope cover?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SOC 2 scope covers three areas: systems (the production infrastructure and technology stack supporting the in-scope service), people (employees, contractors, and subservice organizations with access to in-scope systems), and processes (the policies, procedures, and controls governing how the service operates). The audit evaluates controls within that defined boundary."
      }
    },
    {
      "@type": "Question",
      "name": "Can I exclude some employees from SOC 2 scope?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "At a SaaS company of under 50 people, everyone is usually in scope. Larger companies can limit device management, access reviews, and user-specific audit testing to employees with access to in-scope systems and data. Organization-wide requirements, including policy acceptance, security training, and background checks, still apply to all employees. The boundary should be enforced through IdP groups or access policies as well as stated in the scope document."
      }
    },
    {
      "@type": "Question",
      "name": "Do dev and test environments need to be in scope?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Dev and test environments can be excluded when isolated from production: no shared credentials, no production data in test, and no access paths that cross the boundary. When any of those conditions fails, the auditor expects controls on the dev and test environments."
      }
    },
    {
      "@type": "Question",
      "name": "What is the carve-out method for subservice organizations?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Under the carve-out method, the SOC 2 report acknowledges that a subservice organization, such as AWS or a database vendor, performs functions material to the in-scope service but excludes their controls from the audit scope. The reader is directed to the subservice organization's own SOC 2 Type 2 report for those controls. The carve-out method is the standard approach for major cloud providers that publish their own reports."
      }
    },
    {
      "@type": "Question",
      "name": "How many Trust Services Categories should I include?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "First-time SOC 2 audits typically cover Security only (CC1-CC9), or Security plus Availability when customer contracts include uptime SLAs. Each additional category expands the audit scope and the evidence required. Additional categories are typically easier to add on renewal once the Security controls are operating cleanly."
      }
    },
    {
      "@type": "Question",
      "name": "How do I document SOC 2 scope for my auditor?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A complete scope statement covers five elements: the system boundary (all in-scope components and their connections), the compliance population (who is in scope and the mechanism enforcing the boundary), subservice organizations (listed with carve-out or inclusive method specified), complementary user controls (what customers are responsible for), and out-of-scope exclusions with justification. Providing the scope statement before the auditor begins sampling reduces back-and-forth and prevents unnecessary scope expansion."
      }
    }
  ]
}