A SOC 2 system description is the management-written narrative, presented as Section 3 of a SOC 2 report, that explains the system a service organization uses to deliver its services. To be presented fairly, it must address the nine description criteria in AICPA DC Section 200. A SOC 2 Type 2 description covers all nine criteria; a Type 1 description addresses eight, because the ninth applies only to a period of time.
That single paragraph is the fact most readers come for. The rest of this guide shows you how to actually write each part, using the exact DC 200 criteria and the observations that auditors raise most often when they read a first draft.
A note on scope before we startThis article is educational and framework-based. It is not an audit opinion, and it is not engagement advice for any specific organization.
What is a SOC 2 system description?
A SOC 2 system description is the narrative in Section 3 of a SOC 2 report where service organization management describes the system, meaning the infrastructure, software, people, procedures, and data used to provide services to customers. It is written by management, not the auditor. The service auditor's job is to evaluate whether that description is presented in accordance with the description criteria and does not omit or distort information that report users need.
This distinction matters and trips people up constantly. The system description is management's assertion. The service auditor expresses an opinion on it, but does not author it. In practice, the security or GRC lead drafts it, the executive team reviews it, and the auditor tests it against DC 200.
One more precision point that affects how you frame the whole document: SOC 2 results in an attestation report, not a certification. There is no "SOC 2 certificate," a distinction we cover in is SOC 2 a report or a certificate. So the system description supports an attestation engagement performed under AT-C Section 205, using the 2017 trust services criteria in TSP Section 100.
What is DC Section 200?
DC Section 200 is the AICPA's set of description criteria used to prepare and evaluate the description of a service organization's system in a SOC 2 examination. The current version is the 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (With Revised Implementation Guidance, 2022). It defines nine criteria (DC 1 through DC 9) and pairs each with implementation guidance that helps management judge how much to disclose.
Two facts about DC 200 are worth stating cleanly, because they are exactly the kind of detail an auditor or an AI answer engine will check:
- The 2022 update revised the implementation guidance only. No description criteria were added or changed. The nine criteria are the same as the 2018 set.
- DC 200 is developed by the AICPA's Assurance Services Executive Committee (ASEC). It is used alongside, not in place of, the trust services criteria in TSP Section 100. DC 200 governs the description; TSP 100 governs whether the controls were suitably designed and operating effectively.
Management uses DC 200 to write the description. The service auditor uses the same criteria to evaluate whether the description is fairly presented. You are, in effect, writing to a rubric that your auditor will grade against.
What are the nine DC 200 description criteria?
The nine description criteria define the categories of information a fairly presented system description must address, to the extent each is relevant to the system and the trust services categories in scope. The table below states each criterion and what management is expected to disclose.
| Criterion | What it covers | What management discloses |
|---|---|---|
| DC 1 | Types of services provided | The services the organization delivers through the system (for example, a SaaS platform, payment processing, managed security, or IT outsourcing). |
| DC 2 | Principal service commitments and system requirements | The commitments made to customers (through contracts, SLAs, and published policies) and the system requirements needed to meet them. Only the principal ones relevant to a broad range of report users. |
| DC 3 | System components | The five components used to provide the services: infrastructure, software, people, procedures, and data. |
| DC 4 | System incidents | The nature, timing, extent, and disposition of any significant incidents that resulted from control failures during the period (for example, an incident causing theft, alteration, or unauthorized use of sensitive information). |
| DC 5 | Applicable trust services criteria and related controls | The trust services criteria in scope and the controls designed to meet the organization's service commitments and system requirements. |
| DC 6 | Complementary user entity controls (CUECs) | Controls management assumed customers would implement, which are necessary, in combination with the organization's own controls, to achieve service commitments and system requirements. |
| DC 7 | Subservice organizations | Any subservice organizations relied upon, disclosed using the inclusive or carve-out method, including the controls assumed to be performed by them (complementary subservice organization controls, or CSOCs). |
| DC 8 | Non-relevant criteria | Any specific trust services criterion that is not relevant to the system, and the reason it is not relevant. |
| DC 9 | Significant changes (Type 2 only) | For a period-of-time (Type 2) report, the relevant details of significant changes to the system during the period. |
DC 9 is why a Type 2 description addresses nine criteria and a Type 1 addresses eight. A Type 1 report is a point-in-time assessment, so there is no period over which "significant changes" could occur.
How to write a SOC 2 system description, step by step
Below is the drafting order I recommend to clients. It maps to the DC 200 criteria but follows the sequence that reads most naturally to report users, which is usually the order a prospect's security team will read it in.
1. Describe the services and the company context (DC 1)
Open with what the system actually does. State the service, who uses it, and how it is delivered. Keep it concrete. "We provide a cloud-based payroll platform to mid-market employers in North America" tells a reader far more than "we deliver innovative solutions." Include a short company and system overview so a reader with reasonable background knowledge can orient quickly.
2. State the principal service commitments and system requirements (DC 2)
This is one of the two disclosures the AICPA added in the 2018 criteria, and it is where thin descriptions get flagged. Write down the commitments you make to customers, then the system requirements that make those commitments achievable.
- Service commitments are external-facing promises: uptime targets in your SLA, encryption standards for stored data, password policy standards, breach notification timelines, and privacy commitments if privacy is in scope.
- System requirements are the internal specifications that let you meet those commitments: access review intervals from your security policy, background-check requirements, input validation rules from design documents, and regulatory rules such as HIPAA requirements where applicable.
Disclose the principal items, meaning those relevant to a broad range of report users, not every bespoke commitment made to a single large customer.
3. Describe the five system components (DC 3)
Cover all five: infrastructure, software, people, procedures, and data.
- Infrastructure. Physical and virtual resources: facilities, servers, storage, networks, cloud environments, and environmental monitoring.
- Software. Application programs, operating systems, middleware, databases, and whether applications are in-house, external-facing, or mobile.
- People. The roles involved in governance, operation, security, and use of the system, from developers to operators to management.
- Procedures. The automated and manual procedures through which services are initiated, authorized, performed, and delivered.
- Data. The types of data the system handles, how it flows through the system, and how it is classified and protected.
A data flow diagram or context diagram is permitted and strongly encouraged here. DC 200 explicitly allows flowcharts, tables, and diagrams to supplement the narrative.
4. Disclose significant system incidents (DC 4)
If a control failure led to a significant incident during the period, disclose its nature, timing, extent, and how it was resolved. This is the second disclosure the 2018 criteria introduced. The bar is "significant," so not every alert qualifies, but an incident involving theft, alteration, or unauthorized use of sensitive information generally does. If there were no significant incidents, most organizations state that plainly.
5. Present the trust services criteria and controls (DC 5)
Identify which of the five trust services categories are in scope (Security is always in scope; Availability, Processing Integrity, Confidentiality, and Privacy are optional). Then present the controls that meet your service commitments and system requirements. In most reports this is where the control matrix lives, often cross-referenced to Section 4, where the auditor documents the tests of controls and results.
6. List complementary user entity controls (DC 6)
CUECs are the controls you assume your customers will run for the overall system to work. A common example is expecting the customer to promptly notify you when a user should be deprovisioned. Write these as clear, testable expectations. Weak or generic CUECs are one of the most common auditor observations, discussed below.
7. Address subservice organizations (DC 7)
If you rely on a subservice organization, such as a cloud hosting provider, disclose it using either the inclusive method (their relevant components and controls are described as part of your system) or the carve-out method (you exclude their controls but disclose the types of controls, the CSOCs, you assume they perform). A typical CSOC from a cloud provider is the environmental and physical controls protecting production servers. Do not confuse CSOCs (at your subservice provider) with CUECs (at your customer).
8. Explain any non-relevant criteria (DC 8)
If a specific trust services criterion does not apply to your system, say so and explain why. This is short but should not be skipped when it applies.
9. Document significant changes during the period (DC 9, Type 2 only)
For a Type 2 report, describe significant changes to the system during the review period, with the date and the before-and-after difference. Migrating cloud hosting from one provider to another mid-period is a classic example that belongs here. If nothing significant changed, state that.
Type 1 vs Type 2: what changes in the description
| Aspect | SOC 2 Type 1 | SOC 2 Type 2 |
|---|---|---|
| What is assessed | Design of controls at a point in time | Design and operating effectiveness over a period |
| DC 200 criteria addressed | Eight (DC 1 through DC 8) | Nine (DC 1 through DC 9) |
| DC 9 significant changes | Not applicable (no period) | Required |
| DC 4 incidents | As of the specified date | Across the full review period |
The narrative content is largely the same. The Type 2 description simply speaks to a period rather than a date, which brings DC 9 into play and widens the window for DC 4 incident disclosure. If you are still deciding which report you need, see SOC 2 Type 1 vs Type 2.
A worked example: a system description excerpt mapped to DC 200
The best way to see how the criteria translate into prose is to read a short, realistic excerpt. Below is an illustrative Type 2 system description for a fictional company, Northwind Analytics, a SaaS provider that runs a cloud-based analytics platform for mid-market employers. It is written to show tone and structure, not to be copied verbatim, since your description must reflect your own system. Notice that the language stays factual and avoids puffery, and that each block maps to a specific criterion.
Company and services overview (DC 1)
Northwind Analytics, Inc. provides a cloud-based workforce analytics platform to mid-market employers in the United States. Customers upload payroll and HR data through a web application, configure reporting parameters, and retrieve processed dashboards and exports. The system in scope for this report is the Northwind Analytics production platform and the supporting infrastructure used to deliver it. Billing, marketing, and internal corporate IT are outside the scope of this description.
Principal service commitments and system requirements (DC 2)
Northwind makes the following principal service commitments to customers, communicated through its master service agreement, service level agreement, and published security and privacy policies: the platform will be available at least 99.9 percent of each calendar month, customer data at rest will be encrypted using AES-256, and Northwind will notify affected customers of a confirmed security breach within 72 hours. To meet these commitments, system requirements include quarterly logical access reviews defined in the access control policy, background checks for personnel with production access, and input validation rules specified in application design documentation.
System components (DC 3)
Infrastructure: The platform runs on Amazon Web Services in two US regions, using EC2 compute, RDS databases, and S3 storage. Software: The application is a Python and React web application supported by PostgreSQL databases and internally developed processing services. People: Engineering, security, and customer support personnel operate the system under the direction of the VP of Engineering and the Head of Security. Procedures: Automated deployment, monitoring, and backup procedures are supplemented by manual access provisioning and incident response procedures. Data: The system processes customer-uploaded HR and payroll data, which is classified as confidential and encrypted in transit and at rest.
A data flow diagram would typically accompany this section, showing customer HR data uploaded through the web application, processed in AWS, and returned as encrypted dashboard exports.
System incidents (DC 4)
No significant system incidents resulting from control failures were identified during the period from January 1, 2026 to December 31, 2026.
Complementary user entity controls (DC 6)
The platform was designed on the assumption that customers implement the following controls: promptly notifying Northwind when a user's access should be granted or revoked, maintaining the confidentiality of administrator credentials, and reviewing user access to their own tenant at least quarterly.
Subservice organizations (DC 7)
Northwind uses Amazon Web Services as a subservice organization for hosting and infrastructure, presented using the carve-out method. Northwind assumes AWS performs complementary subservice organization controls over the physical security and environmental protection of the data centers hosting the production environment.
Significant changes during the period (DC 9)
During the period, Northwind migrated its primary database from a self-managed PostgreSQL instance to Amazon RDS in June 2026 to improve availability and backup reliability. Customer data handling and encryption standards were unchanged by this migration.
Two things to note about the excerpt. The DC 4 and DC 9 blocks show how to handle the common "nothing to report" and "one notable change" cases cleanly. And the DC 6 and DC 7 blocks sit next to each other on purpose, so you can see the difference between a control you expect your customer to run (CUEC) and one you expect your cloud provider to run (CSOC).
Common auditor observations on system descriptions
These are the issues I see most often on a first draft. Fixing them before fieldwork saves rounds of revision.
- Marketing language instead of description. DC 200 says a description is not fairly presented if it contains statements that cannot be objectively evaluated, which is the standard's polite phrase for advertising puffery. Cut "best-in-class" and "military-grade." Describe what the system does.
- Vague or unenforceable CUECs. "Customers are responsible for security" is not a CUEC. "Customers are responsible for notifying us within one business day when a user's access should be revoked" is. If a CUEC cannot be evaluated, it will draw a comment.
- Missing principal service commitments. Descriptions written before 2018 habits faded often skip DC 2 detail. If your SLA promises 99.9 percent uptime, that commitment belongs in the description.
- CSOC and CUEC mixed up. Controls at your cloud provider are CSOCs. Controls at your customer are CUECs. Swapping them is a frequent and avoidable error.
- Over-disclosure that creates risk. DC 200 cautions against describing controls at a level of detail that could help a hostile party exploit a vulnerability. Describe the nature of controls, not an attacker's roadmap.
- DC 9 changes buried or omitted. Mid-period changes to hosting, key subservice providers, or core system components need to be called out with dates, not glossed over.
A DC 200 system description drafting checklist
Use this as a final pass before you hand the description to your auditor.
- DC 1: Services and system context are described concretely.
- DC 2: Principal service commitments and system requirements are stated and tied to real SLAs and policies.
- DC 3: All five components (infrastructure, software, people, procedures, data) are covered, ideally with a data flow diagram.
- DC 4: Significant incidents during the period are disclosed, or their absence is stated.
- DC 5: In-scope trust services categories and the controls that meet commitments are presented.
- DC 6: CUECs are specific, testable, and cover each in-scope category.
- DC 7: Subservice organizations are disclosed with the inclusive or carve-out method, and CSOCs are listed for carve-outs.
- DC 8: Any non-relevant criteria are named with reasons.
- DC 9 (Type 2): Significant changes during the period are documented with dates.
- No puffery, no over-disclosure, no CUEC/CSOC mix-ups.
Frequently asked questions
Is the system description the same as Section 3 of a SOC 2 report?
Yes. The system description is presented as Section 3 of a SOC 2 report and is typically the longest section, since it can include narratives, control matrices, and diagrams.
Who writes the SOC 2 system description?
Service organization management writes it. The service auditor evaluates whether it is presented in accordance with DC 200 but does not author it.
How many description criteria are in DC 200?
Nine (DC 1 through DC 9). A Type 2 description addresses all nine; a Type 1 description addresses eight, because DC 9 (significant changes) applies only to a period of time.
Did the 2022 update change the description criteria?
No. The 2022 revision updated the implementation guidance only. The nine criteria themselves were unchanged from the 2018 version.
What is the difference between a CUEC and a CSOC?
A CUEC is a control you assume your customer performs. A CSOC is a control you assume your subservice organization performs. Both are needed, in combination with your own controls, to achieve your service commitments and system requirements.
Does DC 200 require a specific format?
No. DC 200 does not prescribe a format. The description is generally narrative but can be supplemented with flowcharts, tables, matrices, and diagrams.
What does a SOC 2 system description look like?
It is a narrative organized around the DC 200 criteria: a services overview, service commitments and system requirements, the five system components, any significant incidents, the trust services criteria and controls, complementary user entity controls, subservice organizations, and (for a Type 2 report) significant changes during the period. See the worked Northwind Analytics excerpt above for an illustrative example of each block.
This guide reflects the AICPA's 2018 Description Criteria (DC Section 200) with revised implementation guidance from 2022, used with the 2017 trust services criteria in TSP Section 100. It is educational and does not constitute an audit opinion or engagement advice.