Scope & system boundary
Four questions that decide what your SOC 2 actually covers.
Management draws the line around the system an auditor will examine, and the report describes nothing beyond it. Getting that line right is less about policy and more about answering four plain questions in order: what customers pay for, what it shares with the rest of the company, which outside providers it leans on, and what the customer has to do on their side.
Back to SOC 2 services01 · What customers buy
Question one: what does the customer actually pay for?
Start from the service in the contract and work outwards to everything needed to deliver it.
The AICPA's description criteria, DC 200, expect the system description to cover five kinds of component. Walk each one for the service in question and note where teams usually forget something.
| Component | Typical in-scope items | Often missed |
|---|---|---|
| Infrastructure | Cloud accounts, networks, managed databases, office network if it reaches production | A second cloud account used for backups or analytics |
| Software | The product, its APIs, admin consoles, CI and deployment tooling | Internal scripts that touch customer data directly |
| People | Engineering, operations, support, security, leadership | Contractors and offshore support staff with production access |
| Procedures | Onboarding, change, incident, backup and access processes | Manual steps run from a runbook during releases |
| Data | Customer records, files, logs, backups | Copies in a data warehouse or a support tool |
03 · Outside providers
Question three: which outside providers does the service rely on?
A provider whose controls matter to your criteria is a subservice organisation, and the report must say how it is handled.
| Point of difference | Carve-out method | Inclusive method |
|---|---|---|
| Provider's controls tested in your report | No; its services are described only | Yes, alongside yours |
| What you rely on instead | The provider's own SOC report, which you review | The auditor's testing in your examination |
| What the description adds | A list of controls you expect the provider to run, the CSOCs | The provider's relevant controls and its own written assertion |
| Cooperation needed from the provider | Little beyond sharing its report | Substantial: access for testing and a signed assertion |
| Where commonly used | Large cloud hosts and platforms with their own reports | Closely tied providers without a separate report |
A carve-out removes the provider from testing, not from your attention. Reviewing vendor risk sits under CC9.2, so expect the auditor to ask for your review of each carved-out provider's report and how you checked the CSOCs it relies on.
04 · Customer duties
Question four: what has the customer got to run on their side?
Those duties become complementary user entity controls (CUECs), and customers read them as a to-do list.
- Good: tied to a feature you provide"Customers are responsible for removing access for their own staff who leave, using the admin console." A reader knows exactly what to run.
- Good: tied to a credential they hold"Customers protect API keys issued to them and rotate a key they believe is exposed." It names the asset and the action.
- Weak: a blanket transfer"Customers are responsible for the security of their data." It says nothing specific and suggests your controls depend on everything the customer does.
- Weak: a duty that is really yoursListing backup of the customer's data as their job when your service stores it shifts a control you should run onto them.
The same logic runs the other way. Your hosting provider's report lists the duties it assigns to its customers, which means you. Pick up each relevant one as a control of your own: account settings, network rules, encryption choices and who can reach production are yours to answer for.
Sources: AICPA, DC Section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (with Revised Implementation Guidance, 2022); AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; AICPA, TSP Section 100, 2017 Trust Services Criteria (CC9.2).
05 · Go deeper
Go deeper
Dedicated pages on topics this guide only touches.
- Carve-out or inclusive: how vendors appear in your reportTwo ways to present a vendor, and what each does to your report.
- Subservice organizations: vendors inside your reportWho counts, how they're monitored, and what the report must say.
- Complementary controls: what customers and vendors owe the systemCUECs and CSOCs, written so they can actually be checked.
- Hosting on a SOC 2 cloud: what you inheritWhat a provider's report covers, and the controls that stay yours.
- Several products, one report?Drawing a system boundary when you sell more than one product.
Boundary questions from founders
Our hosting provider already has a SOC 2. Does that cover us?
Only for the provider's own layer.
The provider's report covers its data centres, hardware and the services it runs. How you configure your accounts, who in your team can reach production and how you ship code sit outside that report and need your own controls and your own examination.
Who decides the boundary, us or the auditor?
Management draws it; the auditor judges the description.
The service organisation defines its system and asserts that the description is fairly presented. The auditor then gives an opinion on that description. A boundary drawn to dodge the parts customers depend on puts that opinion at risk.
Can the boundary change from one period to the next?
Yes, and the report should say so.
New products, regions or providers can enter scope in a later period. Plan the change before the period starts so the controls run for its full length, and expect the description to note what changed.
Is every SaaS tool we use a subservice organisation?
No, only those whose controls bear on your criteria.
A design tool with no customer data is a vendor, not a subservice organisation. A provider that hosts, processes or secures in-scope data usually is. Both still belong in your vendor review process, scaled to the risk each one carries.
Settle the four questions before the period starts.
In a SOC 2 readiness assessment we walk your service component by component, decide how each provider is treated, and write customer duties a buyer can act on.