Scoping a SOC 2 Engagement and Defining the System - Understanding SOC 2 Attestations: From Basics to Audit Readiness

1. What Does “System” Mean in SOC 2?

In SOC 2, “the system” is a very specific term.

According to the AICPA’s SOC 2 guidance (latest criteria as of 2024–2025), the system is the set of:

Services you provide to users (e.g., a SaaS application)
Processes and procedures (automated and manual)
People (roles, not necessarily individual names)
Data (types of information processed, stored, transmitted)
Infrastructure (networks, servers, cloud resources)
Software (applications, code, third‑party components)

that are relevant to the services described in the SOC 2 report.

In other words, the system is not your entire company. It is the part of your organization that delivers the in‑scope services and supports the in‑scope Trust Services Categories (TSC).

From your earlier modules:

The TSC (Security, Availability, Processing Integrity, Confidentiality, Privacy) define what controls are evaluated.
The system description in the SOC 2 report explains where those controls live and what they apply to.

For this module, remember:

> Scoping = deciding what is included in “the system” for the SOC 2 examination.

2. Start with the Service: What Are You Actually Attesting To?

The most practical way to scope a SOC 2 is to start with a single, clearly defined service.

Ask:

What user-facing service are we attesting to?

Examples: “Multi-tenant CRM SaaS platform delivered via web and API”, “Managed database hosting service”.

Who are the intended report users?

Customers? Their auditors? Regulators? Internal stakeholders?

What commitments or system requirements have we made to those users?

In contracts, SLAs, privacy notices, security pages, RFP responses.

These answers drive which parts of your environment must be in scope.

A simple mental model:

> If a customer would reasonably assume it is covered by your SOC 2, it probably belongs in scope.

This is where organizations often make a mistake: either

Too narrow (leaving out critical components or locations), or
Too broad (including legacy or unrelated products, which increases cost and effort without adding value).

3. Thought Exercise: Define the Service in One Sentence

Imagine you work for CloudGrade, a fictional company.

CloudGrade offers:

A web-based learning analytics platform for universities
A separate mobile note-taking app for individual students (B2C)

CloudGrade is planning its first SOC 2 Type II examination.

Activity:

Write a one-sentence description of the service you think should be in scope for the first SOC 2.
Decide whether the mobile note-taking app should be in scope or out of scope for this first engagement.

Use this checklist to justify your decision:

Which product generates most customer due-diligence requests?
Which product has enterprise contracts and security questionnaires?
Which product has higher data sensitivity from customers’ perspective?

Reflect (no need to be perfect):

Would your scope decision make the report more useful to CloudGrade’s target customers, or just harder and more expensive?

4. Drawing System Boundaries: People, Processes, Technology, Data

Once you’ve picked the service, you need to draw the system boundary.

Think in four layers:

People (Who operates or affects the system?)

In scope: SRE/DevOps team, security team, customer support, engineers deploying code to the in-scope service.
Out of scope: HR staff, marketing team for unrelated products, finance team (unless they manage relevant billing systems).

Processes (What activities support the service?)

In scope: change management, incident response, access provisioning, backup and restore, vulnerability management related to the in‑scope system.
Out of scope: processes that only affect out-of-scope products.

Technology / Infrastructure

In scope: production VPCs, Kubernetes clusters, CI/CD pipelines, logging/monitoring for the in‑scope service, identity provider (e.g., Okta, Azure AD) used to access it.
Out of scope: internal lab environments, separate networks for unrelated internal tools.

Data

In scope: customer data processed by the service, system logs that store customer identifiers, backups containing customer data.
Out of scope: fully segregated data for a different product, if not part of the service being attested.

A helpful rule:

> If a failure in a component could reasonably violate your commitments under the selected Trust Services Categories, that component should be inside the system boundary.

5. Example: Scoping a SaaS CRM on AWS

Consider SalesFlow, a fictional B2B SaaS CRM hosted on AWS.

Service in scope (system):

> “SalesFlow multi-tenant CRM SaaS platform available via web and REST API, hosted in AWS US regions, used by enterprise customers to manage sales pipelines and customer contacts.”

Included in the system boundary:

People: DevOps engineers, application developers, security team, customer support staff with access to customer data.
Processes: deployment and release management for SalesFlow, incident response, vulnerability management, access reviews, backup and restore procedures.
Technology:
AWS accounts and VPCs hosting the production app and databases
CI/CD pipeline used to build and deploy SalesFlow
Centralized logging and monitoring tools used to detect incidents in SalesFlow
Identity provider used for employee access to production
Data:
Customer CRM data (contacts, opportunities)
Application and access logs containing customer identifiers
Backups of production databases

