What Section III is
The system description is Section III of a SOC 2 report, and you write it — not your auditor. It describes the system in scope: what the service does, where its boundaries fall, the infrastructure and software supporting it, the people and procedures involved, and any subservice organizations you depend on.
The auditor evaluates whether it is fairly presented and consistent with what they observed. They do not author it. That division is why the description is so often the last thing finished, and the least considered part of a first report.
It is also, for a customer's security reviewer, one of the two sections that actually get read — the other being Section IV. See what a SOC 2 report contains for the full structure.
What belongs in it
| Element | What it covers | Where it goes wrong |
|---|---|---|
| Services provided | What the system actually does for customers | Marketing copy instead of a system description |
| Boundaries | What is in scope and, explicitly, what is not | Left vague, so scope is ambiguous |
| Infrastructure | The environments, regions and components involved | Describing an architecture that has since changed |
| Software | Applications and supporting tooling in scope | Listing everything the company owns |
| People | Roles involved in operating the system | Named individuals who then leave |
| Procedures | How the service is operated and supported | Aspirational rather than actual |
| Data | What data flows through and how it is classified | Omitting data types customers care about |
| Subservice organizations | Third parties whose controls matter to yours | Not naming the cloud provider at all |
| Complementary user entity controls | What customers must do for your controls to work | Used to offload responsibility |
Boundaries are the whole game
A SOC 2 report says nothing about anything outside the described system. That is not a loophole; it is how scoped assurance works. But it means the boundary statement carries every bit of the report's relevance.
The failure looks like this. A company runs three products. The SOC 2 covers the flagship. The description says "the Company's platform" without distinguishing them. A customer buying product two receives a clean report that does not, on inspection, cover what they bought.
Say what is out of scope explicitly. A description that names the excluded products, environments and legal entities is more useful to a buyer than one that implies everything is included, and it is considerably safer for you.
Carve-out vs inclusive
Every SaaS company depends on subservice organizations — a cloud provider at minimum, often a payments processor, a data centre, a managed database. Two ways to handle them:
| Carve-out | Inclusive | |
|---|---|---|
| Their controls | Excluded from your scope | Included in your report |
| You must state | The complementary controls you assume they perform | Their controls, tested by your auditor |
| Needs their cooperation | No | Yes — and usually they decline |
| How common | The overwhelming default | Rare |
Carve-out is what almost everyone uses. You exclude AWS's controls, state which ones you rely on them for, and your customer reads their SOC 2 alongside yours. The obligation it creates is that you must actually name those complementary controls — "we rely on our cloud provider" is not one of them.
Complementary user entity controls
These are controls your customers have to operate for yours to be effective: configuring SSO properly, managing their own users, protecting their API keys.
Listing them is legitimate and expected. Security reviewers read them as a to-do list, and a clear short list is a sign of a well-understood system.
The failure mode is using them as a liability shield. A description with fifteen complementary user entity controls, several of which look like things the vendor should be doing, reads exactly as it is — and experienced reviewers flag it. Keep the list to what genuinely sits on the customer's side of the boundary.
Why no tool writes this
Compliance automation collects evidence about controls. The system description is a narrative about architecture, boundaries and organisational structure — judgment about what to include and what to exclude, expressed in prose a stranger has to be able to act on.
That is why it is frequently the bottleneck in an otherwise well-run project, and why it is worth writing early rather than in the week before fieldwork. It also tends to surface scope questions nobody had asked out loud, which is much cheaper to discover in month one. See what platforms do not cover.
FAQs
What is the SOC 2 system description?
Section III of a SOC 2 report, written by you rather than your auditor. It describes the system in scope: what the service does, its boundaries, the infrastructure and software supporting it, the people and procedures involved, and any subservice organizations. It is the section a customer reads to check the report covers the product they are buying.
Who writes the SOC 2 system description?
You do. The auditor evaluates whether it is fairly presented and consistent with what they observed, but the description itself is management's. No compliance platform generates it, which is why it is frequently the last thing finished and the least considered part of a first report.
What is a carve-out versus an inclusive method?
Both describe how you handle subservice organizations such as your cloud provider. Carve-out excludes their controls from your description and scope, and states the complementary controls you assume they perform. Inclusive brings their controls into your report, which requires their cooperation. Carve-out is far more common.
Why does the system description matter to customers?
Because it is where they check that the scope matches what they are buying. A clean opinion on a system description covering a different product, environment or legal entity does not answer their question, and procurement teams are increasingly trained to look for exactly that mismatch.
What are complementary user entity controls?
Controls your customers must operate for your controls to be effective — configuring SSO correctly, managing their own user access, protecting their credentials. They are listed in the description, and customers read them as a to-do list. Vague or excessive ones shift responsibility in a way security reviewers notice.
Where to go next
See the full report structure in the SOC 2 audit, settle your scope in the five Trust Services Criteria, get the description drafted early as part of a readiness assessment, or start from SOC 2 compliance.