Learn · SOC Reports
Scoping One Product
When You Have Five
A multi-product company can put a single product in a SOC 2, and the description criteria contemplate it directly. What you cannot do is draw the boundary around the product and leave the machinery it shares with the other four outside it.
The test is separability, not preference. Distinct infrastructure, data stores, access paths and teams make a product genuinely separable. A shared cloud account, identity provider, engineering rota and pipeline do not stop you scoping one product — they decide how much comes with it.
Plain-English explainer · DC section 200 · TSC 2017 (rev. 2022) · Last reviewed August 2026
Yes — one product out of five can be the system in a SOC 2, and the AICPA description criteria say so almost in as many words: the boundaries of a system are the aspects of infrastructure, software, people, procedures and data necessary to provide its services, and when systems for multiple services share those aspects, the systems overlap while the boundaries of each system differ. So the question is never “may we exclude the other products?” It is “what does this product need in order to run, and is any of that shared?” Everything it needs is inside the boundary whether or not four other products need it too. A boundary drawn around the application while the cloud account, identity provider, pipeline and data platform sit outside it is not a narrow scope — it is an inaccurate description, and the description is the part of the report that management asserts and the CPA firm examines. SOC 2 is an attestation under AT-C section 205, not a certification, and the opinion covers the system described — no more and no less.
What the standard says
The subject matter is a system, not a company
Three provisions settle most multi-product arguments before they start — two from the description criteria in DC section 200, one from the trust services criteria.
Systems overlap; boundaries differ
DC section 200 defines system boundaries as the aspects of a service organization’s infrastructure, software, people, procedures and data necessary to provide its services — and states that when systems for multiple services share those aspects, the systems overlap but the boundaries of each system differ. Scoping one product of several is contemplated by the criteria, not merely tolerated.
Criteria apply to the system in scope
The 2017 Trust Services Criteria (revised points of focus, 2022) are written for an entity, and TSP section 100 is explicit that in a SOC 2 they apply as they relate to controls over the categories relevant to the system or systems within the engagement’s scope. That is what lets one product carry a report while four others do not.
Confusion has to be pre-empted
DC 200’s implementation guidance is the constraint most scoping arguments lose on: where report users might be confused about whether a function or process belongs to the system, the description needs to identify plainly which functions sit outside the boundaries. A report that never mentions the other four products is the misleading version.
Together they produce a rule easier to apply than most scoping debates suggest: inclusion follows function. If a component, process or person is necessary to deliver the described service, it is inside the boundary, and the fact that it also serves four other services is irrelevant to that question. Sharing changes not membership but population size — the boundary ends up smaller than the company and larger than the product team’s org chart. For the general rules on what may be excluded, see SOC 2 scope and the system boundary; this page is about the multi-product case.
Separability
The five dimensions that decide it
A product is genuinely separable when it stands alone on all five. Failing one does not block a single-product scope; it enlarges what the scope must contain. The dimension names are ours; the underlying components — infrastructure, software, people, procedures, data — are DC3’s.
| Dimension | Separable when | Not separable when | What that means for scope |
|---|---|---|---|
| Cloud infrastructure | Its own AWS account, GCP project or Azure subscription; its own networks and key material; no standing cross-account trust beyond named, logged roles. | One account and one VPC with shared subnets and security groups, or one Kubernetes cluster in which products are namespaces sharing nodes and a cluster-admin role. | Sharing relocates the boundary rather than defeating it: the account, network and cluster controls become part of the described system and are tested under CC6.1, CC6.6 and CC8.1. |
| Identity provider | In-scope entitlements are distinct groups, joiner and leaver workflows run per group, and no standing group opens production across products. | One “engineering” group opens production everywhere, local accounts exist outside the IdP, or one administrative credential spans tenants. | The IdP is inside the boundary either way, because it authorizes access to the described system. Separability decides only how large the access population is — a subset, or everyone. |
| Data stores | Separate instances or clusters, separate buckets under distinct keys, and no shared warehouse, cache or log store holding in-scope customer data. | One cluster of per-product schemas behind a single admin credential, a central analytics warehouse ingesting everything, or one observability platform receiving request bodies. | Where boundary claims fail most often. If in-scope data lands in a store shared with out-of-scope products, the store is inside the boundary — and so is everyone who can read it. |
| Personnel with production access | A dedicated team holds the in-scope production entitlements; cross-product access is time-boxed, approved and logged rather than standing. | One platform or SRE rota serves every product, on-call engineers hold cross-product administrative rights, or contractors are provisioned once for the estate. | People are a DC3 component, and DC3’s implementation guidance on the people component reaches governance, management, operations and security personnel as well as users of the system, including vendor personnel. Screening, onboarding, training and termination are then tested against everyone who can reach in-scope production. |
| CI/CD pipeline | Separate pipelines, runners and deployment identities scoped to the in-scope account, with approval gates enforced on the in-scope repositories. | One shared pipeline with one privileged deploy identity, shared self-hosted runners, a shared artifact registry, or one infrastructure repository applied by a single role. | A shared pipeline is a shared change path into in-scope production. CC8.1 is tested at the pipeline, and the pipeline’s own access controls come into scope with it. |
From five dimensions to a decision
No failures
Scope the product alone. The description still needs its boundary sentence naming the products that sit outside, because a reader looking at a five-product brand cannot infer it.
One or two failures on infrastructure, pipeline or data stores
Scope the product plus the named shared components. Expect the description to list them under DC3 as components of the described system, and expect each shared component’s own access and change controls to be tested alongside the product’s.
Any failure on identity or people
These are the two nobody separates cheaply. Plan for an entity-wide access population regardless of product headcount: joiner, leaver, access-review, screening and termination testing runs against everyone who can reach in-scope production, and the HR population starts company-wide before it is narrowed.
Four or five failures
Scope the platform. A single-product description would have to assert a separation the environment does not implement, and the first walkthrough finds it — at which point the description is rewritten mid-engagement and the populations are reselected.
What each shared dimension adds
Scope is chosen on effort as much as on principle, so it is worth stating the effort in units rather than adjectives. The numbers below are the ones from the worked example further down this page, carried here so the trade-off is visible before you commit to a boundary.
Shared identity provider and on-call rota
The access listing is drawn from the tenant, not the product roster: 23 people rather than the 14 engineers on the product, so joiner, leaver, access-review and screening testing runs over nine additional identities. Six service accounts sit beside them and carry their own ownership, rotation and review evidence.
Shared build runners and infrastructure repository
A second change population appears — 47 infrastructure changes to the shared core repository beside 612 deploys to in-scope production — with a second control owner who does not report into the product team and a second set of branch-protection settings to evidence.
Shared log store or observability platform
Pulls the account holding it inside the boundary: its access listing, its log-routing configuration, and its retention and disposal settings all become testable, and read access to the in-scope indices becomes a confidentiality control rather than an operational detail.
Shared cloud organization
Adds the trust policy of every role assumable into the in-scope account to the evidence list, plus service control policies and the organization’s account inventory to the walkthrough. Cheap to evidence, easy to forget, and the first thing an auditor pulls.
Shared analytics warehouse
The dimension that most often doubles a scope late. If in-scope customer data is ingested there, the warehouse and its entire reader population — analysts, data scientists, BI tooling — come inside the boundary, and the reader population is usually larger than engineering.
None of that is priced by product count. TCSA readiness is a fixed fee from $4,000 for early-stage startups, quoted after scoping, and the CPA firm’s attestation fee is billed separately. TCSA does the readiness, implementation and evidence work and coordinates the examination; the report is issued by a licensed CPA firm, and TCSA never certifies, attests or signs.
The pattern is worth stating plainly: infrastructure and pipelines can be separated with engineering effort, data stores usually can, and identity and people almost never are — which is why the identity provider and the engineering population sit inside nearly every single-product boundary. One further consequence follows from scoping a system rather than a company: the trust services categories are elected for the described system, so Availability may be relevant to one product and irrelevant to another, and Confidentiality may attach to the product handling customer records while an internal analytics tool carries no confidentiality commitment at all. In the worked example below, Atlas is examined under Security and Confidentiality because its customers receive contractual confidentiality commitments over reconciliation data; the availability commitments of the other two products are not commitments of the described system and are not examined. How that election is made is covered in choosing your trust services criteria.
The options
Five ways to scope it, compared
“Can we scope one product?” is a selection, not a yes-or-no question. These are the five arrangements a multi-product company actually chooses between, and the honest version of what each one costs and delivers. The rest of this page is about the first — but it is the right answer only some of the time.
| Option | When it fits | What it costs you | What the buyer actually gets |
|---|---|---|---|
| One report over one product | The product holds on most of the five dimensions and one buyer segment is driving the requirement. | The shared components still come inside, so what you save is application surface, not the platform. You also answer the “why not our product” question in every deal outside that segment. | An opinion over that product plus the shared machinery as it serves it. Nothing over the other products’ application controls, data stores or change paths. |
| One report over the whole platform | Products share a codebase, a database or a deployment, or buyers arrive from every product line at once. | The widest evidence burden: every product’s change population, every data store, every application control. And any one product’s exception lands in the single report everyone reads. | Coverage of whatever they bought, with no boundary argument to have and no follow-up questionnaire about which system the opinion reached. |
| Separate reports per product | Products genuinely run on separate infrastructure — often after an acquisition — and different buyers demand different categories. | The shared layer is described and tested in each report, so entity-level, identity and pipeline work is repeated. Two examinations, two attestation fees, two periods to keep straight. | A report that names their product, with no boundary to reason about — at the price of reconciling shared-component exceptions across two documents. |
| One report describing two systems | The case DC 200’s overlapping-systems language addresses directly: two services on shared aspects, each with its own boundary, examined together. | The description carries two boundary statements and has to keep them distinct, and the controls matrix has to show which system each control serves. Drafting is harder than either single-system option. | One document covering both, provided they read carefully enough to see which system each control and each exception belongs to. |
| Type 1 over the wider system now, type 2 over the next period | A deal needs coverage of a product with no operating history inside the boundary, and the timeline will not wait for one. | Two engagements and two attestation fees inside roughly a year, and a type 1 says nothing about operating effectiveness — some reviewers will say so. | Design-and-implementation evidence as of a date now, operating-effectiveness evidence at the end of the next period, and a dated sequence rather than a promise. |
Two of the five are chosen far more often than the evidence supports. Separate reports per product look tidy on a slide and repeat the entity-level, identity and pipeline work twice; and the whole-platform scope is often chosen by default when nobody wanted to have the boundary conversation. The type 1-then-type 2 sequence is the one most teams forget exists, and it is the only honest way to answer a buyer who wants coverage of a product that has no operating history inside the boundary.
The hard case
Drawing a boundary through shared infrastructure
There are two honest routes: implement a separation the environment actually enforces and evidence it, or concede the shared layer and put it inside the boundary. Both are respectable. Asserting a separation the environment does not implement is the one that fails.
| Mechanism | What it must demonstrate | Evidence that supports it | Where it breaks |
|---|---|---|---|
| Account or project separation | In-scope compute, storage and keys sit in an isolation unit the provider enforces, and entry into it is enumerable. | Organization structure and service control policies, the tagged account list, and the trust policy of every role assumable into the in-scope account. | A shared-services or management account with administrative reach inward. Whatever holds that reach is inside the boundary, however the diagram is drawn. |
| Network segmentation | Out-of-scope workloads cannot route to in-scope workloads except through declared, controlled paths. | VPC and subnet layout, security-group and NACL exports, peering and transit-gateway routes, service-mesh policies, and a reason for each allowed path. | A flat network, a permissive default security group, or a peering route nobody can explain. Segmentation is a point of focus under CC6.1 — evaluated, not assumed. |
| IAM boundaries | The identities able to act on in-scope resources are a closed, named set with least privilege applied. | Policy documents, permissions boundaries, role-assumption logs for the period, and IdP group membership with grant timestamps reconciled to in-scope resources. | Wildcard resource statements, a cross-product administrator group, or a service account never scoped down after a migration. |
| Data separation | In-scope data is stored, processed and logged inside the boundary, and copies leaving it are controlled. | Instance and bucket inventories mapped to products, key policies, replication and export settings, and log-routing rules reconciled to the asset inventory. | The analytics warehouse — the place in-scope data quietly arrives beside every other product’s data, with a reader population larger than engineering. |
| Logging and observability separation | In-scope telemetry lands in destinations whose readers are enumerable, and out-of-scope telemetry carries no in-scope data with it. | Log-routing rules, index or workspace permissions, retention and export configuration, reconciled to the asset inventory rather than to the architecture diagram. | One observability platform ingesting request bodies from every product. That makes every platform reader an in-scope user, and it is the commonest place a boundary claim fails. |
| Pipeline separation | Changes reaching in-scope production pass a change-control path applied to the in-scope system. | Pipeline definitions, branch-protection and approval settings, deployment-identity permissions, and deploy history reconciled to the pull-request record. | A shared runner fleet or shared infrastructure repository whose approval rules are weaker than the product’s own. The exception usually lands here. |
The trade-off, stated plainly
You can spend a quarter separating the identity provider, or you can name it in the description and test it. The second is not a compromise — it is the accurate answer, and it is usually cheaper than engineering a separation you did not otherwise need. Conceding a shared layer costs a paragraph in the description and a wider population in the evidence request. Asserting a separation the environment does not implement costs a rewritten description mid-engagement, after the sampling has already been done against the wrong populations.
Segmentation deserves one caution. It appears in the trust services criteria as a point of focus under CC6.1 — network segmentation permitting unrelated portions of the information system to be isolated from each other — so it is a control to be evaluated, not a premise the description may assume. CC6.6 covers logical access measures protecting against threats from sources outside the system boundaries, and once you declare where those boundaries run, an out-of-scope product with a route in is a source outside them. That is the sentence turning a diagram into a testable claim.
Description obligations
What you must say when things are shared
The description is management’s document, prepared under DC section 200, and it is examined. Six of the nine description criteria carry extra weight in a multi-product organization, and the disclosures they produce are what stop a narrow scope reading as a concealed one.
DC1
Types of services provided
Name the service the described system delivers, the way customers recognize it. Where a company markets five products, a description saying only “the Company’s platform” invites the reader to assume all five.
DC2
Principal service commitments and system requirements
Commitments and requirements are asserted for the described system only, which makes this the most multi-product-relevant criterion of the nine. Per-product uptime SLAs, encryption commitments and data-handling promises are stated for the product in scope — and that is usually the strongest argument for a single-product scope, because a platform-wide description forces management to assert the union of every product’s commitments and then be measured against all of them.
DC3
Infrastructure, software, people, procedures, data
Shared components serving the in-scope product are listed here as components of the described system — cloud accounts, identity provider, pipeline, log store. DC3’s implementation guidance on the people component reaches governance, management, operations and security personnel as well as users of the system, including vendor personnel, which is how a shared platform rota lands inside the boundary.
DC4
Identified system incidents
Where an incident hit a system outside the description, DC 200 asks management to consider whether it arose from ineffective controls shared across all the organization’s systems, and whether controls such as segmentation prevent the same failure inside the described one. If not, disclosure becomes the likelier answer.
DC8
Criteria that are not relevant
Sharing is not a reason to declare a criterion irrelevant. A criterion applicable to the described system stays applicable regardless of which other products depend on the same control — and DC8 requires an explanation of why a criterion is not relevant, so a bad reason is visible on the page.
DC9
Significant changes during the period
A type 2 description discloses changes to the system during the period. A migration bringing another product onto in-scope infrastructure, a re-platforming, or a consolidation of identity groups all qualify — and all change what the auditor was testing part-way through.
Illustrative boundary wording — not a template to paste
The system described in this report is the Atlas platform, including the prod-atlas AWS account, the logging, build-runner and network components of the shared core account, and the Company’s identity provider as it relates to Atlas entitlements.
The Company also operates Beacon and Relay. Neither product is part of the system described in this report.
Beacon and Relay operate in separate AWS accounts under the same AWS Organization and authenticate through the same identity provider as Atlas.
No opinion is expressed on controls relating to Beacon or Relay.
Four sentences, drawn from the worked example below. The fourth is the one reviewers look for and the one most descriptions leave out, because it says in plain words what the opinion does not reach.
One disclosure has no criterion number and matters more than any of them: the sentence naming what is outside. DC 200’s implementation guidance asks for it wherever report users might be confused about whether a function belongs to the system — and with five products on a shared platform, that risk is not hypothetical. It costs a line and removes the commonest reason a reviewer distrusts an otherwise clean report. Drafting the rest of the document is its own discipline, covered in writing the SOC 2 system description. The same logic governs complementary user entity controls under DC6 and subservice organizations under DC7, where the carve-out or inclusive election is stated.
Auditor procedures
How the boundary gets tested
A service auditor does not take the boundary as given. Under AT-C section 205, Assertion-Based Examination Engagements — redrafted by SSAE No. 21, effective for reports dated on or after 15 June 2022, and later amended by SSAE No. 23 for consistency with the quality management standards, effective for engagements beginning on or after 15 December 2025 — the practitioner must obtain sufficient appropriate evidence; and in a SOC 2, the opinion under DC section 200 covers whether the description is presented in accordance with the description criteria. A boundary is an assertion inside that description, so it draws procedures like any other. The wrong-boundary column below uses the worked example’s numbers.
| Procedure | What the auditor pulls | What a wrong boundary looks like here | Consequence if it fails |
|---|---|---|---|
| Walkthrough of the described system | The engineers who actually operate it, walked through provisioning, deployment and monitoring, against the component list in the description. | An operator names a console, a runner or a data store the description never lists — usually in passing, while demonstrating something else. | The description is amended and the component’s controls join the test plan mid-engagement, before any sampling has been done. |
| Account and resource inventory reconciliation | The cloud organization’s account list and a resource inventory tagged by product, matched against the accounts the description names. | In-scope data found in an account the description places outside — for Atlas, the shared core account holding the log store. | The account comes inside the boundary, and its access, logging, retention and network controls are tested as components of the described system. |
| IAM and identity-provider export review | Group membership with grant timestamps, cloud IAM listings and the service-account inventory, as of a date the auditor picks rather than one management offers. | Management’s listing shows the 14 Atlas engineers; the exports name 23 people and 6 service accounts with standing access. | The access population is redrawn at 29, and every joiner, leaver and access-review selection is made again against it. |
| Cross-account trust-policy inspection | The trust policy of every role assumable into the in-scope account, plus role-assumption logs covering the period. | A standing role from a shared-services account that nobody used and everybody could have. Non-use is not a control. | Whatever holds that role is inside the boundary, and its own access controls come with it — the largest single scope expansion an auditor finds late. |
| Network and segmentation inspection | VPC and subnet layout, security-group and NACL exports, peering and transit-gateway routes, and service-mesh policy. | A route from an out-of-scope product with no stated business reason, or a default security group nobody has narrowed since launch. | Segmentation is a point of focus under CC6.1, so it is evaluated rather than assumed; an unexplained path is a finding against the description, not just a control gap. |
| Deploy-history-to-change-population reconciliation | Deployment history for in-scope production, reconciled backwards to pull requests and tickets rather than forwards from the ticket queue. | Deploys arriving from a pipeline the change population never mentioned — the 47 infrastructure changes applied from the shared core repository. | The change population is extended and CC8.1 testing runs at the second pipeline too, under whatever approval rules that repository actually enforces. |
Completeness is the quiet center of all six, tested by starting from a system-generated source and working towards the client’s spreadsheet rather than the reverse. Two outcomes follow. If the description misstates what is inside, that is a description matter and can modify the opinion on fair presentation independently of whether controls worked. If the description is accurate but a shared component’s controls did not operate, that is an ordinary exception. The first is worth avoiding, because it is fixed by rewriting a document mid-engagement.
Evidence
What the CPA firm actually requests
Multi-product scoping is decided in the evidence requests, not the kick-off call. Every population below has a definition that differs from the intuitive one, always in the same direction: wider than the product team assumed.
| Population | Definition with one product in scope | Artifact requested | Why submissions get rejected |
|---|---|---|---|
| In-scope access listing | Every identity, human and non-human, with access to the described system at a date the auditor picks — not the product team’s roster. | IdP export of in-scope groups with grant dates, cloud IAM listings, database and admin-console user lists, service-account inventory. | A spreadsheet a manager filtered by product. Completeness cannot be established from a hand-filtered list; the auditor wants the export and a reproducible query. |
| Joiners | Everyone granted in-scope access during the period, whichever product they nominally work on. | Provisioning tickets showing request, approval and grant, tied to the entitlement actually created. | Approval dated after the grant, or an approver who is also the requester — an exception rather than a scoping question. |
| Leavers | Company-wide terminations for the period, then the subset holding in-scope access. The population starts wider than the boundary because the boundary is what is being tested. | HRIS termination report for the whole entity, plus timestamped deprovisioning evidence for each leaver with in-scope entitlements. | An HR list omitting contractors. They fall within DC3’s people component when they operate in the system, and the gap surfaces as an access exception. |
| Production changes | All changes deployed to in-scope production, including those made through a shared pipeline or shared infrastructure repository. | Deploy history or pipeline run log for the period, reconciled to pull requests and tickets, with approval state visible per item. | A ticket export alone. Tickets prove intent, not deployment; completeness is tested from the deployment side backwards. |
| Boundary and asset inventory | The components the description claims are inside, in a form reconcilable to the environment rather than to the diagram. | Cloud resource inventory tagged by product, account and network topology exports, data-store inventory with key mappings, and the control-supporting tool list. | An architecture diagram with no underlying export. A diagram is a claim; the inventory is the evidence for it. |
| Vulnerability and penetration testing | Coverage matching the described boundary — the same accounts, hosts and applications named in the description. | Scan configurations showing target ranges, results for the period, remediation tracking, and the penetration-test report with its own scope statement. | A test whose scope names the wrong environment. Two scope statements in one report that do not reconcile is a reviewer’s favorite catch. |
| Incidents and vendors | Incidents affecting the described system — plus, where a shared control failed, incidents elsewhere it could reach — and the vendors supporting the in-scope system specifically. | Incident register with dates, classification and disposition; vendor inventory marking which entries touch the described system, with risk assessments and collected reports. | A company-wide vendor list with no indication of which entries are in scope. CC9.2 is tested against the ones that are. |
Be wary of anyone quoting a sampling rule. No table in the attestation standards fixes a sample size; selections are professional judgment, scaled to how often a control operates and the risk attaching to it, and each firm applies its own methodology — the ranges and the reasoning behind them are set out in SOC 2 sampling and sample sizes. As market practice, an annual control is examined once, a quarterly control twice, and a many-times-daily control lands near twenty-five selections. The multi-product consequence is what to plan for: a shared control tested across a wider population costs evidence-gathering time, which shows up in your preparation schedule rather than in the report.
Worked example
One platform in scope, two out
An illustrative composite, not a client engagement. Three products: Atlas, a payments-reconciliation platform; Beacon, a marketing-analytics tool; and Relay, a scheduling product acquired eighteen months earlier. The company wanted a type 2 over Atlas alone, Security and Confidentiality, for 1 April to 30 September 2025.
The environment
Four AWS accounts under one organization: prod-atlas, prod-beacon, prod-relay, and a shared core account holding centralized logging, the self-hosted CI runners and the transit gateway. One Okta tenant for all forty-one engineers. Atlas had its own Aurora cluster and S3 buckets under a dedicated KMS key; all three products shipped application logs to the core account.
Where separability held
Infrastructure and data stores held — Atlas ran in its own account with its own key material and no standing cross-account roles inward. Identity did not: one tenant serves everything. The pipeline half-held: Atlas deployed through a dedicated environment with an OIDC role scoped to prod-atlas, but on runners living in the shared core account. People half-held: fourteen of the forty-one engineers worked on Atlas, but the three-person SRE rota held admin across all three products.
Two decisions that made the scope honest
Splitting the SRE rota was impractical, so all three SREs were treated as in-scope users — decided on 2 March 2025, four weeks before the period opened, so no remediation fell inside it. And because Atlas request bodies were reaching the shared log store, the core account was named as a component of the described system rather than argued outside it.
What the description said
The described system was the Atlas platform plus the shared components serving it: the prod-atlas account, the core account’s logging, runner and network components, and the Okta tenant as it relates to Atlas entitlements. One sentence named Beacon and Relay as outside the described system; a second noted they run in separate accounts under the same organization and share the identity provider.
What the populations became
The in-scope access listing was twenty-nine identities — fourteen engineers, four support staff with console access, three SREs, two administrators and six service accounts (the deploy role, the backup job, the log shipper, two integrations and the monitoring agent) — not the fourteen the product team expected, nor the forty-one on the roster. Leaver testing began with the company-wide HR list of nine terminations, four of whom had held in-scope access. The change population was 612 deploys to prod-atlas plus 47 infrastructure changes to the shared core repository.
What the report looked like
An unmodified opinion with one exception: two of twenty-five sampled changes to the shared core repository carried no recorded approval, because that repository’s branch-protection rules were weaker than those enforced on Atlas. Confidentiality was exercised on the shared component as well — read access to the Atlas log indices in the core account was restricted to a named group of nine and tested against that list, and index retention was tested against the ninety-day disposal commitment stated in the description. The exception landed exactly where the scoping work said the risk was: on the shared component, not the product.
The instructive part is the gap between expectation and outcome. The company set out to scope “one product” and ended with a report covering one product plus an identity tenant, a shared account and a shared runner fleet — materially more control surface than the first scoping conversation assumed, and none of it optional. Still far less than examining all three, and accurate, which is the only version worth having when a buyer’s security team reads it.
Edge cases
Where this gets contested
The five dimensions settle most cases. These are the ones that generate the real arguments.
The product is a feature flag, not a system
Two “products” on one codebase, one database and one deployment are one system with two price lists. The description would have to invent a separation the environment does not implement, and the first walkthrough exposes it. Scope the platform.
The internal admin console spans everything
A support tool that can read or change customer data across products is inside the boundary, and its users hold in-scope entitlements. Either scope the console and its whole user base, or restrict its in-scope capabilities to a named group.
An acquisition on separate infrastructure, shared HR
The acquired product can sit outside the boundary cleanly on infrastructure while screening, onboarding, training and termination remain shared and are tested across everyone with in-scope access. Its own controls are not tested at all.
Non-production environments holding production data
A staging environment for an out-of-scope product loaded with in-scope customer data sits inside the boundary. The usual resolution is to fix the data flow, and the fix has to precede the period to avoid an exception window.
The same platform sold under two brands
White-label and OEM arrangements are one system with two names. The description should name both, because a report user evaluating the brand they buy needs to see it identified rather than infer it.
A migration lands mid-period
Another product moving onto in-scope infrastructure during the period is a significant change disclosable under DC9, and it changes what the auditor is testing part-way through. Sequencing it outside the period is almost always cheaper — the mechanics are set out in mid-period changes to a SOC 2 system.
A shared control fails in an out-of-scope product
DC 200 asks management to consider whether the incident arose from controls shared across all the organization’s systems, and whether anything — segmentation, for instance — prevents the same failure inside the described one. Where the shared control failed and nothing else stops it, disclosure becomes the likelier answer.
The boundary is drawn around a legal entity
Criteria attach to a system, not to a company on a register. If a subsidiary’s product runs on the parent’s infrastructure and identity, those components are inside the described system whatever the letterhead says.
Objections
What the buyer’s security team pushes back on
These six come up most often when a single-product report meets enterprise review, and none is answered by insisting the scope is fine. The mechanics behind the first two are in the FAQs below; what follows is what you say in the room.
“Your report covers a product we are not buying.”
Concede it immediately, then be exact about what they do hold: tested evidence that the shared components — identity provider, cloud organization, pipeline, entity-level controls — operated as they relate to the described system. Same tooling, same process, tested over the in-scope population, not over the entitlements and changes belonging to their product. Overstating that is what loses the room; getting their product covered is a scoping conversation with dates in it, not a sales answer.
“Add our product before we sign.”
Say plainly that coverage cannot be granted backwards, then put dates on the alternative instead of leaving it open: which period is scoped wider, when readiness starts, and what they hold in the meantime. A dated scoping commitment closes more deals than an argument about attestation mechanics, and it survives their next vendor review.
“You share an AWS account, so the boundary is fiction.”
Shared infrastructure makes the shared layer part of the described system rather than making the boundary fictitious. Walk them through what the description says is inside — accounts, network paths, identity, pipeline — and show that the tested access population was everyone who can reach the environment, not the product headcount.
“Confirm in writing that your other products are equally secure.”
Management can describe its program, and that statement carries management’s name only. It is not assurance, the CPA firm performed no procedures over it, and a letter that reads like an opinion invites the challenge it was meant to close. Assurance over a second product comes from scope, not correspondence.
“Why is your control list so short?”
A narrower system carries fewer controls; that is scope, not weakness. The comparison worth making is between the applicable criteria and the controls mapped to them, not between control counts across vendors. A short list against fully covered criteria is a well-scoped report.
“Your penetration-test scope does not match the report.”
Usually right, and worth fixing before it is asked. Testing commissioned for the whole estate, or for one application when the boundary includes shared infrastructure, leaves two irreconcilable scope statements in one document. Align the testing scope to the described system before the period ends.
For buyers
Reading a report for a product you are not buying
This happens constantly and is not necessarily a red flag — a vendor with a well-scoped report over one platform is ahead of one with a vague report over “the Company.” What matters is knowing exactly what you hold. Six checks, in order.
| Check | Where to look | What a good answer looks like |
|---|---|---|
| Which system is described | Section III opening, the assertion in Section II, and the opinion in Section I | A named product or platform, stated identically in the assertion and the opinion. If the name is the company rather than a system, read further before assuming coverage. |
| What is stated to be outside it | Section III, boundary discussion | An explicit sentence naming the products, environments or functions excluded. Silence is the weaker answer, not the safer one. |
| Which shared components are inside | Section III, system components | Identity provider, cloud accounts, pipeline and logging named as components where they serve the described system — the part that gives you indirect comfort. |
| Whether your product touches them | Your own questions to the vendor | A straight answer that your product runs on the same identity and pipeline, or that it does not. Either is usable; an evasive one tells you where to look next. |
| Where the exceptions landed | Section IV, tests and results | Exceptions on shared components matter more to you than exceptions confined to the in-scope application, because your product depends on the shared parts too. |
| What is genuinely not covered | Inference, not a section | The unscoped product’s application controls, data stores, access paths and change control were not tested. A clean opinion elsewhere does not change that. |
One nuance is worth carrying into the vendor conversation. Entity-level controls — control environment and human resources under CC1, communication under CC2, risk assessment under CC3 and monitoring under CC4 — are usually operated once for the whole organization, so a report over one product does give you tested evidence about the control environment your product sits in. Control activities under CC5 are not in that set: CC5.2 covers technology general controls over the in-scope infrastructure and CC5.3 covers deployment of policies through the described system, and both are tested only for the system described. Nor does the report say anything about the other product’s own application controls, data stores, access paths or change management. Ask for those specifically, through a questionnaire or a scoped assessment, rather than treating the report as though it stretched.
Frequently Asked Questions
Can a SOC 2 report cover only one of our products?
Yes. The subject matter of a SOC 2 is a system, not a company, and DC section 200 states that when systems for multiple services share infrastructure, software, people, procedures and data, the systems overlap while the boundaries of each system differ. The constraint is accuracy rather than narrowness: everything necessary to deliver the described service sits inside the boundary, including components that also serve the products you excluded. A description omitting the shared identity provider, cloud account or pipeline is not narrowly scoped — it is wrong.
We run everything in one AWS account. Can we still scope one product?
You can, but the account comes with it. A single shared account means the account-level controls — identity and access management, logging, network configuration, key management — are part of the described system and are tested under criteria including CC6.1, CC6.6 and CC8.1. Some organizations separate accounts first because they wanted that isolation anyway; others accept the wider boundary and test it. Both are defensible. What fails is asserting an isolation the environment does not enforce, because the first IAM export shows it.
Does a shared identity provider have to be in scope?
If it authorizes access to the described system, yes — it is a component of that system regardless of how many other products it serves. What varies is how much gets tested. Where in-scope entitlements are distinct groups with their own provisioning and review workflows, the auditor tests those groups and the identity controls around them. Where one blanket group opens production across every product, every holder becomes an in-scope user and the access, joiner, leaver and review populations grow accordingly.
Our engineers work across all five products. What does that do to the report?
It widens the people population rather than blocking the scope. People are a system component under DC3, and DC3’s implementation guidance on the people component reaches governance, management, operations and security personnel as well as users of the system, including vendor personnel. Practically, background screening, onboarding, security training, access review and termination controls are tested against everyone who can reach in-scope production — often the whole engineering organization — even though the described system is one product.
Do we have to name the products that are out of scope?
Where a report user might reasonably be confused about whether a function or process belongs to the described system, DC 200’s implementation guidance asks the description to identify plainly which functions sit outside the boundaries. In a company selling five products under one brand, that risk is obvious, so the answer is effectively yes. It also works in your favor: reviewers who find an explicit boundary sentence stop hunting for what was hidden, and reviewers who find silence assume the opposite.
How does the auditor check that our boundary is real?
By testing it rather than reading it. Expect walkthroughs with the engineers who operate the environment, account and resource inventories reconciled to the description, IAM and identity-provider exports examined for standing entitlements crossing the boundary, trust policies on cross-account roles, network and segmentation configuration, and deployment history for in-scope production reconciled against the change population management supplied. Completeness matters most — a client-filtered spreadsheet that does not match a system-generated export is the usual way a boundary problem surfaces.
What happens if the boundary turns out to be wrong mid-engagement?
The description is amended and testing follows it. Not a disaster, but expensive in time: populations are redrawn, samples reselected, and evidence gathered for components nobody prepared. Leaving the description inaccurate is worse, because the opinion covers whether the description is presented in accordance with the description criteria — a misstated boundary is a description matter that can modify the opinion independently of whether the controls themselves operated effectively.
Can we add a second product to an existing SOC 2 report?
Not retroactively. A type 2 opinion addresses operating effectiveness throughout a stated period, so a product brought into scope now can only be covered by a period that includes it — with readiness work first, since controls must be operating before they can be tested. The usual sequence is to extend the boundary at the next period, or run a type 1 over the wider system as of a date and follow it with a type 2. A mid-period change is disclosed under DC9.
A vendor sent us a SOC 2 for a different product. Is it worthless?
No, but it is narrower than it looks. You get tested evidence that the components the two products share — commonly the identity provider, cloud organization, deployment pipeline and the entity-level governance and HR controls — operated as they relate to the system described. That is the same tooling and the same process your product runs on, but it was tested over the in-scope population, not over your product’s entitlements, changes and data stores. Read the boundary statement in the system description, ask whether your product runs on the same identity and pipeline, and cover the remainder through a questionnaire or a scoped assessment.
Related reading: SOC 2 scope and the system boundary, the anatomy of a SOC 2 report, how to read a SOC 2 report, cloud-provider shared responsibility, choosing your trust services criteria, vendor SOC 2 requirements, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
SOC 2 Scope & System Boundary
What may legitimately be excluded, and the DC 200 test that stops a boundary flattering the vendor.
Read moreCarve-Out vs Inclusive Method
How subservice organisations are described and tested — and what carve-out does not let you avoid.
Read moreOur Cloud Provider Has SOC 2 — Why Do We Need One?
The shared-responsibility split, and the CUECs your provider’s own report assigns to you.
Read moreChanges During Your Observation Period
New modules, IdP migrations and adding a category mid-window — what is absorbable and what is not.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreWriting the System Description (Section 3)
The omit-or-distort standard, writing at the right altitude, and an honest CUEC section.
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