Short answer: SOC 2 scope is the boundary around what the auditor examines. You define it by choosing the service being reported on, the systems, people, data and processes that support it, and the Trust Services Categories to include. Security is always required. Availability, Confidentiality, Processing Integrity and Privacy are optional and depend on what your customers rely on.
Scope is the first real decision in a SOC 2 project and the one that affects everything after it: cost, timeline, how many controls you must run and how many samples the auditor will test. A tight, sensible scope gets you a report faster. A scope that is too wide buries your team in evidence. One that is too narrow produces a report your buyers do not trust.
This guide shows how to set scope deliberately, what to include and exclude, how to choose categories and how to document the result.
What does SOC 2 scope mean?
SOC 2 reports are about a service organization’s system, not the whole company. Scope answers four questions:
- Which service or product is being examined?
- Which components make up the system that delivers it? Infrastructure, software, people, data and procedures.
- Which Trust Services Categories apply?
- Which time period or date does the report cover?
Everything inside the boundary is described in the report and tested. Everything outside is not mentioned except where it interacts with the system. A buyer reads the scope to decide whether the report covers the thing they are buying.
Step 1: Define the service and its commitments
Start with what you promise customers. These are your service commitments (for example uptime targets, data protection obligations or processing accuracy) and the system requirements you set internally to meet them. Contracts, SLAs, security pages and your terms of service are good sources.
Then decide which service or services the report covers. A small company with one product usually scopes that product. A larger company with several services might scope only the one customers ask about first and add others in later years.
Step 2: Map the system boundary
Auditors describe a system through five components. Use them as an inventory template:
| Component | What to list | Examples |
|---|---|---|
| Infrastructure | Hosting and network that run the service | Cloud accounts, containers, databases, networking, endpoints used by operators |
| Software | Applications and supporting tools | Production application, CI/CD, monitoring, ticketing, identity provider |
| People | Roles that operate or access the system | Engineering, DevOps, support, security, leadership |
| Data | Types of data processed and where it flows | Customer content, account data, logs, backups |
| Procedures | Documented and automated processes | Change management, access provisioning, incident response, vendor reviews |
Draw a data flow diagram as you go. It becomes your main scope evidence and is usually the first document the auditor asks for.
Step 3: Decide what is in and what is out
A useful test is this: if removing a system would not change the commitments you make to customers, question whether it belongs in scope. Common exclusions include:
- A marketing website that holds no customer data.
- Finance, HR or recruiting tools that do not touch the service.
- Development and test environments that never contain production data.
Exclusions must be genuine. If a developer laptop can reach production data, it is in scope for the controls that protect that path. Write down why each excluded item is out, because the auditor may challenge it.
Step 4: Choose the Trust Services Categories
There are five categories. Security is mandatory in every SOC 2 report. The others are optional and should reflect what customers actually rely on. Our overview of the five Trust Services Criteria describes each one in detail.
| Category | Include it when |
|---|---|
| Security | Always. It is required. |
| Availability | Customers depend on uptime, you have SLAs, or the service is operationally critical. |
| Confidentiality | You hold customers’ confidential business information, such as contracts, source code or financial records. |
| Processing Integrity | The accuracy and completeness of processing is central, such as payments, calculations or data transformation. |
| Privacy | You collect and handle personal information and customers expect assurance about it. |
For a first report, starting with Security alone is often the sensible choice. Each added category brings more criteria and more evidence. You can add categories in later years as customer demands grow.
Step 5: Handle third parties
Your system depends on providers such as your cloud host, payment processor or support platform. In SOC 2 these are subservice organizations. You can either present them with the carve-out approach, where their controls are described but not tested, or the inclusive approach, where their controls are tested as part of your report. Most cloud-hosted companies use carve-out and rely on the provider’s own SOC report, while documenting the controls they must operate on their side.
Our article on subservice providers and your SOC 2 explains why you cannot assume that a major provider’s report covers your responsibilities, and third-party risk management for SOC 2 covers how to review vendors.
Step 6: Document the scope
Capture the result in a short scope statement that you can reuse in the system description and share with your auditor. A good statement includes:
- The service name and a plain description of what it does.
- The categories in scope.
- The systems, locations and teams included.
- Named exclusions and the reason for each.
- Subservice organizations and how they are treated.
- The period or date the report will cover.
Example scope statement
The in-scope system is the Acme Analytics web application and its supporting production infrastructure hosted in a public cloud. The report covers the Security and Availability categories. In scope are the production application, database, deployment pipeline, identity provider, monitoring tools and the engineering, DevOps and support teams. Excluded are the corporate marketing website and internal finance systems, which do not store or process customer data. The hosting provider is treated as a subservice organization using the carve-out method.
Common scoping mistakes
- Scoping everything. Including every tool and team for the sake of completeness multiplies evidence and cost.
- Scoping too narrowly. A report that omits the system the buyer uses raises questions and may be rejected.
- Adding every category at once. Extra categories add criteria you may not need yet.
- Forgetting shadow systems. Unmanaged tools that hold customer data, such as shared spreadsheets, are easy to miss.
- Not revisiting scope. Acquisitions, new products and new regions change the boundary.
- Treating exclusions casually. If you cannot explain an exclusion in one sentence, it probably does not hold.
How scope affects cost and timeline
Each added system, team and category increases the number of controls, evidence items and samples. A narrow, well-defined scope shortens preparation and audit time and makes the observation period easier to run. If you are comparing budgets, our guide to SOC 2 compliance cost in India breaks down what drives price, and the SOC 2 audit timeline shows where scope decisions land in the schedule.
Practical recommendations
- Start from what customers ask for in security reviews, then work backward to categories.
- Keep the first scope small and credible, then expand.
- Review scope with your auditor before you begin remediation, since the auditor decides whether it is reasonable.
- Re-confirm scope at the start of every observation period.
- Use a gap assessment to check that everything inside the boundary has working controls. Our guide to SOC 2 gap analysis shows how.
If you are a young company deciding where to start, the SOC 2 for startups page outlines a practical path, and our SOC 2 readiness service includes a scoping workshop. After you set scope, the next planning question is how long to run your examination. See the SOC 2 observation period guide for that.
A scope review checklist you can reuse
Scope is a decision, not a discovery. Rather than listing every system you own, start from the services you commit to deliver and work backwards. The questions below help you test whether your boundary is both honest and practical.
- Which services do customers actually buy? Include the systems that deliver them, and describe those services accurately.
- Where does customer data live and travel? Follow it from entry to storage to deletion, including backups and logs.
- Who can touch production? Employees, contractors, vendors and automated accounts all count.
- Which vendors perform part of the service? Decide whether each is a subservice organization and how it will be presented.
- Which trust categories do customers need? Add categories because of real commitments, not because they sound impressive.
- What is deliberately out of scope? Write the reason down, such as an internal tool with no customer data or a product line not yet launched.
Revisit scope when things change
A new product, cloud region, acquisition or major vendor should trigger a scope review before it affects an observation period. Record the decision and the date. Auditors prefer a documented decision over a silent assumption, and customers will notice if the report does not match the service they use. If you need a structured start, our SOC 2 readiness service includes scoping, and our guide on gap analysis shows how scope feeds the rest of the work.
Frequently asked questions
How do you scope a SOC 2 audit?
Identify the service being reported on, map its infrastructure, software, people, data and procedures, choose the Trust Services Categories, decide how to treat subservice providers and document exclusions.
What is the SOC 2 system boundary?
It is the line around the components that deliver the in-scope service. Everything inside is described and tested, and anything outside is excluded unless it interacts with the system.
Which Trust Services Categories are required for SOC 2?
Only Security is required. Availability, Confidentiality, Processing Integrity and Privacy are optional and chosen based on customer needs.
Should a startup include all five categories in its first SOC 2?
Usually not. Security alone is a common first scope. Add other categories later as customer demands justify the additional work.
Does SOC 2 cover the whole company?
No. It covers a defined system and service. Many small companies scope their one product, which can make it feel like the whole company is in scope.
Can I change SOC 2 scope later?
Yes. You can expand or adjust scope in a later period, but a change mid-period needs agreement with your auditor and can complicate the report.
Conclusion
Good SOC 2 scoping starts with customer commitments, produces a clear boundary and ends with a documented statement your auditor agrees with. Keep the first scope focused, include only categories you can justify, treat vendors honestly and revisit scope each year. A well-chosen scope makes every later step easier.
