SOC 2 Scope: What to Include and What to Leave Out
Your SOC 2 scope is the boundary of the system being examined: the product or service, the infrastructure and software behind it, the people who operate it, the data it handles, and the suppliers it depends on. You define it, not your auditor. Scope drives almost everything that follows, because every system inside the boundary needs controls, evidence and testing, and every system outside it needs a defensible reason for being there.
Most first-time SOC 2 scoping mistakes run in one direction: too wide. Pulling in corporate IT, a second product nobody asked about, or an acquisition still on separate systems can double the work without making the report any more useful to the customer who asked for it.
What is SOC 2 scope?
SOC 2 scope has two separate layers that are often confused. The first is which Trust Services Criteria you report against: Security is mandatory, while Availability, Confidentiality, Processing Integrity and Privacy are optional additions. The second is the system boundary, meaning which parts of your business the examination actually covers.
Choosing criteria is the better-known decision and which Trust Services Criteria apply covers it in detail. The system boundary gets far less attention and has a larger effect on cost, timeline and how much of your organisation has to change. The two decisions are independent: you can report on Security only across a wide boundary, or on four criteria across a narrow one.
How do you define your SOC 2 system boundary?
Work backwards from the customer who asked for the report. They want assurance about the service they buy from you and the data they give you. Everything that stores, processes or transmits that data, or that could affect its security, is in. Everything else needs a reason.
- Name the service. One product, one platform, or a named set. If you sell three products on separate stacks, scoping all three because they share a logo is a choice, not a requirement.
- Map the data flow. Follow customer data from ingestion to deletion. The systems it touches are your starting boundary.
- Add the supporting infrastructure. Identity provider, code repositories, deployment pipeline, logging and monitoring. These affect security even though customer data may never sit in them.
- Add the people. Engineering, support, anyone with production access. Their onboarding, offboarding, training and access reviews become in-scope controls.
- Decide on suppliers. Each one is either carved out or included, which is a formal choice covered below.
- Write the boundary down. This becomes your system description, and ambiguity here turns into argument during fieldwork.
Corporate IT is the recurring judgement call. A laptop used by an engineer with production access is clearly relevant. The finance team’s accounting software usually is not, unless it touches customer data. Scoping all of corporate IT in by default is the most common way an Australian SMB accidentally triples its SOC 2 workload.
What is the difference between carve-out and inclusive method?
Every SOC 2 report has to address the suppliers you depend on, called subservice organisations. Your cloud provider is the obvious one, but so are managed service providers, payment processors and anyone else performing controls that matter to your customers. You handle them one of two ways.
| Carve-out method | Inclusive method | |
|---|---|---|
| What it means | The supplier’s controls are excluded from your report and described, not tested | The supplier’s relevant controls are tested as part of your examination |
| What your report says | Names the supplier, the controls they perform, and the controls you assume they operate | Covers their controls alongside yours in the testing section |
| What it requires of you | Monitoring evidence, typically review of their own SOC 2 report each year | The supplier’s co-operation, their auditor’s involvement, and usually a contract clause |
| How common it is | The default, used for nearly all cloud providers | Rare, mostly where a supplier is effectively an extension of your own operation |
| Effect on your workload | Lower, but you must evidence that you review their reports | Higher, and dependent on a third party’s timeline |
Carve-out is right for almost every Australian SMB, and no auditor will question carving out a major cloud provider. What they will question is carving one out and then holding no evidence that you ever read their report. The carve-out is not a way of ignoring the supplier, it is a way of relying on them deliberately. How to vet a supplier’s SOC 2 report covers what that review should look like.
What happens if your SOC 2 scope is too wide or too narrow?
Both errors are expensive, in different currencies. A scope that is too wide costs money and months. A scope that is too narrow costs you the deal the report was meant to win, and you will not find out until a customer’s security reviewer reads it.
The narrow-scope failure is the more damaging of the two, because it surfaces late. A report that excludes the very module a customer uses, or that covers a staging environment rather than production, reads to a reviewer as an attempt to game the examination even when it was an honest mistake. If a specific customer drove the project, it is entirely reasonable to ask what they need to see covered before you finalise the boundary.
How do you keep track of controls once the scope is set?
Once the boundary is fixed, every system inside it generates controls and every control generates evidence across the observation period. You need somewhere to hold the control list, the policies and the evidence, and the honest answer is that several options work at SMB scale.
A spreadsheet is free and fine for a narrow scope, though it degrades once several people maintain it. A consultant running the programme keeps it organised and is the most flexible option. An enterprise platform such as Vanta or Drata automates evidence collection through deep integrations, which earns its cost for larger teams. A lighter option is CertAssist, a separate company founded by members of the Siege Cyber team, which lists US$375 per month and has no integrations at all, so it holds no access to your systems. The trade-off is automation on one side and simplicity on the other.
Whichever you choose, none of them decides your scope for you. That decision is commercial and architectural, and it is made before any tool is involved.
Common questions about SOC 2 scope
What is a SOC 2 system description?
The system description is the section of a SOC 2 report where you describe the system being examined: what the service does, the infrastructure, software, people, procedures and data involved, the boundary, your subservice organisations, and the controls you have implemented. You write it, your auditor assesses whether it is fairly presented, and it is the part of the report a customer’s security reviewer reads most closely. The AICPA’s SOC suite of services sets the requirements it must meet.
What does a SOC 2 audit include?
A SOC 2 examination covers the Trust Services Criteria you selected, applied to the system boundary you defined. The auditor assesses whether your system description is fairly presented, whether controls were suitably designed, and for a Type 2 whether they operated effectively across the observation period. Anything outside your stated boundary is not examined, which is exactly why the boundary matters so much.
Can you change your SOC 2 scope between reports?
Yes, and many companies do, usually widening scope as they grow or adding a criterion a customer asked for. Changes are noted between reporting periods, and a reader comparing two reports will see the difference. Widening is read positively. Narrowing invites questions, so if you reduce scope, be ready to explain why in plain terms, ideally because a product was retired rather than because something became inconvenient.
Does SOC 2 scope include your whole company?
Usually not, and it should not by default. SOC 2 examines a system, not an organisation. A company with one product and twenty staff may find the boundary covers nearly everything, while a company with three products and two hundred staff might scope a single platform. The test is whether the boundary covers what your customers rely on, not whether it covers your whole business.
How does scope affect SOC 2 cost and timeline?
Directly and substantially. More systems mean more controls, more evidence to collect across the observation period and more auditor testing, so both the audit fee and your internal effort scale with the boundary. A narrow, well-defined first scope that you widen in year two is usually faster and cheaper than an ambitious first attempt. Preparing for a SOC 2 audit covers the full sequence.
Setting a scope you can defend
Write your boundary down in one paragraph before you talk to an auditor, and read it as though you were the customer who asked for the report. If it covers the service they buy and the data they hand you, it is right. If you find yourself hoping they will not notice an exclusion, it is not.
Then resist the urge to scope wide to look thorough. Nobody is impressed by a broad SOC 2 report, they are only interested in whether it covers the thing they are buying. A tight boundary you can evidence properly beats a generous one you cannot. A readiness assessment is a low-cost way to test whether your boundary holds up before the examination starts.
Siege Cyber helps Australian companies scope SOC 2 sensibly and get through the examination without paying for coverage nobody asked for. See our SOC 2 services or get in touch.