The SOC 2 system description, explained (with outline)

Section III of a SOC 2 report is the system description: a narrative — usually the longest part of the report — describing the system under examination. The auditor writes the opinion and the test results; your company writes this. It’s governed by the AICPA’s description criteria, which work like a completeness spec: the services you provide, the commitments you’ve made, the components of the system, its boundaries, and the control environment holding it together.

It matters to two audiences at once. Your auditor tests against it — every control they examine is a control the description claims exists. And buyer security teams read it — Section III is where a customer’s reviewer learns which product, which environment, and which promises the report actually covers. A vague or padded description weakens both readings.

The backbone is five system components. Infrastructure: the cloud provider, regions, environments, and network architecture the service runs on. Software: the application itself plus the operational stack — source control, CI/CD, monitoring, logging, identity provider. People: the teams and roles that build, operate, and secure the service. Procedures: the recurring processes, from change management and access reviews to incident response and vendor evaluation. Data: what you collect, where it flows, how it’s classified, retained, and destroyed.

Around the components sit the boundary statements. System boundaries declare which products and environments are in scope — and, just as usefully, which are excluded. Subservice organizations are the providers you build on (hosting, above all), typically handled by the carve-out method with their assumed controls listed as complementary subservice organization controls (CSOCs). Complementary user entity controls (CUECs) run the other direction: things only your customers can do, like managing their own user accounts or enforcing SSO, without which certain criteria can’t be met. Incidents relevant to the report’s scope get disclosed in descriptions of both report types; what a Type II description adds is significant changes to the system during the period.

Management owns the authorship. Auditors evaluate the description but can’t write it for you, for the same independence reasons they can’t author your assertion — the firm can share outlines and flag gaps, nothing more. In practice the first draft comes from whoever runs the program (a compliance lead, a consultant, or a platform), and engineering, security, and legal then correct it against reality.

Expect fifteen to forty pages for a typical SaaS company. Complexity drives the length: a single product on one cloud provider lands short; a multi-product platform with several subservice organizations runs long. The right target is completeness against the criteria at the minimum length that achieves it — reviewers should find your boundaries without a table-of-contents safari.

Auditors test the description against reality, not against good intentions. They walk through the system with your engineers, compare the narrative to architecture diagrams and org structures, and verify what they can observe: if the description promises quarterly access reviews, they’ll sample for four; if it names a monitoring tool you decommissioned in March, that’s a misstatement. The standard they apply is “fairly presented” — accurate, complete against the criteria, and not misleading.

The predictable feedback: descriptions that read like the sales site, boundaries that don’t match what the audit was scoped for, stale tooling lists, CUECs copied from a template that don’t fit the product, and roadmap features written in the present tense. All fixable in review — but every round-trip adds days to report issuance, usually the exact days a deal is waiting on.

The system description is the most writer-intensive artifact in a SOC 2, which is why Agency automated the draft. Agency AI generates the description from the program data it already holds — components, boundaries, subservice organizations, complementary user entity controls — and our forward-deployed engineers refine it with your team until it reads true. Because one system produces the description, the assertion, and the evidence base, the three stay reconciled instead of drifting apart between drafts.

For the wider context, the SOC 2 framework page walks the full report structure, and SOC 2 run end-to-end shows everything an operated program takes off your team’s plate.