What SOC 2 scope means and where it is written down
A SOC 2 report has four parts. Section I is the independent service auditor's opinion. Section II is management's assertion. Section III is the description of the system, written by the company. Section IV lists the controls, the criteria they map to and, in a Type II report, the tests the auditor performed and the results. Customers usually read Section III first, because it tells them whether the report is about the thing they are buying.
Scope in SOC 2 has three dimensions that are set together. The first is the system: the service and everything that delivers it. The second is the set of Trust Services Criteria the report covers, with Security always included. The third is time: a single date for a Type I, an observation period for a Type II. This article is about the first dimension, because it is the one that decides how much work the examination takes and whether the report answers the customer's question.
The description is not freeform. It is prepared against the AICPA's 2018 Description Criteria for a description of a service organisation's system in a SOC 2 report, known as DC section 200, with implementation guidance revised in 2022. The auditor's opinion covers whether the description is fairly presented against those criteria. A description that leaves out a relevant part of the system, or describes controls that do not operate the way it says, is a problem for the opinion and not just for the reader.
How to draw the boundary of the system
The boundary is the line between what the report covers and what it does not. Drawing it well means starting from the customer, not from the organisation chart.
Start from what customers buy
The first input is the set of commitments the company has already made. Customer contracts, data processing agreements, service level agreements, the security page on the website and the answers given in past security questionnaires all describe what the company promises. DC section 200 calls these principal service commitments, and the system in scope is the one that delivers them.
In practice this means listing the products and services customers pay for, then asking which of them the customer requesting the report actually uses. A company selling one SaaS product has an easy answer. A company selling a platform plus a managed service, or several products on separate stacks, has to decide whether one report covers all of them or whether the first report covers the product that is blocking the deal.
Products and environments
Once the services are chosen, the next decision is which environments belong to them. The production environment that serves customers is always in scope. Staging and development environments are often outside the boundary, but only if customer data never reaches them and the controls that separate them from production are themselves in scope. If engineers copy production data into staging for testing, staging is part of the system whether the description says so or not.
Regions and hosting accounts follow the same logic. If the product runs in two cloud regions, or in several accounts with one provider, the description should name them. An auditor who finds a production workload in an account the description does not mention will ask why it is not covered.
People and teams
The people component covers everyone whose work affects the system: engineering, operations, support with access to customer data, and the security function. It also covers the processes that sit outside engineering but control access to the system, such as HR onboarding and offboarding, background checks and security awareness training.
Contractors and outsourced teams need explicit treatment. A development agency with commit rights, or an outsourced support team that can view customer records, is part of the people component. The description should say who they are, what access they have and which controls apply to them.
Data
The data component describes the types of data the system processes and where they flow. Customer content, personal data, credentials, logs and backups each need a place in the description. The useful exercise is to follow one customer record from the moment it enters the system to the moment it is deleted, and to note every component it touches along the way.
This is also where the boundary most often moves. A data flow to an analytics tool, a support platform or a data warehouse may pull another system into scope, or turn a vendor into a subservice organisation that the description has to address.
What the system description has to disclose
DC section 200 contains nine criteria, DC1 to DC9. Each one is a disclosure the description has to make. There is no prescribed format, so companies can organise Section III by system component, by control area or by another logical structure, as long as every criterion is addressed.
Services, commitments and system requirements
DC1 asks for the types of services provided. DC2 asks for the principal service commitments and system requirements. Commitments are what the company promises customers, such as availability targets, encryption of customer data or deletion on contract termination. System requirements are the internal specifications that make those promises achievable, such as backup frequency, access review cadence or patching timelines.
This pair matters because the controls in Section IV are evaluated against them. If the description promises 99.9% availability but no control addresses capacity or recovery, the gap becomes visible to the auditor and to the reader.
The five system components
DC3 asks for the components used to provide the services: infrastructure, software, people, procedures and data. The description should explain how each component operates in practice, not how a policy says it should. Infrastructure means the hosting, networks and endpoints. Software means the applications, databases and supporting tools. Procedures means the automated and manual processes that run the service.
The common weakness here is generic language. A description that says "the company uses industry standard encryption" tells the reader nothing they can rely on. A description that names the database service, states that data is encrypted at rest with keys managed in the cloud provider's key management service and explains who can access those keys gives the reader something to check.
Incidents and significant changes
DC4 requires disclosure of system incidents that resulted from controls not being suitably designed or not operating effectively, or that otherwise caused a significant failure to meet service commitments. The description gives the nature, timing, extent and disposition of each one. Companies often hope to leave this section empty. It is better to disclose an incident with a clear account of what was fixed than to have the auditor find it during testing.
DC9 applies to Type II reports and asks for significant changes to the system during the period. A migration to a new hosting provider, a new product line inside the boundary, a change of security leadership or a change of legal entity all belong here, with the date and how the system differed before and after.
Criteria, complementary controls and exclusions
DC5 covers the applicable Trust Services Criteria and the related controls. DC6 lists complementary user entity controls: the controls the customer must operate for the company's controls to work, such as managing their own users' access or protecting their API keys. DC7 covers subservice organisations and how they are treated. DC8 asks the company to state any specific criterion that is not relevant to the system, and why.
DC8 is where scope decisions become explicit. If the company has no physical offices that host system components, the criteria about physical access may be covered by the cloud provider instead. The reason has to be a fact about the system, written so a reader can verify it.
Cloud providers and other vendors in the description
Most companies seeking a first SOC 2 run on a large cloud provider. That provider is a subservice organisation: a vendor whose controls the company relies on to meet its commitments. The description has to say how it is treated. Under the carve out method, the provider's controls are excluded from the report and the customer is pointed to the provider's own SOC 2. Under the inclusive method, the provider's controls are covered by the examination. The differences are explained in our comparison of SOC 2 Type I and Type II; almost every company on AWS, Azure or Google Cloud uses the carve out method.
Carving out a provider does not mean leaving it out of the description. The description still names it, explains which services it provides and lists the complementary subservice organisation controls: the controls the company assumes the provider operates, such as physical security of data centres or the resilience of the underlying infrastructure. The company then needs its own control for monitoring the provider, usually an annual review of the provider's SOC 2 report and a record of how any exceptions were assessed.
Not every vendor is a subservice organisation. A tool the team uses to write documents, or a design application with no access to customer data, does not need to appear in DC7. The test is whether the vendor's controls are needed to meet the commitments in DC2. A payments processor, an identity provider or a customer support platform holding customer records usually passes that test. The broader question of how to assess these vendors is covered in our article on third party risk management.
Scoping mistakes that cost deals
Three mistakes account for most of the scoping problems that surface after the report is issued, when they are hardest to fix.
Too narrow: the report misses the product the customer buys
The most expensive mistake is a report that does not cover what the customer is purchasing. It happens when the first report is scoped around the core platform and the customer turns out to use a newer module running on separate infrastructure, or when a managed service delivered by a separate team was left out to reduce the size of the examination.
The customer's security team will read Section III, see that their product is not described and treat the report as irrelevant to them. The company then has to answer the full questionnaire anyway, or wait for the next report period. Checking scope against the specific customer's use case before the examination starts prevents this.
Too wide: controls nobody asked for
The opposite mistake is scoping in everything. Internal tools, legacy products with few customers, additional legal entities and every office location all add controls, evidence and potential exceptions. Each exception appears in Section IV and has to be explained to every reader of the report, including those who never used the system where it occurred.
A wide scope also lengthens the work before the observation period can start, because every included component needs its controls designed and operating. For a first report, the scope that covers the commitments driving current deals is usually the right one. Products can be added in later periods as the control framework matures.
A description that does not match the system
Everything in the description is open to audit. If it says access reviews happen quarterly, the auditor will ask for the quarterly reviews. If it describes a deployment pipeline with mandatory peer review and the team sometimes pushes changes directly, the auditor will find the direct pushes in the change history.
The opposite problem is just as real. If the auditor finds a production system, a team with access or a data flow that the description does not mention, the description is not fairly presented. That can lead to a modified opinion on the description itself, which is the part of the report customers trust most. The safest description is the one written from the system as it runs, then checked against it.
When the scope has to change between reports
Scope is not fixed for the life of the programme. A new product, a new cloud region, an acquisition or a move between hosting providers all change the system. Changes within a Type II period are disclosed under DC9. Changes between periods are absorbed into the next description, with new controls designed and operating before the next observation period starts.
Customers holding the previous report need to know when the scope they rely on has changed. A bridge letter from management covers the time between the end of the last period and today, but it cannot extend the report to systems it never covered. If a large customer's product moves into scope, telling them when the next report will include it is part of managing the relationship.
The practical discipline is to keep a current inventory of the system boundary: products, environments, accounts, teams, vendors and data flows. When that inventory changes, the scope question is asked immediately, not in the month before the auditor arrives.
Where Qalea fits
Qalea's platform maps each control in the SOC 2 framework to the systems, people and vendors inside the boundary, and collects the evidence for each control as the work happens. When a new account, team or vendor appears, it surfaces against the scope instead of waiting to be found during testing.
The Infrastructure area adds what a documentation exercise cannot: visibility of the external attack surface, cloud configuration and code. That shows what is actually exposed and running, so the boundary written in Section III matches the system the auditor will examine. More on the framework is in our SOC 2 topic hub.
