Scope is the first real decision in a SOC 2 project, and the one that is hardest to change later. It decides which systems need controls, which people produce evidence, and what your buyers will find covered when they read the report.
Most first-time scoping goes wrong in one of two directions. Teams scope everything, including systems no customer cares about, and spend the observation period evidencing controls nobody relies on. Or they scope so narrowly that the report does not cover the product buyers are actually purchasing, and the first enterprise reviewer notices.
This article walks through the decisions that make up scope, in the order that works, and what to write down at the end.
Scope is a set of decisions, not one
"What is in scope?" sounds like a single question. In practice it is seven, and they depend on each other:
Which services the report covers.
Where the system boundary sits around those services.
Which locations and legal entities are included.
Which trust services categories apply.
Whether the report is Type I or Type II, and over what period.
How third parties that support the system are treated.
Which responsibilities sit with your customers.
Take them in that order. Each answer narrows the next.
Start with the service customers buy
The report describes a system that provides a service. Name the service the way your customers would recognize it: the product on the order form, not the internal codename for its backend.
If you sell more than one product, decide which ones the report covers. The usual starting point is the product that generated the security questionnaires prompting the audit. A second product built on the same infrastructure, by the same team, is often cheap to add. A separately built product from an acquisition is not.
What people get wrong: excluding a product buyers use, to make the first audit smaller. A report that covers your core platform but not the add-on most enterprise customers buy will draw the obvious question. Better to know that now than in a security review.
Draw the system boundary
Once the service is named, decide what supports it. The AICPA's description criteria describe a system in terms of five components, and they make a good checklist for the boundary:
Infrastructure. Cloud accounts, networks, and hosting for the production service.
Software. The application itself and the supporting tools that run or change it: source control, build and deployment pipelines, monitoring, and ticketing.
People. The teams who build, operate, and support the service, and the functions that support them, such as HR for onboarding and offboarding.
Procedures. The documented and automated processes that run the system.
Data. The information the system processes, including customer data, logs, and backups.
A workable rule for borderline systems: include a system if it can affect the security of the service or the data in it. Your identity provider is in, because it controls access to everything else. Laptops used to reach production are in, through endpoint controls. A marketing site with no access to customer data can usually stay out.
Say a hypothetical 40-person SaaS company runs its product in one cloud account, deploys from a hosted source control service, and manages staff through an identity provider and an HR system. Its boundary would typically include the production cloud account, source control and the deployment pipeline, the identity provider, the HR system as the trigger for joiners and leavers, the alerting and ticketing tools that support operations, and staff laptops. Its sandbox account for experiments would sit outside, provided it holds no customer data and has no path into production.
Segregation is what makes exclusion defensible. If a legacy environment or an internal tool sits outside scope, be ready to show it cannot reach the in-scope system, or that access between them is controlled.
Choose categories and report type
Security is required. Each other category should be tied to a commitment you have made. The category deep dives cover each decision: availability, confidentiality, processing integrity, and privacy.
The report type is a separate choice. A Type I reports on control design at a point in time. A Type II reports on operation over a period. The trade-off, and how it drives your timeline, is in SOC 2 Type I vs Type II.
Locations and legal entities belong in this step too. If you have offices, a subsidiary that employs engineers, or a contractor team abroad that operates the service, the auditor needs to know whether they are inside the boundary. Remote-first companies often have no office in scope at all, which is fine as long as the description says so.
Decide how third parties are handled
Almost every SaaS system depends on vendors. Scope asks which of them are subservice organizations: vendors whose services, and controls, are part of how your system meets its commitments. A cloud hosting provider is the usual example. A vendor that sends your newsletters is not.
For each subservice organization, your report either carves its controls out or includes them. Carve-out is the common choice for large cloud providers, and it means your report identifies the provider, describes what it does, and states which of its controls your system relies on. You then monitor it, typically by reviewing its own SOC report each year.
Make a list now. For each vendor, record what it does, whether it touches customer data or production, and whether it is a subservice organization. That list feeds your system description and your vendor risk process.
Identify what your customers must do
Some controls only work if your customers do their part. If customers manage their own users in your product, you cannot review their access for them. Those assumed customer responsibilities appear in the report as complementary user entity controls.
Write them down during scoping, not at the end. They follow from your product design and your contracts, and they should match both. A long list of vague customer duties reads as shifting responsibility. A short list of specific ones reads as an honest description of shared responsibility.
Write it down and agree it with your auditor
Scope only counts once your auditor has agreed it. Capture the decisions in a short scope memo before the observation period begins:
- Not done:
The services covered, named as customers know them
- Not done:
The system boundary, listing in-scope environments and supporting tools
- Not done:
Locations and legal entities included, and any excluded
- Not done:
Trust services categories, with the commitment behind each one
- Not done:
Report type, and the period start and end dates for a Type II
- Not done:
Subservice organizations, and carve-out or inclusive treatment for each
- Not done:
Complementary user entity controls, in draft
- Not done:
Systems deliberately excluded, with the reason
The memo becomes the skeleton of your system description, and it gives your team one answer to "is this in scope?" when the question comes up mid-period, as it will. If you want to test the memo against the controls you have, the SOC 2 readiness checklist walks through the common criteria area by area. For the calendar that follows from scope, planning your first audit timeline picks up where this leaves off.
How TrustLynce helps
TrustLynce's readiness dashboard shows your gaps against the categories you select, so scope decisions are visible in terms of the work they create. Third-party risk keeps your vendor inventory, tiering, and reviews in one place, including the subservice organizations your report relies on.