The SOC 2 system description is management's own account of the system the report covers, written against the AICPA's DC 200 description criteria, and it is what the auditor's opinion is about. It sets out the services provided, the service commitments and system requirements, the components of the system (infrastructure, software, people, procedures and data), any significant incidents, the criteria and related controls, the complementary user entity and subservice organization controls, and any significant changes during the period. The auditor gives an opinion on whether the description is fairly presented, so it has to match the system as it actually ran.
A SOC 2 report is usually organized into a handful of sections: the auditor's report, management's assertion, the description of the system, and, in a Type 2, the criteria, controls, tests and results. The system description is the longest piece management writes and the one first-time companies most underestimate.
What DC 200 asks for
The AICPA's description criteria for SOC 2, known as DC 200, set out what the description has to disclose. In plain terms:
| Element | What to write |
|---|---|
| Types of services provided | What the service is and who uses it, in terms a customer would recognize |
| Service commitments and system requirements | What you promise customers about security and the other categories in scope, and the requirements the system has to meet to keep those promises |
| System components | Infrastructure, software, people, procedures and data that make up the system |
| Significant incidents | System incidents that caused a failure to meet commitments or requirements, and their nature, timing and extent |
| Criteria and related controls | The Trust Services Criteria in scope and the controls that address them |
| Complementary user entity controls | What the design assumes customers do themselves |
| Subservice organizations | Which vendors perform part of the service, how they are treated, and the controls you assume they operate |
| Criteria not relevant | Any criterion that does not apply to the system, and why |
| Significant changes | Changes to the system during the period, for a Type 2 |
Drawing the boundary
The boundary decides what is in scope. A clear description names the production environment, the services and data stores inside it, the tools used to build and deploy it, and the people and teams who operate it. Leaving something out because it is untidy, such as an internal admin tool with production access, is the kind of omission an auditor finds in walkthroughs, and it forces a rewrite.
Writing the system components
- Infrastructure: cloud providers and regions, networks, environments and how they are separated.
- Software: the application, its main services and the third-party software it depends on.
- People: the teams that build, operate and govern the system, and their responsibilities.
- Procedures: how access, changes, incidents, monitoring and vendors are handled, in summary.
- Data: the kinds of data the system processes and stores, how it flows and how it is protected.
Commitments and requirements
Service commitments are what you have promised customers in contracts, terms, SLAs and public statements, such as encrypting data or notifying them of incidents. System requirements are what the system has to do to keep those promises. They are the reference point for the whole report: the controls exist to meet them, and an incident is significant when it caused a failure to meet them.
Complementary controls and subservice organizations
The description lists what you assume customers do and which vendors perform part of the service, with the controls you assume each one operates. The guide to CUECs and subservice organizations covers carve-out and inclusive treatment in detail.
Mistakes that cause rework
- Describing the target state instead of what ran during the period.
- Copying a template that names tools or procedures you do not use.
- A boundary that leaves out systems with access to production or customer data.
- Procedures described in more detail than the controls actually support, which the auditor then has to test.
- Forgetting to record significant changes that happened during the period.
The AICPA's 2027 exposure draft also revises the description criteria alongside the Trust Services Criteria; the article on the 2027 criteria covers what is changing.