SOC 2 Scope Determination: An Actionable Playbook

SOC 2 scope determination is the process of defining exactly what your audit covers: the service being examined, the systems and data that support it, the people and procedures that operate it, the third parties it depends on, the Trust Services Criteria categories included, and whether the report is Type 1 or Type 2. Security’s 33 Common Criteria (CC1 to CC9) apply to every engagement, and each optional category adds its own criteria on top. Nearly every report also includes Security as a category.

A customer or procurement team has asked for a SOC 2 report, and someone now has to decide what “getting SOC 2” means for your company. Scope too broadly and you spend months of engineering time on controls nobody asked for. Scope too narrowly and the report fails the enterprise buyer who requested it. Scope sets the cost, the timeline, the evidence load, and whether the report helps close deals, so treat it as a business decision with audit consequences.

Our one-page scope worksheet turns the decisions below into something you can copy and send to an auditor. Once the worksheet is filled, run the 90-second readiness check to pressure-test the in-scope controls.

What should your SOC 2 scope start with?

Start with the service customers buy, not with a list of controls. Name the product or service in the words your contracts use, then draw the boundary around the systems, data, people, and procedures that deliver it. That boundary tells the auditor what to test and tells your buyers what the report covers.

If you sell one core SaaS platform, scope that. If you also sell managed services or run internal analytics consulting, leave them out of the first report unless buyers are asking for them. Teams often pull in a staging environment nobody outside the company touches, an old internal tool, or a side product with no enterprise demand. Each addition brings more evidence requests, walkthroughs, and testing. A system you could remove without changing the commitments you make to customers deserves a hard look before it goes in.

Read your customer commitments before you finalize anything: MSAs, security addenda, SLAs, and questionnaire answers. Sales language tends to widen scope more than architecture does, and an auditor will test against what you have promised in writing.

Who has to agree on scope before the audit starts?

Scoping usually breaks before the auditor arrives, when sales promises one thing, engineering supports another, and legal uses broader contract language than either. Get the CTO or head of engineering, the security lead, someone from support or operations, whoever owns contracts, and a sales lead who hears the buyer questions into one meeting, and leave with written decisions.

Four decisions need to be on paper: the exact service name for the report description, the customer commitments attached to it, the environments that support it (production almost always, staging and development depending on how close they sit to production), and the roles with operational responsibility for deploys, access, incidents, changes, and support.

An asset inventory then makes the decisions testable. List the cloud accounts, CI/CD and identity systems, customer-facing and internal admin applications, the data types and where they live, the recurring procedures (onboarding, offboarding, access review, vulnerability handling, incident response, backups, change control), and the vendors that materially support the service. A missing item here is the usual cause of mid-audit rescoping, so the inventory should come from architecture diagrams and the vendor list, not from memory.

What belongs inside the system boundary?

The system boundary covers five components: infrastructure, software, people, procedures, and data. The glossary in the AICPA’s Trust Services Criteria defines a system as the infrastructure, software, people, procedures, and data that work together to deliver the service, so a scope that ignores one of them is probably incomplete. The service description in the report is measured against the AICPA’s description criteria.

Production is the starting point. If engineers can push code that reaches customers, the deployment pipeline is in. If support staff use an admin console to change customer accounts or data, that console is in. Systems that do not support the service, such as a marketing site, an applicant tracking system, or a finance ERP, can usually sit outside, as long as you can explain why they do not affect the commitments being examined. Corporate IT (laptops, the identity provider, endpoint management) is different: staff reach production through it, so most scopes include it.

For data, record what types flow through the service, where they are stored, who can reach them, what is logged, and how backups and retention work. For people, name roles, not departments, because auditors ask who approves production access, who reviews logs, who triages incidents, and who owns each policy. A simple ownership map helps:

A component nobody owns will show up as a finding during testing, so assign owners before fieldwork starts.

Which Trust Services categories should your scope include?

Add a category when you make a commitment it would test. Security is in nearly every report. Availability, Processing Integrity, Confidentiality, and Privacy each add criteria, evidence, and audit hours, so each should match something customers rely on. Our Trust Services Criteria guide holds the full decision table; the version below starts from the business model.

Three points keep this table consistent with the criteria guide. Availability sets no uptime number: the AICPA text says the objective does not, in itself, set a minimum acceptable performance level, so your own commitments set the bar and the criteria test the capacity, backup, and recovery controls behind them. Processing Integrity is usually addressed for one system or function, not the whole company, so a billing engine can be in scope while everything else is not. And Privacy is the largest addition, 18 criteria across P1 to P8 against 2 for Confidentiality (C1.1 and C1.2). Many companies meet customer privacy needs with Security and Confidentiality controls plus a separate privacy program, and add the Privacy category when a buyer requires it.

Timing matters for a Type 2. A category added partway through a period has no operating history for the earlier months, so ask the firm whether it appears in full in this report or the next. If you are unsure which categories your target buyers expect, read their security questionnaires and the contract language before you ask an auditor.

How do vendors and customers change your scope?

Every vendor that runs a control you depend on has to be named in the report. A cloud host, an identity provider, or a payment processor is either carved out, where the report lists the controls you rely on it for without testing them, or included, where its controls are tested as part of your engagement. Carve-out is the usual treatment, and it still leaves you responsible for reviewing each vendor’s own report.

Deciding which vendors count as subservice organizations is part of scoping. The carve-out vs inclusive guide explains how to decide which vendors count as subservice organizations and what changes in the report under each method, and the vendor management requirements cover the oversight your own controls need either way. A vendor handling highly sensitive data or sitting directly inside your service promise is where a bare carve-out can leave the report less useful to buyers, and it is worth raising with the auditor early.

The dependency also runs the other way. Some of your control objectives only hold if your customers do something on their side, such as managing their own user accounts or keeping credentials private. Those are complementary user entity controls, and they are written into the system description. The CUEC guide covers how to define and document them.

How do report type and period affect scope?

A Type 1 report gives an opinion on the design of your controls as of one date. A Type 2 covers design and operating effectiveness over a period you agree with the firm, so scope decisions made at the start get tested for months. Firms commonly plan first periods of 3, 6, or 12 months, as our observation period guide explains.

Choose by who is asking and when. A Type 1 can start procurement conversations quickly. Larger buyers often ask for a Type 2 because they want evidence that controls ran consistently, not that they existed on one day. If the pipeline already depends on sustained assurance, go straight to a Type 2. If you need something to show this quarter, a Type 1 first can be the right start. Our Type 1 vs Type 2 guide compares the two and shows what firms quoted buyers through us by company size.

Scope is also the largest lever on price, because each added environment, category, and unresolved vendor dependency adds testing. Ballpark fees by company size are on our audit cost page, and ballpark quotes from matched firms are the next step once your scope is written down. Budget for remediation, tooling, and internal time as well as the auditor’s fee.

One-page scope worksheet

Copy the table below into a document, fill in the “Your answer” column, and send it with your first request to an auditor. The last column shows the answers for an invented example: a 40-person B2B SaaS company called Ledgerline that sells an invoicing application. It is an illustration of the level of detail, not a recommendation for your scope.

Fill the worksheet in the order shown, since each row narrows the next. If two people give different answers to the same row, that is a scoping disagreement to settle before an auditor sees it. Once the rows are settled, the SOC 2 compliance checklist puts scope and report selection first in its sequence and shows how to measure your controls against them, and the controls list maps each control to the evidence an auditor asks for. When you are ready to compare firms on the scope you have written down, start from the auditor directory.