Learn · SOC Reports
SOC 2 Scope and the
System Boundary
A SOC 2 opinion covers one described system for one stated period, and the description of that system is what tells a reader where the assurance stops. Scoping is not a matter of choosing from a list of permitted exclusions — no such list exists. It is a matter of drawing a line a report user would not be misled by.
The constraint that governs everything: the AICPA description criteria (DC section 200) publish no catalogue of allowed exclusions. They set a presentation test instead — and the failure mode that test is written to catch is the exclusion nobody stated, rather than the exclusion itself.
Plain-English explainer · DC section 200 · TSC 2017 (rev. 2022) · Last reviewed August 2026
The system boundary is the set of infrastructure, software, people, procedures and data necessary to provide the service being reported on — and every word of the opinion is true only inside it. You may legitimately exclude a product, an office, a business process or a whole region, provided the description makes the exclusion visible enough that a reader cannot mistake what was examined. That rule is narrower than it sounds. The AICPA publishes no list of permitted exclusions. What it publishes is DC section 200, the description criteria for a SOC 2 system description, which sets nine criteria — DC1 to DC9 — for what must be disclosed, plus a presentation test the finished description has to meet. SOC 2 is an attestation under AT-C section 205 (redrafted by SSAE No. 21, effective for reports dated on or after 15 June 2022), and the controls inside the boundary are evaluated against TSP section 100, the 2017 Trust Services Criteria with revised points of focus issued in 2022. In a Type 2 the opinion has three parts, and the first of them is about the description itself — which is why a boundary problem sits one level above the controls rather than among them. SOC 1 works differently: it has no DC 200, and its description requirements live in AT-C 320.
What “the system” is
Five components, one line
DC3 requires the description to cover the system across five dimensions: infrastructure, software, people, procedures and data. The boundary is neither the network diagram nor the product roadmap. It is the answer, for each dimension, to one question: is this necessary to provide the service being described? Whatever is, sits inside. Whatever is not may be left out — and where leaving it out could confuse a reader, must be named as left out.
| Component | Inside the boundary | Legitimately outside | The mis-scope we see most |
|---|---|---|---|
| Infrastructure | The physical and virtual resources supporting the environment — cloud accounts, servers, storage, data-storage media, mobile devices, internal networks and connected external networks, and the facilities holding in-scope assets. | Estates with no path into the described environment and no in-scope data. | Excluding the shared logging, SIEM or secrets account because “it is not the product”. If it supports the commitments, it is inside. |
| Software | Application and service code, system software and databases, infrastructure-as-code, internal admin or support consoles that can read or change customer data, and the security tooling — firewalls, IPS/IDS, SIEM, configuration monitoring — that DC 200 treats as likely to sit inside. | Codebases with no deployment path into the in-scope environment. | Omitting the internal support console. Nobody buys it, so nobody lists it — while support staff use it on customer records daily. |
| People | Governance, management, operations and security personnel, plus users of the system — which under DC 200 expressly reaches vendor and user-entity personnel operating within it. | Staff with no role in the service and no access to in-scope assets. | Building headcount from the org chart. Contractors and offshore engineers with production access belong in the population regardless of cost centre. |
| Procedures | The automated and manual procedures through which the service is initiated, authorised, performed and delivered — including the undocumented workaround. | Back-office processes not relevant to report users. DC 200 names invoicing user entities as the classic example. | Leaving out manual exception handling: the “we do it by hand for enterprise customers” path that touches production without a ticket. |
| Data | Inputs, outputs, stores, queues, backups and transaction flows. Where Confidentiality or Privacy is in scope, the whole lifecycle of that information. | Internal corporate data with no relationship to the described service. | Analytics replicas, backup vaults and support-tool caches that hold customer data but never appear as described data stores. |
Two consequences surprise people. Tools count: DC 200 notes that applications and software tools supporting the achievement of service commitments and system requirements — firewalls, intrusion prevention and detection systems, SIEM, configuration monitoring — are likely to sit inside the boundary. And third-party access counts: where vendors or partners connect to, or perform functions within, components of the system, DC 200 points the description at the nature of that access and connectivity, and at what those third parties actually do inside the system.
The governing test
One standard, three sentences
Most scoping arguments start in the wrong place, with someone asking what they are allowed to leave out. DC 200 says three things that between them settle every case. A description need not address every aspect of the system: what is irrelevant to report users or beyond the scope of the examination can be left out. A description is presented in accordance with the criteria when it describes the system actually placed in operation, covers each criterion to the extent relevant, and does not omit or distort information likely to be relevant to report users’ decisions. And a description fails outright when it states or implies that components exist that do not, that processes are performed that are not, or when it makes claims that cannot be objectively evaluated.
“We did not exclude it. We just did not mention it.”
— the scoping position that fails every time it is tested
Materiality here is qualitative, not numeric. Management and the service auditor both work the same question: is there a substantial likelihood that misstatements or omissions would influence the judgements of the report’s specified parties? DC 200 gives the case of a privacy examination where management failed to describe a principal service commitment about complying with a data-protection law it was legally bound by. No control changed; the omission alone was enough, because a reader’s judgement would have moved had they known.
In readiness work we reduce this to two questions asked of every proposed exclusion. Is the excluded thing necessary to deliver the service being described? If it is, no drafting will move it outside. Reading only this report, would a reasonable customer form a belief about what was tested that is not true? If they would, the exclusion needs a disclosure attached — or a different boundary. The first question is about the standard. The second is about the reader, and it is the one teams skip.
The sequence
How the boundary actually gets drawn
Order of operations matters more than any single decision, because each step constrains the next. Teams that draw a line first and choose categories afterwards spend the engagement widening the line. This is the sequence we run in readiness work.
- 1Name the service a customer buys, in the words they would use for it, and write down the system name that will appear in the opinion, the assertion and the description. If sales, the contract and the architecture diagram call it three different things, that is the first thing to settle — every later step inherits it.
- 2Choose the trust services categories at the same time, because they move the line before you draw it. Security alone bounds you to the components delivering the service; Confidentiality or Privacy extends the boundary to every component touching the lifecycle of that information, formal processes and ad hoc handling alike.
- 3Inventory the five components — infrastructure, software, people, procedures, data — against one test: is this necessary to provide the service being described? Work from system-generated listings rather than the architecture diagram, because the diagram records intent and the listing records what exists.
- 4Trace every shared component and follow it to its end. The identity provider, the deployment pipeline, the artefact registry, the cluster, the on-call rota, the endpoint fleet and its device management: anything that can reach in-scope production comes inside, whatever else it serves and whichever cost centre pays for it.
- 5List the proposed exclusions and, for each one, write now the sentence that will appear in the description. If the sentence is hard to write without ambiguity, the exclusion is the problem, not the wording. This is also the moment to check whether a reader could form a false belief from silence.
- 6Evidence the separation before you assert it. Security-group, peering and IAM trust-policy exports for the network and identity paths; a walkthrough of every flow that crosses the line. An exclusion that rests on segmentation makes that segmentation a control inside the boundary, and controls get tested.
- 7Rebuild the populations from access rather than from the org chart. In-scope production identities, joiners, leavers, changes deployed to in-scope environments, incidents, access reviews — each drawn from the system that governs it, each reconcilable to a second source, each with the run date on the face of the export.
- 8Fix the boundary before the observation period opens, and instrument it. Anything that moves mid-period — an acquisition, a migration, a new region, a legal-entity change — becomes a disclosable change to the system and controls during the period, and is far cheaper to log as it happens than to reconstruct in month eleven.
Steps one and two are the ones teams compress into a single meeting, and they are the two that cost the most to revisit. Everything after step five is mechanical; everything before it is judgement. For the category half of that judgement, see choosing your trust services criteria, and for the period half, choosing your observation period.
One product, five products
Defensible versus misleading
Reporting on one product while selling five is ordinary and legitimate — the criteria contemplate it, noting that systems sharing components overlap while each boundary remains its own. This is the decision we walk clients through, exclusion by exclusion. Column three is where reports go wrong; column four is what survives the exclusion in every case.
| Proposed exclusion | Defensible when | Misleading when | What must still be disclosed |
|---|---|---|---|
| A second product on its own infrastructure | Separate accounts, code, data stores and operators, with no network or identity path into the in-scope environment. | The two share a control plane, an identity provider, a database or a support console — but the report is presented as covering the company. | Name the described system precisely and state that other products exist outside it. Where confusion is plausible, DC 200 expects the excluded functions to be identified. |
| A legacy product being sunset | It runs separately, no in-scope data flows to it, and its operators hold no in-scope production access. | A migration is under way, so in-scope data is being copied into it — or the same engineers run both and access was never separated. | That it is excluded, plus any interface between the two. Where a sunset or migration commitment governs how in-scope customer data is handled, it can meet the DC2 test for a principal service commitment — judge it against the described system, not the retired product. |
| An office or engineering site | The site holds no in-scope assets or data, and its staff hold no logical access to the described environment. | Engineers there deploy to production, or support staff open customer records on unmanaged endpoints, and only head office is described. | Which sites are inside. Physical access to facilities and protected information assets is tested under CC6.4, so the claim must match the asset inventory. |
| A region or deployment model | The description states which deployments are covered, and each covered deployment runs the described controls. | The report covers multi-tenant SaaS while the customer is buying a dedicated instance, an on-premise build or a regional estate run by another team. | The deployment models and regions in scope, in the words a buyer would use for what they bought. Silence here is where reports flatter hardest. |
| A business process (billing, onboarding conversion) | It is not relevant to report users and neither touches in-scope data nor authorises access. DC 200 names both examples. | The process moves customer data or provisions entitlements — typically a conversion team loading records by hand. | Say the process is outside where a reader might assume otherwise. The failure mode is the unstated exclusion, not the exclusion. |
| A subservice organization (carve-out) | Always available as a method choice. Carve-out removes the provider’s components from the description and examination — not the dependency. | It is used to imply a criterion no longer applies to you, or the provider is never named and no monitoring control appears. | Under DC7(b): the nature of the services, the criteria intended to be met there, and the types of controls expected at that organization — plus, whichever method is used, the controls you operate to monitor it. |
| A Trust Services Criterion itself | Only where the criterion is genuinely not relevant to the described system — and DC8 requires the reason to be given. | A policy forbidding an activity is used to declare the criterion irrelevant. DC 200 rejects that reasoning by name. | The criterion and the reason. A criterion stays relevant even when every component supporting it sits at a carved-out subservice organization. |
| Corporate IT and internal-only systems | They play no part in delivering the service — finance systems, the marketing site, a wiki holding no in-scope data. | The corporate identity provider, MDM or laptop fleet enforces production access but is written off as “corporate, out of scope”. | Which corporate systems perform in-scope control functions. If it enforces the control, it is inside for that control. |
The pattern is constant across all eight rows: an exclusion is defensible when the separation can be evidenced, and misleading when a reader would assume coverage the examination never gave. See carve-out vs inclusive method for how the subservice-organization row is drafted, and choosing your trust services criteria for the other axis of scope.
The hard case
Shared infrastructure, shared people
Products with genuinely separate stacks are easy to scope. Almost no company has them. The real work is deciding what happens to components serving the in-scope service and the excluded ones at once — and the answer is usually the unwelcome one.
The shared identity provider
If one SSO tenant grants access to in-scope production, it is inside the boundary whatever else it serves. The cost lands in populations: access review, provisioning and de-provisioning testing now covers every identity that can reach production, which usually crosses the product line you drew.
The shared pipeline
A CI/CD system or artefact registry that can deploy into the in-scope environment is part of that environment’s change management. Excluding a product does not exclude the pipeline that ships it. Expect change populations to be filtered by target environment — and expect the firm to test that the filter is complete.
The shared cluster or database
Internal multi-tenancy is a control problem before it is a scoping problem. Namespace or schema separation between an in-scope and an excluded workload is a control, and relied-upon controls get tested. You cannot lean on segmentation to justify an exclusion and place the segmentation outside the boundary.
The shared people
One on-call rota across five products, one security team, one support desk. If an engineer can reach in-scope production, they are in the people component even when four-fifths of their work sits elsewhere. Build in-scope populations from access, not from the reporting line.
The shared endpoint fleet
Laptops that authenticate to in-scope systems, and the device management governing them, are inside for the controls they enforce — even when the fleet is called corporate IT. This is the most common route by which an excluded office quietly returns to scope.
The shared incident process
One process across the estate means shared failure modes, and shared failure modes ignore the exclusion. Where an incident in an excluded system arose from a control shared with the described one, DC 200 expects management to weigh disclosing it anyway.
The working rule is short: the boundary follows the control. A control that operates once and protects both the in-scope service and an excluded product is inside, and will be tested against the criteria — CC6.1 for the logical access architecture over protected information assets, CC6.4 for physical access to facilities and those assets, CC9.2 for the vendors and business partners in the picture. What stays outside is what the described service can be delivered without.
Exclusions in practice
An office, a legacy product, a region
Excluding an office
Workable when the site stores no in-scope data, holds no in-scope infrastructure, and its staff have no logical access to the described environment. What pulls a site back inside is rarely the building — it is the people in it: deployment access, a support console, customer records printed for a workshop, an unmanaged laptop that can authenticate to production. For a cloud-hosted service the physical-security story mostly belongs to the hosting provider and is handled through the subservice organization disclosures, but the office still matters for endpoints, people and local storage. Where the exclusion holds, name the sites that are inside rather than leaving geography out altogether.
Excluding a legacy product
Straightforward when the legacy platform runs on its own infrastructure with its own operators and no in-scope data reaches it. The trap is the migration: during one, the legacy system almost always holds a copy of in-scope customer data, or a temporary interface exists to move it, and both belong in the description. A migration starting inside a Type 2 period is also a disclosable change to the system during that period. And if customers were told a sunset date and a continuity plan, that promise is a principal service commitment under DC2 — it cannot be dropped because the product it concerns is out of scope.
Excluding a region or deployment model
The exclusion most likely to mislead, because buyers rarely think to ask. A description that speaks of “the production environment” while the company runs a US estate, an EU estate and a set of dedicated single-tenant instances invites every reader to assume their own deployment is covered. If the regional or dedicated deployments run the same controls operated by the same people, name them and include them. If they do not — different infrastructure, different operators, a different release train — say which deployments the examination covers, in the words a customer would use for what they bought.
Evidence
What the CPA firm actually requests
In a Type 2 the service auditor opines on three things: that the description is presented in accordance with the description criteria, that controls were suitably designed, and that they operated effectively throughout the period. The first is a boundary test, and reading the description does not satisfy it. The firm corroborates it through walkthroughs, inspection of system-generated listings, and comparison of what management wrote against what the environment shows — working under AT-C section 205, which builds on the concepts common to all attestation engagements set out in AT-C section 105, including the requirement that the criteria used be suitable and available to report users. The boundary also drives every population in Section 4: get it wrong and the populations are wrong, and every sample drawn from them with it. One distinction first — in a Type 1 the description and the boundary are as of a single date, so a boundary that moved during the year is a Type 2 problem. What follows describes the Type 2 case.
| Boundary activity | Who owns it | What the others do |
|---|---|---|
| Defining the system and drawing the boundary | Service organization management | TCSA advises and challenges the proposed line, and tests it against the components inventory. The CPA firm evaluates the result against the description criteria and will push back on a boundary it cannot corroborate. |
| Writing the system description and signing the assertion | Management, who owns and signs both | TCSA drafts and edits alongside management. Neither TCSA nor the CPA firm can write management’s assertion — a description the auditor authored is a description the auditor would then be examining its own work on. |
| Evidencing that the separation is real | Management produces the evidence | TCSA makes the listings reproducible — stated source system, visible filter, run date — before they are requested. The CPA firm inspects them and corroborates through walkthroughs rather than accepting the description at face value. |
| Deciding whether an out-of-scope incident requires disclosure | Management assesses it, in writing | TCSA helps frame the assessment against the shared-control question. The firm evaluates management’s assessment — the judgement is management’s to make and the auditor’s to test, in that order. |
| Issuing the opinion on the description | The independent licensed CPA firm alone | No one else. TCSA coordinates the examination and prepares for it; TCSA never certifies, attests, audits or signs, and there is no such thing as a SOC 2 certificate. |
That split is the part buyers most often have backwards. The auditor does not set your scope. Management defines the system, draws the boundary and asserts that the description is fairly presented; the CPA firm evaluates that assertion against the description criteria and reports on it. An auditor who drew the boundary would be examining their own work, which is why the pressure in a scoping conversation runs the other way — the firm challenges what management proposes, and management either evidences it or moves the line.
| Boundary claim | What the firm requests | What gets rejected |
|---|---|---|
| “These three cloud accounts are the environment.” | An organisation-level account or consolidated billing export showing every account, with management identifying which are in scope and why; region, VPC and cluster listings; architecture and data-flow diagrams walked through with an engineer. | A hand-drawn diagram with no system-generated listing behind it, or a console screenshot cropped to the accounts you wanted to show. |
| “The other product shares nothing.” | Configuration evidence for the separation: security-group, peering and firewall rules; IAM role and trust-policy exports showing credentials in one environment cannot assume roles in the other; a walkthrough of every flow that crosses the line. | The assertion in the description with nothing behind it. A policy that says “logically separated” is the claim restated, not evidence of it. |
| “Only 22 of our 38 engineers reach production.” | The complete HR roster for the period including joiners and leavers, an identity-provider group membership export, a production access listing generated on a stated date, and a reconciliation of the three. | A list typed into a spreadsheet, or an export with no timestamp, no visible filter and no source system — the standard objection to information produced by the entity, because completeness cannot be assessed. |
| “That office is out of scope.” | Asset inventory by location, an endpoint-management export showing which devices hold in-scope access, badge or visitor-log populations where in-scope assets sit on site, and a walkthrough of what those staff do. | An HR headcount by location. It answers who sits where, not what they can reach. |
| “Billing sits outside the boundary.” | A process walkthrough showing it neither touches in-scope data nor authorises access, plus the sentence in the description that places it outside. | Silence. An exclusion nobody stated is not an exclusion — it is an omission, and omission is the thing DC 200 tests for. |
| “No incidents required disclosure.” | The incident and security-ticket population for the whole period across the whole organisation, with management’s written assessment of which incidents touched the described system or arose from controls shared with it. | A register already filtered to the in-scope product. That filter is precisely the judgement the auditor is there to evaluate. |
The populations a boundary decision creates
This is where a boundary stops being an argument and becomes work. Every line you draw defines a set of items the firm will test, a source system that has to produce that set, and a completeness check that proves the set is whole. Get the population wrong and the sample is irrelevant however carefully it was drawn — which is why completeness, not sample size, is what engagements actually fail on.
| Boundary-driven population | Source system and how the listing is generated | Completeness test the firm applies | Typical sample basis (market practice) |
|---|---|---|---|
| In-scope production access (as of a date) | Identity-provider group export plus the cloud IAM listing for each in-scope account, with the run date on the face of the export. | Reconciled to the HR roster for the whole period including joiners and leavers, so that identities without an HR record — contractors, service accounts, shared consoles — are surfaced rather than dropped. | An as-of population. Where it runs under roughly 30 identities, firms commonly test it in full rather than sampling. |
| Joiners granted in-scope access | HR system plus the onboarding ticket queue, filtered to the period, not to a department. | Reconciled against identity-provider account-creation events: every creation event in the period should map to an approved request, and every approved request to an account. | Attribute sampling over the period population. Size scales with the number of joiners, not with company headcount. |
| Leavers who held in-scope access | HR termination records plus the offboarding queue, whole period. | Reconciled against de-provisioning timestamps in the identity provider and each in-scope cloud account. The gap between termination date and revocation timestamp is the tested attribute. | Attribute sampling over the period population, usually with every long-gap item examined rather than left to chance. |
| Changes deployed to in-scope environments | Pipeline or ticketing export filtered by target environment, since the boundary — not the repository — decides which changes count. | Re-run the same export unfiltered and reconcile the delta, so the filter itself is evidenced. Emergency and out-of-band deployments are the items the filter most often misses. | Attribute sampling, sized to the deployment frequency. High-velocity teams generate the largest populations on the engagement. |
| Incidents and security tickets | The unfiltered organisation-wide register for the whole period — every product, not only the described one. | Management’s written in-scope / out-of-scope determination sits on top of the unfiltered population, so the judgement is visible and testable rather than baked into the extract. | Ordinarily every in-scope incident is examined, plus the out-of-scope items management assessed as arising from shared controls. |
| Access reviews over in-scope systems | The review records themselves, one per stated frequency per in-scope system. | The population is defined by the frequency the description states: a quarterly review over a twelve-month period is a population of four, and three is an exception, not a small sample. | Small, fixed populations are usually tested in full — there is nothing to sample from. |
Market practice, not a standard requirement
No table in the attestation standards fixes a sample size. AT-C section 205 sets no numbers, and each firm’s own methodology governs. What is nonetheless common across firms, for attribute sampling on a manual control, is sizing by frequency: roughly 1 occurrence tested for an annual control, 2 for quarterly, 2 to 5 for monthly, 5 to 15 for weekly, 15 to 25 for daily, and 25 to 60 where the control runs many times a day — adjusted for the size of the population, for exceptions found in a prior period, and downward to the whole population where the population is smaller than the indicated sample. Treat those as planning figures to budget evidence against, and confirm them with the firm that will sign the report rather than assuming them.
Two closing notes. Populations must cover the whole period, so where the boundary moved mid-period expect two populations and a test of the transition itself. And every listing is information produced by the entity: the firm evaluates whether it is complete and accurate before relying on it, which is why a stated source system, a visible filter and a run date on the face of the export are worth more than a tidier spreadsheet. TCSA does this preparation — defining the boundary early, building the populations that follow from it, making the listings reproducible before they are asked for — and coordinates the examination. The opinion is issued by an independent licensed CPA firm.
Worked example
Five products, one platform in scope
An illustrative composite, not a client: a 140-person software company preparing a Type 2 for 1 October 2026 to 30 September 2027, Security plus Confidentiality, on the product enterprise buyers actually ask about. The description calls it the Payments Platform system. Five products exist; the opening proposal was to report on one and exclude four.
Excluded
Self-serve free tool
Own cloud account, own codebase, two-person team, no network path or shared credentials into the platform. Excluded — and named as outside, because a reader browsing the website would otherwise assume coverage.
Excluded
On-premise connector
Runs inside customers’ own environments, maintained by the acquired team, no access to platform production. Excluded, with the interface it uses to authenticate described, because that interface is inside.
Pulled inside
Reporting add-on
Sold separately, but runs on the same cluster and reads the same database with the same credentials. Its components are the in-scope components; its exclusion would have relied on a segmentation that did not exist.
Pulled inside
Operations console
Nobody buys it and it never appeared on a product list, yet it holds write access to customer payment records. Software and procedures within the described system, tested like any other component.
Boundary event
1–12 March 2027
The connector team briefly held read access to a platform analytics replica for a migration trial. Because it touched in-scope data, management disclosed the change and the firm tested the revocation rather than waving it through.
The people arithmetic followed the same logic. Of 38 engineers, 22 could reach platform production; four support staff held console access and three contractors held temporary deployment access — an in-scope people population of 29, spanning three cost centres and two employment types. Joiner, leaver, background-check and training populations were rebuilt from access rather than from an engineering headcount pulled off the org chart, which is where the first draft would have lost all seven — the three contractors outright, because they never appear in the HR system, and the four support staff because nobody thinks of support as part of engineering. The second office held no in-scope assets and no production access, so it was excluded and stated as outside. Confidentiality being in scope widened the data boundary to the support ticketing system and an analytics warehouse the original diagram did not show.
The outcome is worth naming, because every multi-product company arrives at the same fork. Sales wanted “SOC 2 for the company”. What the company got was a report on one product whose boundary included two things nobody thought of as product, excluded two products and one office by name, and could be verified line by line by a buyer’s security team. The narrow, stated boundary survives diligence. The broad, implied one does not.
What the description actually said
Scope statement
This description covers the Payments Platform system operated by Northgate Payments Technologies Limited. Except where expressly stated, references to the system throughout this description mean the Payments Platform system and no other service offered by the Company.
Out-of-scope statement
The Company also offers a self-serve reconciliation tool and an on-premise file connector. Neither forms part of the system described here, and neither was within the scope of this examination. The self-serve tool operates in a separate cloud account with separate credentials and no network path into the Payments Platform environment; the connector operates inside customers’ own environments.
Interface statement
The on-premise connector authenticates to the Payments Platform through the Company’s public transfer API using per-customer credentials issued and revoked by the Company. The API endpoint, the credential issuance and revocation procedures, and the controls over them are part of the system described here, notwithstanding that the connector itself is not.
Sites statement
Personnel operating the system work from the Company’s Bengaluru office and from Company-managed endpoints when working remotely. The Company’s second office holds no system infrastructure, stores no customer data, and its personnel hold no logical access to the production environment; it is outside the boundaries of the system described here.
Illustrative wording, not a template. The description is management’s assertion about its own system, and it has to describe that system in that company’s terms — a sentence borrowed from another report is the fastest route to a description that states something untrue.
The trade
What widening the boundary costs
Every boundary argument so far has been about correctness, and correctness is what settles it. But the reason these conversations are hard is that widening the line has a price, and the price is rarely where people expect. It lands in populations and evidence, not in headcount — which is why a 40-person company with two products and three regions can carry more evidence burden than a 200-person company with one.
A second product on shared infrastructure
The change population multiplies by target environment rather than by product, and segmentation stops being an assumption and becomes a control that is described, tested and capable of generating an exception. Expect a second set of environment listings and a second reconciliation.
Adding Confidentiality
Every component in the information lifecycle enters the boundary — support ticketing, the analytics warehouse, exports produced for migrations, backup vaults — each carrying retention and disposal evidence over the whole period. This is routinely the largest scope increase teams do not budget for.
A second office
Endpoint, physical-access and local-storage populations appear where none existed: a device-management export by location, badge or visitor logs where in-scope assets sit on site, and an asset inventory that has to agree with both.
Contractors and agency staff
Joiner, leaver, background-check and security-training populations must be rebuilt from access rather than from HR, because the HR system does not hold the people concerned. The rebuild is cheap in month one and expensive in month ten.
A second region or deployment model
A second change population and a second access population, plus a second set of infrastructure listings — and if the regional estate runs a different release train or different operators, a second set of control descriptions to match.
The general rule is worth carrying into the scoping meeting: scope cost scales with populations, not with headcount. Adding a product that shares infrastructure adds a filter and a reconciliation to every change population you already had. Adding a category adds whole components. Adding people who are not in the HR system adds four populations at once. None of that argues for the narrowest possible boundary — a boundary too narrow to cover what customers buy costs more in lost deals than any of this costs in evidence. It argues for deciding deliberately, once, before the period opens.
For the reader
Spotting a boundary drawn to flatter
A flattering boundary is rarely a lie. It is an omission plus an ambiguity — and both are visible if you read the system description with these eight checks in hand.
- 1Read the system name in the opinion, the assertion and the description. All three should match, and it should be the thing you are buying.
- 2Check the legal entity. A report for a parent may not cover the subsidiary on your contract, and one subsidiary’s report does not cover its siblings.
- 3Look for an explicit out-of-scope statement. In a company that visibly sells several products, its absence is the tell.
- 4Match the deployment model — multi-tenant, dedicated instance, on-premise, or a named region. Buyers of dedicated instances are the most commonly uncovered readers.
- 5Read the people component for roles and locations. If engineering sits in three countries and one is described, ask what the other two do.
- 6Read the complementary user entity controls. A narrow boundary pushes work onto the customer, and the CUECs are where it lands.
- 7Read the subservice organizations and the method used. A carve-out is ordinary; a dependency you can infer from the architecture but not find in the description is not.
- 8Cross-check the control list against the boundary. If the description leans on segmentation from an excluded product, look for a control and a test result evidencing it.
None of this requires an accounting background, and none of it is adversarial — a well-run readiness process runs the same checks on its own description before the firm sees it. For the wider method, see how to read a SOC 2 report and the anatomy of the report.
Objections
What a buyer’s security team pushes back on
Each of these lands in real deal cycles. In every case the answer that works describes the mechanism rather than defending the marketing.
“Your SOC 2 does not cover the product we are buying.”
The right objection, and it deserves a straight answer: confirm what the report covers, state when the next observation period begins and whether the product is inside it, and offer interim evidence for that product under NDA. What loses deals is arguing the report covers “the company”. The reader can see the system name in the opinion, and a vendor arguing against their own report reads worse than a vendor with a known gap and a date.
“Why is your EU deployment out of scope?”
Two honest answers exist and one dishonest one. Either it runs the same controls operated by the same people, in which case it belongs in the description and should be named at the next period; or it is genuinely different, in which case say so and describe what governs it. The dishonest answer is ambiguity — a description that says “our production environment” while three regional estates exist invites the reader to assume coverage the examination never gave.
“You carved out your cloud provider — does that not make the report meaningless?”
No, and it is the ordinary treatment. Carve-out means the provider’s controls were not examined inside your report; it does not mean the criteria stopped applying to you. The description names the provider, the controls expected of it, and your monitoring of them. Pair the two reports: theirs covers infrastructure controls, yours covers configuration, access and data. What would be meaningless is a carve-out with no monitoring control and no mention of the dependency.
“This looks like scope shopping.”
Categories and boundary are separate axes, and it is fair to ask about both. Categories follow the commitments you actually made — Confidentiality because contracts oblige you to protect customer information and dispose of it. The boundary follows the service being described. Answer with the mechanism: here is the described system, here are the products outside it and why, here is the sentence saying so, and here is what changes next period.
Edge cases
Where this gets contested
The rules above settle four scoping questions in five. These are the ones that generate the arguments — between management and the firm, and between vendor and buyer.
An acquisition closes mid-period
The acquired system is normally outside the boundary for that period — it was not part of the described system when the period began. Disclosure often is required, though: a change of that significance to the services, to the IT and security personnel operating them, or to the organisational structure governing internal control over the system is the kind of change DC9 asks a Type 2 description to detail, with the date it happened and how the system differed either side of it. Buyers will ask whether the acquisition is covered, and the credible answer is a date rather than a reassurance.
An incident happens in an excluded product
A boundary is not a wall. DC 200 asks management to consider whether an incident outside the description arose from controls shared across all its systems, and whether anything — segmentation, for instance — actually prevents the same failure inside the described one. Where the shared control failed, the incident can require disclosure even though the affected product is out of scope.
You outsourced everything a criterion covers
A criterion relevant to the service stays relevant even when every supporting component sits at a carved-out subservice organization. DC 200 works the example: if the provider destroys data on decommissioned storage, CC6.5 — discontinuing logical and physical protections over physical assets only after the ability to read or recover data and software from them has been diminished and is no longer required to meet the entity’s objectives — is still relevant to you, because the commitment to your customers is still yours.
A policy forbids it, so the criterion “does not apply”
DC 200 rejects this directly. A policy prohibiting disclosures of personal information does not make the criteria covering such disclosures irrelevant; what belongs in the description is the controls preventing or detecting the activity. The pattern generalises — a rule is not evidence that the risk is absent.
You add Confidentiality or Privacy
The boundary widens by definition: it then covers, at minimum, every component involved in the lifecycle of that information, including informal ad hoc handling. That means support tickets holding customer records, spreadsheets exported for a migration, and the analytics warehouse nobody counted as a data store. One extra category often costs more scope than one extra product.
Non-production environments hold production data
Excluding “non-production” as a category is among the most common boundary errors in readiness work. A staging environment loaded with a copy of the production database is inside — it holds in-scope data, and the access and protection criteria follow the data. Either control it accordingly, or remove the data and evidence the removal across the whole period.
Contractors, agencies and offshore teams
People are a system component, and DC 200’s people component reaches vendor personnel operating within the system. Membership follows access, not employment status. The consequence shows up in populations: joiner, leaver, background-check and training populations drawn from the HR system alone will miss contractors, and the gap surfaces as an access-control exception rather than a scoping debate.
The entity on the contract is not the entity in the report
The description and management’s assertion name a legal entity. A report issued for a parent does not automatically cover a subsidiary that contracts in its own name, and one subsidiary’s report does not cover its siblings — different signing entity, different assertion, often different operators. Where several entities operate one system under common management and common controls, the description can name them all, but that is a drafting decision taken before the period opens, not an inference a buyer is entitled to make. A change of legal entity mid-period is itself the kind of organisational change DC9 expects a Type 2 description to disclose. Buyers: compare the entity in the opinion against the entity on your MSA before anything else.
Frequently Asked Questions
What is the system boundary in a SOC 2 report?
It is the set of infrastructure, software, people, procedures and data necessary to provide the service the report describes. The AICPA description criteria define system boundaries in those terms, and add that where several services share those aspects the systems overlap while each boundary stays distinct. Practically, the boundary is what the system description covers and what the opinion applies to — anything outside is untested by that examination, however clean the opinion reads. Checking the boundary first is the fastest way to know whether a report is relevant to you at all.
Can we scope our SOC 2 to just one product?
Yes, and it is common. The description names the system being reported on, so a company selling five products can report on one. It is defensible when the excluded products are genuinely separate — infrastructure, code, data stores and operators — or, where components are shared, when those shared components are brought inside the boundary rather than assumed away. It becomes misleading when the result is presented as company-wide assurance, or when the other products go unmentioned although any reader looking at your website would expect them to be covered.
Can we exclude an office from SOC 2 scope?
Only when the site holds no in-scope assets or data and its staff hold no logical access to the described environment. If engineers there deploy to production, or support staff open customer records on unmanaged endpoints, the office is inside regardless of what the description says. Physical access to facilities and protected information assets is tested under CC6.4, and the asset inventory settles the question. Where the exclusion genuinely holds, name the sites that are inside rather than omitting geography — silence reads as evasion to an experienced reviewer.
Does excluding a product mean the auditor never looks at it?
No. The auditor does not test the excluded product’s controls, but does test that the exclusion is true — walking the network and identity paths between environments, checking whether the same people operate both, and confirming no in-scope data crosses. Two hooks reach further: an incident in an excluded system may still require disclosure where it arose from a control shared with the described system, and any interface between the two is part of the described system and gets tested like any other component.
What has to be disclosed when we exclude something?
Where a reader might realistically be confused about whether a function is part of the system, the description is expected to state that it sits outside the boundary. Beyond that, exclusions carry their own disclosures. Carved-out subservice organizations must still be identified, along with the controls expected of them and your monitoring of those controls. A criterion treated as not relevant needs the reason. And significant changes to the system during a Type 2 period must be described, including changes to the boundary itself.
Can we exclude a Trust Services Criterion from scope?
Only where it is genuinely not relevant to the described system, and DC8 requires the description to explain why. Two traps are worth knowing. A policy prohibiting an activity does not make the criterion covering it irrelevant — the criteria reject that reasoning explicitly, and what belongs in the description is the controls that prevent or detect the activity. And a criterion relevant to the service stays relevant even when every supporting component has been outsourced to a carved-out subservice organization; it is addressed through expected controls and monitoring, not by removal.
Who decides what is in scope for a SOC 2?
Management does. The service organization defines the system, draws the boundary, writes the description and signs a written assertion that the description is presented in accordance with the description criteria. The CPA firm then evaluates that description against those criteria, corroborates it through walkthroughs and system-generated listings, and will challenge a boundary it cannot verify — but it does not set the scope, because an auditor who drew the line would be examining their own work. Buyers exert pressure commercially rather than formally, by declining reports that do not name what they bought. TCSA advises on the boundary and prepares the evidence behind it, and neither defines the scope nor attests to it.
What happens if the CPA firm disagrees with our boundary?
It surfaces long before drafting — in planning and walkthroughs — and is usually resolved by widening the description or adding the disclosure that removes the ambiguity. Where management will do neither, the consequence lands on the first element of the opinion rather than on the controls: a description failing the omit-or-distort test is not presented in accordance with the description criteria, and that is a modified opinion on the description itself. It is a serious outcome and a rare one, because boundary disputes are settled in scoping. If your firm is raising the question late, the useful response is to produce the separation evidence, not the argument.
What is included in SOC 2 scope?
Five components of the system being described: infrastructure (cloud accounts, servers, storage, networks and the facilities holding in-scope assets), software (application code, databases, admin consoles, and the security tooling supporting the service), people (governance, management, operations and security personnel, plus vendor and contractor personnel operating within the system), procedures (the automated and manual steps by which the service is initiated, authorised, performed and delivered) and data (inputs, outputs, stores, queues and backups). The test for each is the same: is it necessary to provide the service being described? Scope also has a second axis — the trust services categories, which determine which criteria the controls are evaluated against.
Does adding Confidentiality or Privacy change our scope?
Yes, usually more than teams expect. Where those categories are in scope, the system boundaries cover at minimum every component involved in the lifecycle of the confidential or personal information, including informal and ad hoc handling. That pulls in the support ticketing system holding customer records, the analytics warehouse, exports produced for migrations, and backups that never appeared on the architecture diagram. Category choice and boundary have to be decided together — choosing categories first and drawing the boundary afterwards is how scope grows mid-engagement.
Related reading: carve-out vs inclusive method, subservice organizations, CUECs and CSOCs, the Trust Services Criteria, choosing your observation period, opinions and exceptions, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Carve-Out vs Inclusive Method
How subservice organisations are described and tested — and what carve-out does not let you avoid.
Read moreSubservice Organizations
Carve-out vs inclusive — how your vendors' vendors appear in the report.
Read moreChoosing Your Trust Services Criteria
Security is mandatory; the other four are driven by commitments you actually made — and Privacy costs more than teams expect.
Read moreAnatomy of a SOC 2 Report
An interactive, annotated Type II example — click every element to see what it means.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreWhat Is SOC 2?
The AICPA attestation explained — five categories, Type 1 vs Type 2, report not certificate.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours