How to scope a SOC 2 before anyone quotes it
The organization decides the scope of its SOC 2, and it should settle that decision before any CPA firm is asked for a quote. Security is always in scope, covered by the common criteria CC1.1 to CC9.2, and any other trust services category (availability, confidentiality, processing integrity or privacy) is added only when the customer's risk requires it. A customer asking for a SOC 2 without naming categories is asking for the security baseline, and the vendor should confirm that reading in writing before scoping begins.
The right scope follows from the product or service the customer actually buys. Ask which application, environments, data stores and support functions deliver that service, and which physical locations, cloud accounts or self-hosted deployments are operated by the organization. Then list every third party that runs part of the service, such as a hosting provider, a managed database or a support desk, because each one changes how the report must describe subservice organizations. Note whether the customer's own regulator expects something beyond the trust services criteria. If it does, a SOC 2+ report may be the better vehicle, and that question belongs in the scope document rather than in a later renegotiation.
Write the scope as a short, signed document before the CPA firm engagement letter is drafted: the system name and boundary, included and excluded components, categories selected with the reason for each, and the third parties and their treatment. Ask the auditor to confirm that the boundary is one it will accept, since a scope the auditor later rejects can force rework and a new description. Keep the document under change control, because adding a product or region after the examination starts usually means a separate examination period for that addition.
Which systems, services and locations belong in the scope
A SOC 2 scope is a set of decisions, not a single line on a form. Each decision answers the same question: would a customer reasonably expect this component to be covered by the report? The 2017 Trust Services Criteria can be applied across the whole entity, to a subsidiary or division, or to a narrower set of controls, so the scope should be fixed in writing before readiness work begins.
The system and its boundary
The system is the set of infrastructure, software, people, procedures and data that delivers the service being examined. The boundary decides which production accounts, clusters, databases, identity providers and support tools sit inside the report. Check whether the internal corporate laptops, staging environments and billing tools that touch customer data are in or out, and write down the reason for each exclusion. Customers will ask why an excluded component is excluded, so the reason must be defensible.
Services and customer commitments
The report must describe the services customers buy and the commitments the company makes about them, such as uptime targets, data handling terms and support response. A product line that customers do not use, or a free tier that carries no contractual commitments, may not need to be in scope. Confirm which service commitments appear in customer contracts and security questionnaires, because the system description must match what the company actually promises. Mismatches between marketing claims and the described system are a common source of exceptions.
Locations and legal entities
Scope must name the data centers, cloud regions, offices and legal entities that operate or support the system. A parent company may own the software while a subsidiary employs the support team or processes payments, and each of those entities can change what the report covers. Confirm where customer data is stored, replicated and backed up, and whether any personnel with production access work from countries that customers have flagged. Omitting a region that holds customer data is a scope error that is hard to correct after fieldwork starts.
Entity-wide or a subsidiary or division
Criteria can apply to the whole entity or only to a subsidiary, division or product unit. A narrower scope can make sense when one business line serves regulated customers and the rest of the group does not, but customers may ask whether shared identity, shared engineering or shared leadership undermines a narrow boundary. Write down which controls are shared across units and whether they are tested once for all units or separately. Confirm with the CPA firm how it treats shared controls before committing to a narrow scope.
Narrower sets of controls
A scope may also be defined by control sets rather than by organization, for example only the access and change management controls that protect a specific data store. The test is whether the report still gives customers a fair picture of the system they use. A narrow control set that leaves out the controls customers rely on most, such as logging, incident response or backup, is likely to draw questions. Ask the CPA firm and key customers whether the proposed control set matches the risks they care about before fieldwork begins.
Subservice organizations and carve-outs
Cloud hosts, payment processors and other vendors that perform part of the service are subservice organizations. The report can include their controls (inclusive) or exclude them and rely on their own SOC reports (carve-out), and the choice changes what the auditor tests and what customers read. Check which vendor SOC reports are available, whether their scope matches the services you use, and which complementary subservice organization controls your own controls depend on. Confirm the treatment with the CPA firm early, because it shapes the system description.
Which trust services categories to add to security
This table compares the five trust services categories, showing what each adds to the mandatory security criteria and when it fits. Read each row against the systems and customer commitments in scope, then confirm the exact criteria in the 2017 Trust Services Criteria document before the scope is fixed.
| Category | Criteria added | When it fits | What it adds to the report |
|---|---|---|---|
| Security | CC1.1 to CC9.2 (33 criteria) | Always included in every SOC 2 report | Common criteria covering governance, risk, access, operations, change management and vendor risk |
| Availability | A1 (3 criteria) | Customers rely on uptime, capacity or recovery commitments in contracts or service levels | Capacity management, environmental protections, backup and recovery infrastructure, and recovery plan testing |
| Confidentiality | C1 (2 criteria) | The service handles information customers designate as confidential, such as contracts, designs or financial data | Identifying confidential information, protecting it, and disposing of it when no longer needed |
| Processing integrity | PI1 (5 criteria) | The service processes customer data or transactions where completeness and accuracy of output matter, framed around providing services or producing or distributing goods | Processing specifications and controls over inputs, processing, outputs and stored data |
| Privacy | P1 to P8 (18 criteria) | The service collects or uses personal information and customers ask how it is handled throughout its life cycle | Notice, choice and consent, collection, use, retention, access, disclosure, quality, and monitoring. Nine common criteria also gain privacy points of focus: CC1.3, CC1.5, CC2.2, CC2.3, CC6.1, CC7.3, CC7.4, CC8.1 and CC9.2 |
How cloud providers and other subservice organizations are handled
With the inclusive method, the subservice organization is described inside the system description and its controls fall within the examination scope. The CPA firm tests the relevant controls at the subservice organization as part of the service organization's report, so the report covers the whole service path a customer depends on. This approach is common when the service organization wants one report to answer a customer's questions about its hosting environment.
- Description: The system description names the subservice organization, the services it performs and the boundary between its responsibilities and the service organization's.
- Testing scope: The examination includes the subservice organization's controls that support the criteria in scope, which usually means access, change, monitoring and backup controls in the hosting environment.
- Access to evidence: The service organization must be able to obtain evidence from the subservice organization, so the contract should give the auditor a route to it.
- Cost and effort: More controls are tested, so the examination requires more evidence and more fieldwork time, and this effort recurs each period.
- Ownership: The service organization remains responsible for the description and for any gap in what the provider supplies.
Confirm with the auditor, before fieldwork, which subservice controls will be tested and whether the provider's evidence is accessible in time.
With the carve-out method, the subservice organization is excluded from the examination and its services are described only at a high level. The report instead lists the controls the service organization relies on the subservice organization to perform, known as complementary subservice organization controls. The provider's controls are not tested in the service organization's examination, which narrows the work but places the reliance in plain view for customers.
- Description: The system description states which services the subservice organization provides and that its controls are carved out of the examination.
- Complementary controls: The report lists the controls the subservice organization is expected to perform, and the service organization must monitor that they operate.
- Narrower testing: Fewer controls fall within the examination, which can reduce fieldwork, but the reader must judge the carved-out controls on their own.
- Monitoring duty: The service organization must review the subservice organization's reports and exceptions, since it still answers for the service its customers receive.
- Customer reading: Customers and their auditors often ask for the provider's own report alongside the carve-out report to close the gap.
Before choosing this method, confirm with the auditor how the complementary subservice organization controls will be presented and how the service organization will evidence its monitoring of them.
Whichever method the service organization uses, a customer reviewing a cloud provider or other subservice organization should ask for that provider's own SOC reports and read them against the service organization's report. Major cloud providers publish SOC reports to their customers through their own channels, and the customer should confirm the scope, period and exceptions in each report before relying on it. The reviewer must also map which controls still belong to the service organization, because a provider's report cannot cover configuration choices the service organization makes.
- Request the report: Ask the provider for its current SOC 2 report and any bridge letter covering the gap to the present date.
- Read the scope: Check which services, regions and systems the provider's report includes, since a service used by the service organization may sit outside it.
- Review exceptions: Note any exceptions or qualified opinions and whether they affect controls the service organization depends on.
- Map ownership: List the controls the service organization still owns, such as user access, data classification, encryption settings and application logging, and confirm evidence exists for each.
- Record the gaps: Document any complementary controls with no evidence and agree remediation with the service organization.
Confirm the provider's report scope and period in writing, and confirm which of your own controls the provider's report does not cover.
Why the common criteria set the floor for every scope
Every SOC 2 examination covers the common criteria CC1 to CC9, whatever categories are chosen. Security is the one category that applies to every SOC 2, and it is covered by 33 criteria from CC1.1 to CC9.2. Availability, confidentiality, processing integrity and privacy only add criteria when they are put in scope, so the scope decision is never about whether the common criteria apply. It is about which system, which locations and which additional categories sit on top of them. Before you choose anything beyond security, confirm that your control matrix already maps each common criterion to a named control, an owner and an evidence source for the system you plan to examine.
CC1 to CC5 restate the 17 COSO internal control principles, covering integrity and ethics, board oversight, the control environment, communication, risk assessment, monitoring and control activities. CC6 to CC9 add the criteria that most often produce findings in practice: logical and physical access, system operations, change management and risk mitigation, including vendor risk. For a scope with a cloud-hosted production environment, the CC6 and CC8 criteria usually reach into identity providers, privileged access paths, deployment pipelines and infrastructure as code, so those systems belong in the scope definition from the start. If a component supports the in-scope service but sits outside the boundary, document why and how it is governed.
Points of focus are the characteristics under each criterion that help you design and evaluate controls. They are not separate requirements, and not every point of focus has to be addressed. A scope decision should therefore be stated in terms of criteria and controls, such as which access review control satisfies CC6.2 for the in-scope systems, rather than in terms of which points of focus were ticked. When privacy is in scope, nine common criteria carry additional points of focus (CC1.3, CC1.5, CC2.2, CC2.3, CC6.1, CC7.3, CC7.4, CC8.1 and CC9.2), so review those criteria with your privacy scope in mind. Confirm the exact wording and the 2022 revisions in the AICPA's criteria document before you finalize the matrix.
The steps to fix the scope before readiness work begins
The sequence turns a vague request from a customer into a written scope statement that names the system, the categories, and how each third party is treated, so readiness work targets the right controls from the start.
List the product and customer commitments
Start with what the service promises customers, in the contracts, order forms, security addenda and public documentation the business already uses. Record each commitment that depends on a control, such as uptime language, data handling terms or processing accuracy claims. Ask the customer or the requesting party which report they need, and whether they name specific categories. The output is a short list of commitments, each tied to the customer-facing service it describes, that you can check against later.
Draw the system boundary
Define the system the report will describe: the named products or services, the production environment, the internal tools that administer it, and the people and processes that operate it. Decide whether the examination covers the whole entity, one product line, or a narrower unit, which the 2017 criteria allow. Exclude what customers do not rely on and say so explicitly. The output is a boundary diagram or list that a CPA firm and an engineer would both read the same way.
Identify infrastructure and third parties inside the boundary
Inventory the cloud accounts, hosting regions, identity providers, code repositories, monitoring and logging services, data stores, backup locations and support vendors that the boundary depends on. For each one, note who operates it, where its data sits, and whether the organization holds its own controls over it. Include locations where staff or contractors access the system. The output is a dependency register that shows every organization whose controls the service relies on, which becomes the input to the subservice decision.
Choose the trust services categories
Confirm that security is in scope, since the common criteria apply to every SOC 2. For each additional category (availability, confidentiality, processing integrity and privacy), compare it against the commitments from the first step and decide whether a customer relies on it. Note that processing integrity is framed around providing services or producing goods, and that privacy adds points of focus to nine common criteria. The output is a documented category decision with a reason for each inclusion and each exclusion.
Decide inclusive or carve-out treatment for each subservice organization
For every third party in the dependency register, decide whether its controls will be included in the examination and tested, or carved out and covered by its own SOC report and complementary subservice organization controls. Check whether the provider publishes a current SOC report that covers the services you use, and whether that report's period and scope match yours. Confirm this with the provider and your CPA firm, because the treatment shapes the system description and the testing effort. The output is a table of providers with their treatment, the reason, and the report you will rely on.
Write the scope statement
Combine the boundary, categories and subservice decisions into one scope statement. It should name the system, the services, the locations, the categories, the excluded items and the treatment of each subservice organization. Review it with engineering, product and legal, and confirm that the customer-facing commitments from the first step are covered. The statement becomes the basis for the system description and for management's assertion, so changes after this point should be recorded and reviewed. The output is an approved, dated scope statement that the leadership team has signed off.
Confirm the scope with the examining CPA firm
Share the scope statement with the CPA firm that will issue the report, and ask it to confirm that the boundary, categories and subservice treatment are acceptable for the report the customer requested. Ask the firm to note any open questions about the period, the third parties or the complementary controls before readiness work starts. Keep the firm's written response with the scope record. The output is a scope that the firm has reviewed in writing, so that readiness effort is spent on controls the examination will actually test.
When a SOC 2+ report that adds other criteria makes sense
A SOC 2+ report is worth considering only when a customer's regulator or contract names a specific framework or control list that the trust services criteria do not cover, or when a particular subject matter must be reported on and no standard category fits it. The AICPA's October 2022 SOC 2 guide includes an illustrative report for this case, in which the report also addresses criteria or subject matter beyond the trust services criteria. Start by asking the customer or regulator exactly what they need reported: a named control set, a specific system component, or a yes or no answer that a standard SOC 2 could already give. If the answer is the last one, a plain SOC 2 with a clear system description is usually the better route.
The extra work is real and recurs. The CPA firm must test the added criteria as well as the trust services criteria, so the examination grows in procedures, evidence and sample sizes, and the organization must map each added requirement to its own controls and keep them operating across the observation period. Expect the readiness and remediation effort to increase, and ask the firm to quote the added testing as a separate line in the engagement letter so the cost can be compared with a standard examination. Also confirm that the firm is willing and qualified to accept the added criteria at all, because an auditor may decline criteria it is not competent to test.
Ask the CPA firm early, before any readiness work starts, whether it will accept the added criteria and under what conditions, and get the answer in writing. Also weigh the cost to readers: a report that mixes trust services criteria with other requirements can be harder for customers and their vendor-review teams to read, and some of them will compare it against a standard SOC 2 they already accept. Where a single customer or regulator needs a specific control set, a separate assessment against that framework, using a suitable assessor, may serve them better than changing the report that every customer receives.
Scope mistakes that cause exceptions, rework or a report nobody accepts
Most SOC 2 scope problems surface late, during fieldwork or when a customer reads the report. The pitfalls below share one root cause: the system boundary, the categories, the subservice organizations and the locations were not written down once and then held consistent across every document.
Boundary leaves out a production component
The system description omits a production service, database, admin console or integration that customers actually use, so controls over it are never tested. Before fieldwork, trace a real customer request end to end through every component, from the API to storage, backups and support tooling. Ask the CPA firm to confirm the boundary matches that trace, and list anything excluded with a stated reason.
Category added without supporting controls
Adding availability, confidentiality, processing integrity or privacy to the scope commits the organization to additional criteria, and each one needs controls that operate over the period. A team that adds privacy without notice, choice or retention controls will report exceptions it could have avoided. Add a category only when a customer requirement and an owned set of controls both exist.
Carve-out provider without a SOC report review
When a cloud provider is carved out, its controls are excluded from testing and must be covered by complementary subservice organization controls. Teams that never collect or read the provider's current SOC report cannot show that those controls exist or that the carve-out is reasonable. Obtain the provider's report, map the listed complementary controls to your own, and record how you monitor the provider between reports.
Scope changes after fieldwork starts
Adding a service, retiring a region or moving a database after the observation period begins can invalidate sampled evidence and force a rewrite of the system description. Freeze the boundary, categories and locations in writing before the period starts, and route any change through a documented review. Tell the CPA firm in advance, so it can decide whether the change affects testing or needs a separate disclosure.
Description and contract disagree
When the system description, the security commitments in customer contracts and the public trust page name different services, data types or commitments, a reader will question which one is true. Reviewers often compare the report against the contract before they accept it. Assign one owner to the boundary definition, and check each contract template and trust page against it before the report is issued.
Locations and entities missing from one document
A data center, office, subsidiary or contractor site listed in the system description but absent from the control matrix, asset inventory or access review leaves a gap that an assessor will find. The reverse also happens, where a location is tested but never described. Reconcile the list of locations and legal entities across the description, the asset inventory, the control matrix and the evidence set before fieldwork.
Who decides the scope, who drafts it and who tests it
Leadership and product owners decide which services the organization is willing to commit to in front of customers, banks and partners. That decision comes first because it sets what a SOC 2 report is expected to describe. The organization owns the scope and the controls that support it. An implementation partner can help prepare systems and evidence, but the decision about what the report covers belongs to the business.
- Service commitments: Name the products, modules and customer-facing services that customers actually buy and rely on.
- Contractual promises: Identify which availability, confidentiality or data handling commitments appear in customer contracts and security addenda.
- Excluded products: Record any product line, region or legacy service that will stay out of the report, and the reason, so customers are not surprised later.
- Category decisions: Decide with the compliance lead which trust services categories customers have asked for beyond security.
- Budget and timing owners: Assign a named executive who approves scope changes, since later changes can affect fees and the observation period.
Check that the commitments leadership has made in sales materials match the scope written down before the auditor is engaged.
The compliance lead and engineering team turn business decisions into a technical boundary. They list the infrastructure, accounts, applications, people and data flows that support the in-scope services, and they decide how each trust services category maps to controls. This draft is the working basis for the system description and the control matrix, so it needs to be accurate about where data lives and who can change production.
- System boundary: List production and supporting environments, including cloud accounts, clusters, repositories, identity providers and corporate systems that touch the service.
- Locations and entities: Record the offices, data centers and legal entities involved, and confirm which of them the report covers.
- Subservice organizations: Identify each cloud provider, hosting company or managed service and whether it will be included or carved out.
- Category choices: Document why each added category is or is not in scope, tied to customer requirements.
- Open-source platforms: Note self-hosted components that run controls, since their configuration and logs will become evidence.
Before finalizing the draft, confirm with the auditor that the boundary and category choices are the ones the report will need to describe.
The independent CPA firm does not decide scope for the organization, but it does evaluate whether the scope and description are fairly presented and then tests the controls within them. Because the auditor's judgment shapes the final report, its view should be requested before significant work starts. The CPA firm issues the report. Neither the organization's staff nor any implementation partner can issue it.
- Early scope review: Ask the firm to comment on the proposed boundary, categories and subservice treatment before readiness work begins.
- Description assessment: The firm judges whether the system description is complete and accurate enough for a reader to understand what was examined.
- Testing approach: The firm decides which controls it will test, how it samples, and what evidence it requests.
- Engagement terms: Confirm in the engagement letter who is responsible for each item, and what the firm needs from management.
- Independence: Ask whether the firm or its affiliates are also preparing your controls, since that affects what the firm can accept as its own testing evidence.
Ask the firm in writing to confirm its view of scope so the boundary is not changed after fieldwork has started.
Scope questions buyers ask before they hire outside help
Can we leave a cloud provider out of the SOC 2 scope?
Yes, but only by choosing how the provider is handled, not by ignoring it. A cloud provider that hosts part of your system is a subservice organization. You can use the inclusive method, where its controls are tested as part of your report, or the carve-out method, where your report excludes its controls and relies on its own SOC report and the complementary subservice organization controls you document. Carve-out is common because the major cloud providers publish their own SOC reports, but the choice affects what your customers read and what your auditor must test. Confirm with the CPA firm which method fits your architecture, how it will review the provider's report, and which controls remain your responsibility.
Do we need privacy in scope if we only process customer data for them?
Not automatically. Privacy is an optional category, and it is usually added when your customers ask for it or when your commitments to them describe how personal information is collected, used, retained and disclosed. If you process personal information on a customer's behalf and your service commitments do not speak to privacy, the security category alone may satisfy the request. If privacy is in scope, the 2017 Trust Services Criteria add 18 privacy criteria (P1 to P8), and nine common criteria carry additional points of focus. That raises the number of controls to design, test and describe. Ask the CPA firm to review your commitments and the customer's contract wording together before deciding.
Can a SOC 2 cover one product line instead of the whole company?
Yes. The Trust Services Criteria can be applied to an entire entity, to a subsidiary or division, or to narrower levels, so a report can cover a single product, service or environment. The boundary must be clear enough that the system description says exactly which software, infrastructure, people, procedures and data are included. Problems arise when the product shares identity systems, deployment pipelines, support staff or hosting accounts with excluded products, because those shared components must be described and controlled consistently. Confirm with the CPA firm how the boundary will be drawn, how shared services are handled, and whether customers will accept a report that covers only that product.
Who signs off on the SOC 2 scope?
Management of the service organization owns the scope. Management decides which systems, services, locations and trust services categories are included, and it writes the system description and the assertion that the report relies on. The CPA firm then evaluates whether that scope and description are reasonable and fairly presented, and it tests what management has declared. An implementation partner or consultant can prepare the scope statement and the evidence behind it, but cannot approve it on the organization's behalf or issue the report. Expect the executive sponsor, the security lead and the person who signs the assertion to agree the scope in writing before the auditor starts fieldwork.
How much work does changing the scope after kickoff create?
Scope changes after kickoff can be costly because they change the controls to be designed, the evidence to be collected and the population the auditor samples. Adding a category, such as availability or confidentiality, adds criteria to test. Adding a new product, region or subservice organization adds system components and documentation. Removing a component can also require re-describing the boundary and explaining the change in the report. The work recurs for each change, so the cost depends on how much evidence has already been collected and how far fieldwork has progressed. Ask the CPA firm for its change process, any fee impact in writing, and how a change would affect the observation period for a Type 2 report.
Can we do the SOC 2 scoping ourselves?
Your team can draft the scope, but the decision should be tested by the CPA firm that will issue the report. Scoping requires an inventory of systems, data flows, subservice organizations and people, along with a clear view of the commitments made to customers. Internal teams often know these well, but they may miss shared infrastructure or data stores that the auditor will ask about. Ask the CPA firm to review a draft scope before the readiness work begins, and confirm whether its feedback is part of the examination fee or a separate readiness engagement. If the same firm helps prepare the scope, confirm how it will keep its independence when it later issues the report.
How DeployOpen helps you set and document the scope
DeployOpen helps organizations decide which systems, services, locations and trust services categories belong in a SOC 2, then documents those choices so the CPA firm and customers can follow them. DeployOpen prepares the systems and records, while the independent CPA firm decides whether the scope and report are acceptable.
How we scope
- We map the systems, services, data flows and locations that support the service in scope.
- We recommend which trust services categories to add beyond security, with the reasons for each choice.
- We record how each subservice organization such as a cloud provider will be treated, inclusive or carve-out.
How we build
- We map each in-scope common criterion and any added category criteria to controls on your self-hosted platforms.
- We set up the open-source tools that produce evidence for those controls inside your own infrastructure.
- We identify the complementary user entity and subservice organization controls that the report will need to name.
How we hand over
- We deliver a written scope statement and a criteria mapping that your CPA firm can review before fieldwork.
- We document the system boundary, data flows and exclusions so the system description can be drafted from them.
- We provide a list of open decisions, such as carve-out choices, that your organization must approve and own.
How we support
- Our engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support is available as a retainer to keep scope records current as systems and services change.
- We help you confirm scope changes with your CPA firm before they take effect in the next examination period.