Explicitly out of scope (documented in the description):

A separate marketing website hosted on a different platform
An internal HR system used only by employees
A beta experimental product not yet sold to customers

The SOC 2 system description would clearly state these inclusions and exclusions so readers know exactly what the opinion covers.

6. Subprocessors, Third Parties, and Locations

Modern SOC 2 reports almost always involve cloud and third‑party services. These are often called subservice organizations or subprocessors (the latter term is more common in privacy/GDPR contexts).

Examples:

Cloud providers (AWS, Azure, GCP)
Payment processors (Stripe, Adyen)
Email delivery services (SendGrid)
Logging/monitoring services (Datadog, New Relic)
Customer support platforms (Zendesk, Intercom)

For each third party that is critical to the in‑scope service, management and the auditor decide:

Is this subservice organization part of the system?

Generally yes, if it is essential for delivering the service.

Carve‑out vs. inclusive method (AICPA terminology):

Carve‑out (most common):
You describe the subservice organization and the controls you rely on them for.
The auditor does not test controls at the subservice organization.
You implement complementary subservice organization controls (CSOCs) like vendor due diligence, review of their SOC reports, and contract clauses.
Inclusive (less common):
The subservice organization agrees to be included in your SOC 2.
The auditor tests controls at both your organization and the subservice organization.

Locations

Physical offices where in‑scope staff work (especially if they access production systems).
Data center or cloud regions where data is stored/processed.
Remote work considerations (common after 2020): how secure remote access is controlled.

Your system description must clearly state:

Which subservice organizations are relevant
Whether they are treated under carve‑out or inclusive method
The locations that are in scope for the examination

7. Selecting Trust Services Categories (TSC) for the Engagement

By current AICPA guidance:

Security (also called Common Criteria) is always included in SOC 2.
Availability, Processing Integrity, Confidentiality, Privacy are optional, based on your services and commitments.

How to choose TSC in a practical way:

Security (required)

Covers: access control, change management, logging/monitoring, risk management, incident response, etc.

Availability

Choose this if you make uptime or performance commitments (e.g., 99.9% SLA, RTO/RPO promises) that customers care about.

Processing Integrity

Choose this if customers rely on you for complete, accurate, timely, and authorized processing of transactions or data (e.g., financial transactions, order processing, automated calculations).

Confidentiality

Choose this if you handle sensitive but not necessarily personal data (e.g., trade secrets, proprietary business data) and you make explicit confidentiality commitments.

Privacy

Choose this if you collect, use, store, disclose, and dispose of personal information and you make privacy commitments (e.g., privacy notices, data subject rights, cross‑border transfers).

Note: The AICPA privacy criteria are based on the GAPP framework and are distinct from, but related to, regulations like GDPR or CCPA.

Strategic considerations:

More categories = broader assurance but more work (more controls to design, operate, and evidence).
Many first‑time SOC 2 reports focus on Security only, then add Availability or Confidentiality in later years as the program matures.

Always align TSC selection with:

What customers actually ask for in RFPs and contracts
What your marketing and sales materials already claim
Your organization’s real capabilities (avoid over‑committing)

8. Timeframe and Type II Period: 6–12 Months in Practice

You learned earlier:

Type I: controls at a point in time (design only)
Type II: controls over a period of time (design and operating effectiveness)

For Type II SOC 2 examinations, the review period is typically:

Minimum: 3 months (rare, usually only for first-time reports)
Common range: 6–12 months
Maximum: Often 12 months, because users want current assurance

As of late 2025, most mature SaaS companies aim for:

A 9–12 month period once the program stabilizes, so customers see performance over almost a full year.

Implications of choosing the period length:

Shorter period (e.g., 6 months):
Easier for a first report
Less historical evidence to gather
But some customers may prefer a longer period
Longer period (e.g., 12 months):
Stronger signal of ongoing control operation
More effort to manage exceptions and documentation

Important: the period must be continuous and clearly stated in the report (e.g., “For the period from January 1, 2024 to December 31, 2024”).

9. Scope Trade-offs: Effort, Cost, and Usefulness

Consider a mid‑size SaaS company, DataBridge, planning its first SOC 2 Type II.

DataBridge options:

Option A (Narrow scope)

Service: Only the core data integration platform
TSC: Security only
Period: 6 months

Option B (Moderate scope)

