Compliance Artifacts

The SOC 2 system description, explained (with outline)

The SOC 2 system description is Section III of your report: a management-written narrative covering your infrastructure, software, people, procedures, and data, plus system boundaries, subservice organizations, and complementary user entity controls (CUECs). Here’s what it must include, who writes it, how auditors evaluate it, and an annotated outline of a strong one.

Talk to a Compliance Engineer

Last updated July 26, 2026

What the system description is

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.

What Section III must cover

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.

An annotated outline of a strong description

System description outline (Section III skeleton)

1. Overview of services. Two or three paragraphs: what the company does, which service this report covers, and the trust services categories in scope. No marketing prose — a reviewer should recognize the product they’re buying.

2. Principal service commitments and system requirements. The promises the controls exist to keep — availability targets, confidentiality obligations, contractual and regulatory requirements. Everything the auditor tests traces back to this list.

3. Infrastructure. Cloud provider, regions, production versus non-production environments, network segmentation, and the architecture diagram reviewers actually study.

4. Software. The application stack and the tooling that operates it: repositories, CI/CD pipeline, monitoring and alerting, logging, endpoint management, identity provider.

5. People, procedures, and data. Teams and their security responsibilities; the recurring processes (change management, access reviews, incident response, onboarding and offboarding); data types, flows, classification, and retention.

6. System boundaries. Which products and environments are in scope, which are explicitly out, and where responsibility hands off to providers.

7. Control environment, risk assessment, information and communication, and monitoring. Governance, hiring screens, the risk assessment cadence, how policies reach employees, and how control failures get noticed.

8. Subservice organizations. The carve-out list, with the complementary subservice organization controls assumed of each provider.

9. Complementary user entity controls. A numbered list of customer responsibilities — reviewers map these to their own obligations before they rely on your report.

10. Incidents and changes. Incidents relevant to the report’s scope — a disclosure both report types carry — and, for a Type II, significant system changes during the period, each with a line on how it was handled.

The elements auditors expect to find

Their review runs the description criteria as a checklist — run it yourself first.

Every description criterion addressed: services, commitments, components, boundaries, and control environment all present.
The five components each described specifically — infrastructure, software, people, procedures, data — not gestured at.
Boundaries precise enough that a reader knows exactly which product and environment the opinion covers.
Each subservice organization named, the carve-out method stated, and complementary subservice organization controls listed.
Complementary user entity controls enumerated as an actual list, not a throwaway sentence.
Controls described as they exist today rather than as the roadmap intends — aspirational language is the most common revision request.
Consistency with the management assertion, the opinion letter, your policies, and what your engineers will say in walkthroughs.
Relevant incidents disclosed rather than discovered — plus, for a Type II, significant changes during the period.

Who writes it — and how long it runs

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.

How auditors evaluate it

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.

How Agency handles system descriptions

The system description is the most writer-intensive artifact in a SOC 2, which is why Agency automated the draft. Our M79 platform 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.

Frequently asked questions

How long should a SOC 2 system description be?

Most land between fifteen and forty pages. Complexity drives length — multiple products and subservice organizations stretch it; a single SaaS product on one cloud stays tight. Auditors judge completeness against the description criteria, not page count, so cut padding before cutting substance.

Can our auditor write the system description for us?

No. It’s management’s narrative, and independence rules prevent the firm that opines on the description from authoring it. Auditors will share outlines and point out gaps, and consultants or platforms can produce drafts — but your team has to stand behind every sentence when walkthroughs start.

What are complementary user entity controls (CUECs)?

The controls your customers must operate on their side for the system to stay secure — managing their own user accounts, configuring SSO and MFA, protecting their API keys. The description lists them so a customer’s reviewers know which responsibilities remain theirs. Sophisticated buyers read the CUEC list before anything else.

Do we rewrite the description every audit cycle?

You revise, not rewrite. Each report needs the description brought current — architecture changes, new subservice organizations, team restructures, boundary shifts — plus the Type II disclosure of changes during the period. Teams that touch it quarterly turn next year’s update into an afternoon.

Does the system description have to cover our whole company?

No — only the system under examination. Boundaries exist precisely so a report can cover one product or environment without dragging in the rest of the organization. That’s also why reviewers check boundaries first: a clean opinion on a system that excludes the product they’re buying tells them nothing.

Keep going

SOC 2 Framework Trust & Transparency SOC 2 Startup Guide SOC 2 Bridge Letter

Stop writing Section III by hand

M79 drafts your system description from live program data, and Agency engineers make it audit-true. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.