SOC 2 scope and the system description

Scope is the one decision on this site that no tool can make for you, and it sets the price of everything that follows. This is how to make it, write it down, and defend it to an auditor.

Last reviewed 2026-08-31Written by Jacob Masse, TrazTech Inc.

Your SOC 2 scope is the set of systems, people and processes the auditor gives an opinion on, and the system description is the document that states it in your own words. Decide scope first, before you buy a platform, book a firm or write a policy, because everything downstream is priced against it. For a single-product cloud company the whole exercise is two pages and about half a day of argument, and skipping it is the most expensive half day on this site.

Section 3 Where your system description lands in the final report, in your words not the auditor's

What the system description actually is

A SOC 2 report has four parts: the auditor's opinion, management's assertion, your description of the system, and the auditor's tests with their results. The third part is written by you. The audit firm reviews it, argues with it and will refuse to attest against a description it thinks is misleading, but the text is yours, and it is the part a customer reads before anything else.

Scope

What the auditor gives an opinion on: which product, which environments, which supporting systems, which people and which criteria.

System description

The written statement of that scope, including infrastructure, software, people, procedures and data, plus the commitments you have made to customers about them.

Boundary

The line between in and out. Everything on the inside is testable and everything on the outside has to be defensible as out.

Trust Services Criteria

The five categories an opinion can cover: security, availability, processing integrity, confidentiality and privacy. Security is mandatory. The other four are chosen.

Subservice organisation

A vendor whose own controls your service depends on, such as your cloud provider. You either carve it out and say which controls you assume it operates, or you include it, which nobody does for a hyperscaler.

Complementary user entity controls

The things your customers have to do for your controls to work, such as managing their own users. Named in the description so a reader knows where your responsibility ends.

The scope decision, in order

Work these in sequence. Each answer constrains the next, and doing them out of order is why scope discussions go round twice.

1. Read what the customer asked for. The security schedule or the questionnaire almost always names the report type and sometimes the criteria. If it says Type 2, you cannot shortcut the observation window. If it says nothing beyond SOC 2, the answer is security alone.
2. Name the product. One product, or one platform with named modules. If you sell two things that share nothing but a logo, scope one of them. Two products in a first audit roughly doubles the evidence work and rarely doubles the deals it unblocks.
3. Draw the boundary around the production path. Everything that stores, processes or transmits customer data, plus everything that can change what does. That second clause is the one people miss: your code repository and your deployment pipeline are in scope because they can alter production, even though no customer data lives in them.
4. Decide the criteria. Security alone for a first audit unless a customer named more. Add availability if you sell an uptime commitment. Add confidentiality if your contracts define confidential information and promise handling for it. Do not add privacy because you handle personal information: that is what PIPEDA is for, and the privacy criterion is an AICPA construct that adds a large amount of work.
5. Write down what is out, and why. One line each. The marketing site, the internal analytics warehouse, the acquired product still on its own stack, the corporate network if you have no premises. An auditor will accept a stated reason far more readily than an omission.
6. Test the boundary against the awkward questions below, then get it approved by whoever can overrule an engineer, and date it.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

The awkward questions that decide the boundary

Ask each of these out loud before you write the description. Every one of them has moved a real scope late in a program, and then remediation and evidence both have to catch up.

Where Canadian law changes the boundary

SOC 2 does not test statutory compliance, so PIPEDA, Law 25 and provincial health privacy law do not appear in the criteria. They still change the boundary, because you cannot credibly describe a system as out of scope while telling a regulator it holds personal information you are accountable for.

Under PIPEDA, accountability stays with you when personal information moves to a processor, which means the vendor holding it belongs in your description as a subservice organisation or in your vendor controls. Under Quebec's Law 25, a project that involves personal information may require a privacy impact assessment before it launches and a named person in charge of the protection of personal information, and if the system doing that work sits outside your SOC 2 boundary a Quebec buyer will notice the mismatch. If you hold health information for a custodian, read the agreement with them before drawing anything, because it commonly names retention, notification and audit rights stricter than the criteria ask for.

What differs by province is covered on the readiness consultants guide, which has a page for each of twenty markets and names the statute that applies in each.

Writing the description

Two to four pages for a first report. Write it in plain language, because the audience is a procurement analyst at your customer, not your auditor. Cover these, each in a short section:

1. What the service does and who uses it, in a paragraph a non-technical reader can follow.
2. The infrastructure: cloud provider, regions, the major components, and what is managed rather than run by you.
3. The software: your application, the significant third-party components, and the pipeline that changes them.
4. The people: which teams operate the system, and how contractors are handled.
5. The data: what customer data you hold, how it is classified, how long it is kept, and where it goes.
6. The procedures: how access is granted, how changes are approved, how incidents are handled, at the level of who does what rather than control identifiers.
7. The commitments you have made to customers about all of the above, since the criteria test you against your own promises.
8. What is out of scope, and one line of reason each.
9. Subservice organisations, carved out or included, with the controls you assume they operate.
10. Complementary user entity controls: what your customers must do.

Date it, name an approver, and version it, because it will change. Then keep it beside the checklist, since every item on that list is scoped by this document.

Changing scope mid-program

Scope changes are survivable early and expensive late. A change during preparation costs rework on policies and the gap list. A change once the observation window is open usually costs the window, because evidence for the newly included system does not exist for the days already elapsed, and a Type 2 opinion covers the whole period.

If you find a system that should have been in after the window opened, the honest options are to restart the window for a later period, to keep the original scope and add the system in the next report, or to accept an exception and explain it. Auditors have seen all three. What none of them accept is a description that quietly leaves it out. That is a misstatement in the part of the report you wrote, and it is a different category of problem from a control gap.

Common questions

The other half of the scope decision is which trust services categories the report covers, and what each one adds beyond security is the arithmetic behind it. Contractors and offshore staff are the other boundary question that gets settled late and should not be: who counts as workforce covers it.

If ISO 27001 is also on the table, settle the boundary once for both. The ISMS scope statement and the SOC 2 system description describe the same thing in different registers, and preparing for both together covers where the two diverge.