Why this matters
Scope decides what the auditor tests and how much work your team does before fieldwork. A broad scope pulls in systems and teams that do not affect the report your customers read. A narrow scope can leave out a service or data flow that the auditor later finds. Both mistakes cost time and rework.
Your report includes a system description. It names the services, infrastructure, software, people, data, and processes in scope. Once fieldwork starts, changing that description is hard because the auditor has planned samples and walkthroughs around it.
Scope also shapes the sales conversation. Buyers read the system description and the criteria section first. If the report covers one product but the buyer uses three, it may not answer their questionnaire. If it covers services you no longer sell, you carry audit work for no benefit. Treat scoping as a design decision.
Before you start
Collect the demand signal. Pull the security questionnaires, contract clauses, and customer emails that mention SOC 2. Note which service each request covers, which criteria the buyer asks about, and whether they want a Type I or Type II report. Do not scope from a single request.
Name one scope owner with authority to reject late additions. List control owners for access review, change management, incident response, backup, and vendor management. If no one owns a control, it is a poor fit for the first report.
Build a raw inventory before you decide. List legal entities, offices, cloud accounts, production applications, data stores, key SaaS tools, and subcontractors that touch customer data. Mark each item as production, corporate, or development. Share it with your CPA firm and ask how it treats shared infrastructure, subservice organizations, and corporate IT. A short conversation now prevents a scope argument later.
How to do it
Work from the outside in. Start with the service a customer buys, then trace the systems and data that support it. Do not start with the org chart or the cloud account list. Those lists grow and hide the real boundary.
Write the boundary in plain language. Name the service, customer group, legal entity, locations, production environment, and data types. State what is out of scope and why. The out of scope list matters as much as the in scope list.
Pick criteria based on evidence and demand. Security is always in scope. Add Availability, Confidentiality, Processing Integrity, or Privacy only when a buyer needs them and you can show controls for them. More criteria means more controls, samples, and interviews. For vendors, a first audit often uses the carve out method, but confirm that choice with your auditor.
- Name the service and customer set. Write one sentence that names the product, the customer type, and the legal entity that sells it. If two services share the same code, infrastructure, and support team, consider one boundary. If they have separate environments or support teams, treat them separately.
- Draw the system boundary. List the production applications, databases, cloud accounts, networks, and key SaaS tools that store, process, or transmit customer data. Add the people and processes that operate them. Put everything else on an out of scope list with a reason.
- Map data flows and dependencies. Trace customer data from entry to storage, backup, and deletion. Note every third party that receives it and every internal team that can access it. This map becomes the backbone of the system description and the evidence plan.
- Choose the trust services criteria. Start with Security. Add other criteria only when a buyer asks and you have controls you can test. For each chosen criterion, name the control owner and the evidence source. Drop any criterion with no owner or no repeatable process.
- Set the vendor treatment. List vendors that provide infrastructure, monitoring, payment, support, or identity. Decide carve out or inclusive with your auditor. For carve out, document the complementary subservice organization controls you rely on and the evidence you will request from each vendor.
- Fix the report period. For a Type II report, choose a period long enough to show controls operating, often three to twelve months. Confirm it with your auditor and the customer. Make sure your evidence systems can produce samples across the whole period, not just the last month.
- Write and approve the scope memo. Put the service, boundary, criteria, vendor treatment, period, and exclusions in a two to four page memo. Have the executive sponsor, control owners, and auditor review it. Version it and freeze it before fieldwork begins.
- Test with a walkthrough. Pick one customer request and trace it through the in scope systems. Pick one control and pull a sample. If either path leaves the boundary, fix the memo now. A walkthrough with the auditor is cheaper than a scope change later.
How to check it worked
Run a trace test. Take one customer onboarding or support ticket and follow it through every system, team, and vendor in scope. If the trace hits a system that is not in the system description, the boundary is wrong. If it hits a system that is out of scope, write down why that is acceptable.
Check coverage by criterion. For each criterion in scope, list the controls, owner, evidence, and sample source. If a criterion has no evidence source, remove it or build the control. Do not keep a criterion just because a template included it.
Read the draft system description as a buyer. Can a customer tell which service is covered, which entity provides it, and what they must do on their side? Are the complementary user entity controls clear? Confirm that the auditor's plan matches your memo before fieldwork starts.
Mistakes to avoid
Scoping the whole company by default. Corporate IT, development laptops, marketing sites, and internal finance systems can pull in controls and evidence that do not serve the report. Include them only when they touch the in scope service or customer data.
Choosing criteria to look impressive. Privacy and Processing Integrity add real work. If no customer asks and no control owner exists, leave them out of the first report. Add them later when the process is ready.
Forgetting the humans and the admin tools. The auditor will ask how engineers access production, how changes are approved, and how backups are restored. Identity providers, ticketing systems, chat tools, and endpoint management are part of the boundary when they control access or hold evidence.
Letting a compliance tool define scope. A tool can show templates and collect evidence, but it cannot decide which service you sell or which vendor you rely on. Write the scope first, then configure the tool to match it. Cloudverg's SOC 2 readiness assessment is a fixed price package at $7,500 and is one option among others.
Frequently asked questions
What should be in scope for a first SOC 2 audit?
The service you sell to customers, the production systems and data that support it, the people who operate and support it, and the vendors that touch customer data. Start with Security criteria and add others only when a buyer needs them and you can evidence the controls. Put everything else on a written out of scope list with a reason.
Should I include corporate IT in my SOC 2 scope?
Include corporate IT only where it can affect the in scope service or customer data. Email, identity, endpoint management, and the ticketing system often matter because they control access or hold evidence. Marketing sites and internal finance systems usually stay out unless they share the same production environment.
How long should a SOC 2 Type II period be?
Pick a period that gives the auditor enough time to see controls operate, often three to twelve months. Confirm it with your auditor and the customer who requested the report. Make sure you can produce evidence across the whole period, not just for the weeks before fieldwork.