Service: Data integration platform + managed connectors marketplace
TSC: Security + Availability
Period: 9 months

Option C (Broad scope)

Service: All products (including beta labs)
TSC: Security + Availability + Confidentiality + Privacy
Period: 12 months

Your task:

Rank the options (A, B, C) from lowest to highest in terms of:

Implementation effort
Audit cost and complexity
Usefulness to large enterprise customers

For each option, write a one‑sentence note on who would benefit most:

Early‑stage startups as customers?
Large regulated enterprises?
Internal stakeholders (e.g., the board)?

Reflect:

If you were the CISO at DataBridge, which option would you pick for year 1, and what would your 3‑year roadmap look like (e.g., start with A, then move to B)?

10. Quick Check: What Belongs in Scope?

Answer this question to test your understanding of system boundaries and scope choices.

Your company provides a SaaS HR platform. It uses AWS for hosting, Stripe for billing, and a separate marketing website on a different domain. For your SOC 2 report over the HR platform, which of the following is MOST appropriate?

Include the HR platform, AWS infrastructure, and Stripe as subservice organizations; exclude the marketing website from the system description.
Include the HR platform, AWS infrastructure, Stripe, and the marketing website all as part of the system, because they are all owned by your company.
Include only the HR application code; exclude AWS, Stripe, and the marketing website because they are not directly controlled by your developers.

Show Answer

Answer: A) Include the HR platform, AWS infrastructure, and Stripe as subservice organizations; exclude the marketing website from the system description.

Option 1 is correct. The system should include the HR platform and the critical third parties (AWS, Stripe) as subservice organizations, with their roles and your complementary controls described. The marketing website is not part of the HR service being attested and can be explicitly excluded. Ownership alone does not determine scope (so option 2 is wrong), and excluding AWS/Stripe would ignore key dependencies (so option 3 is wrong).

11. Flashcards: Key Scoping Terms

Use these flashcards to reinforce key terminology related to scoping a SOC 2 engagement.

System (in SOC 2 context): The combination of services, processes, people, data, software, and infrastructure that are relevant to the services described in the SOC 2 report and to the selected Trust Services Categories.
System Boundary: The conceptual line that defines which components (people, processes, technology, data, locations) are included in the SOC 2 examination and which are excluded.
Subservice Organization (Subprocessor): A third-party service provider that performs functions for the service organization and is relevant to the system and Trust Services Criteria (e.g., cloud provider, payment processor).
Carve-out Method: A method where the subservice organization is described in the SOC 2 report, but the auditor does not test its controls; instead, the report describes the complementary subservice organization controls the service organization implements.
Inclusive Method: A method where the subservice organization’s relevant controls are included and tested as part of the service organization’s SOC 2 examination.
Trust Services Categories (TSC): The AICPA’s categories—Security (required), Availability, Processing Integrity, Confidentiality, and Privacy—used to organize control objectives and criteria in SOC 2.
Type I vs. Type II: Type I reports on the design of controls at a point in time; Type II reports on the design and operating effectiveness of controls over a defined period (commonly 6–12 months).
In-scope Location: A physical or logical location (e.g., office, data center, cloud region) where in-scope system components or personnel reside and that is included in the SOC 2 examination.

Key Terms

System: In SOC 2, the set of services, processes, people, data, software, and infrastructure that support the in-scope services and are relevant to the selected Trust Services Categories.
Type I Report: A SOC 2 report that evaluates the design of controls at a specific date.
Type II Report: A SOC 2 report that evaluates the design and operating effectiveness of controls over a defined review period, commonly 6–12 months.
System Boundary: The defined perimeter of what is included in the SOC 2 examination, covering specific services, components, and locations.
Carve-out Method: An approach where the subservice organization is described but its controls are not directly tested; instead, the service organization’s complementary controls are evaluated.
Inclusive Method: An approach where the subservice organization’s relevant controls are included within the SOC 2 examination and tested by the auditor.
In-scope Location: Any physical site or cloud environment where in-scope system components or personnel are located and that is included in the SOC 2 engagement.
Subservice Organization: A third-party service provider that performs functions for the service organization and is relevant to the system and SOC 2 criteria (often called a subprocessor).
Trust Services Categories (TSC): The AICPA’s categories—Security, Availability, Processing Integrity, Confidentiality, and Privacy—that structure SOC 2 criteria and controls.
Complementary Subservice Organization Controls (CSOCs): Controls that the service organization implements to manage risks related to relying on a subservice organization, such as vendor due diligence and review of their SOC reports.