Multi-product scoping
Several products: one SOC 2 boundary or several?
A company with one product draws one boundary. A company with several products, a shared platform or an acquisition has choices, and each choice tells readers something. This page sets out the options, the consistency the description needs, and how to avoid a boundary that misses what the customer actually buys.
Back to SOC 2 services01 · Three shapes
Three shapes of multi-product company
The architecture usually decides more than the org chart does.
- Shared platform
- Several products run on one infrastructure, one identity system and one deployment pipeline. Separating them on paper is hard to defend.
- Separate stacks, shared people
- Products run in separate accounts or networks, but one engineering, security and support organization operates them all.
- Acquired and still separate
- A bought company keeps its own infrastructure, tools and team, and has not yet been integrated.
Start from how the systems are actually built and run, not from how they are marketed. If two products share an identity provider, a deployment pipeline and a production database cluster, a control failure in one is a failure in both, and a boundary that splits them will be hard for the auditor to test and harder for a reader to trust. If they share only a finance team and a logo, separating them is natural.
02 · One report or several
One report or several
Each option has a cost and a reader effect.
One report, all products
- One description, one period, one evidence calendar
- Every buyer finds their product inside
- A control failure in any product appears in the one report
- Fits a shared platform best
Several reports
- Each product's description stays focused
- Fits separate stacks or a recent acquisition
- Shared controls are tested more than once
- Descriptions must agree wherever they share people or processes
A third option, one report covering only some products, is valid when the boundary is honest about it. See the decision table below.
03 · Decision table
A decision table
Illustrative; your auditor confirms what is testable.
| Illustrative situation | Reasonable approach |
|---|---|
| Three modules sold as one suite on one platform | One report naming all modules |
| Two products, separate cloud accounts, one shared team | One report for both, or two reports with identical shared-process sections |
| Main product plus a small beta not yet sold widely | One report for the main product; state that the beta is outside the boundary |
| Acquired company on its own stack | Keep it out and say so; add it once integrated, or give it its own report |
| One product sold to enterprises, another only to consumers | Scope the enterprise product first if only those buyers ask for SOC 2 |
04 · Consistent descriptions
Keeping the description consistent
Readers compare what you say in different places.
- Product names match the market. The names in Section 3 are the names on your website and order forms.
- Shared components are described once, the same way. Identity, CI/CD, logging and HR processes read identically wherever they appear.
- Exclusions are stated. Products, regions or acquired entities outside the boundary are named as outside.
- Commitments match the boundary. SLAs and contract terms quoted in the description belong to the products in scope.
- Changes are disclosed. Products added, retired or migrated during the period appear as significant changes.
05 · What readers infer
What readers conclude from what is left out
Silence is read as absence.
A careful reader of Section 3 looks first for their product, then for the infrastructure and teams that run it. If the product is not named, the opinion says nothing about it, however clean that opinion is. A boundary that leaves a product out without saying so invites the worst reading: that its controls would not have passed.
- Quietly leaving out the product the customer buys. The report is shared in a sales cycle for a product it does not cover. Reviewers find out, and trust drops.
- Boundary drawn around the cleanest product. Scoping the easiest system to pass, then presenting the report as company-wide.
- Separate reports that contradict each other. Two descriptions of the same access review process with different frequencies.
- Forgetting the shared team. Separate stacks, but the shared on-call team's access to both is never described.
Sources: AICPA description criteria DC section 200 (types of services, system components, significant changes); AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; AICPA attestation standards AT-C 205.
Questions about scoping several products
Can we add a second product halfway through a period?
Usually in the next period.
Controls for the new product need evidence across the whole period being tested. Disclose the addition as a change and bring it fully into the next period.
We bought a company. Does its existing SOC 2 report still count?
For its own system, until things change.
Its report covers its system as it was. Once you merge infrastructure, people or processes, the old description stops matching reality. Plan the combined boundary.
Is it acceptable for a report to cover only one of our products?
Yes, if it says so.
Name the product in scope, and be clear in sales conversations which product the report covers. The problem is silence, not a narrow scope.
Do separate reports need the same CPA firm?
No, but one firm simplifies shared controls.
Different firms may test the same shared process differently. Using one firm, with aligned periods, avoids inconsistent conclusions.
A boundary every buyer can find themselves in.
We map your products, platforms and acquisitions to a boundary and a reporting plan that holds up in sales reviews.