Every SOC 2 report contains a section called the description of the service organization's system. It is Section 3 of the report in the standard layout, and it is prepared by management, not the auditor. Your auditor's job is to evaluate whether that description is fairly presented in accordance with a specific set of standards published by the AICPA.
Those standards are called DC Section 200, formally the Description Criteria for a Description of a Service Organization's System in a SOC 2 Report. They have been in place since 2018, with revised implementation guidance issued in 2022. Most service organizations have never read them. That is a problem, because if your system description fails to meet the DC 200 criteria, your auditor will report that it is not fairly presented, which is a finding that raises immediate questions for anyone reading your report.
This post breaks down what DC 200 requires, how auditors evaluate it, and where system descriptions most commonly fail.
Why the System Description Matters
The system description is the foundation of your SOC 2 report. It tells the reader what your system does, what boundaries it operates within, what infrastructure and people support it, and what controls are in place. Customers, enterprise procurement teams, and their auditors use Section 3 to understand what they are trusting when they rely on your services.
Critically, it also sets the scope of the auditor's testing. The auditor tests the controls described in Section 3. If your description omits a system component or a control, that component or control is outside the scope of the audit. If a customer later discovers that an important system component was not in scope, it calls the value of the report into question.
The auditor is required to evaluate whether the description is fairly presented in accordance with DC 200. If it is not, they will modify their opinion accordingly. A finding that the system description does not meet the description criteria is rare, but when it occurs, it is conspicuous.
The Nine DC 200 Criteria
DC 200 requires the system description to address nine categories of information. Here is what each one requires and what auditors look for.
DC 200.A — Types of Services Provided
The description must identify the types of services you provide and explain how customers use your system. This sounds simple, but vague or overly broad descriptions of services create problems downstream. The services described must match what the auditor is actually testing.
DC 200.B — Principal Service Commitments and System Requirements
You must describe the principal service commitments you have made to customers, typically through contracts and service level agreements, and the system requirements relevant to those commitments. This is where your Trust Services Criteria selection comes in: the commitments you describe should logically map to the categories you have selected (Security, Availability, Confidentiality, Processing Integrity, Privacy).
DC 200.C — Components of the System
This criterion requires disclosure of the five system components: infrastructure, software, people, procedures, and data. Many system descriptions cover infrastructure and software adequately but give thin treatment to people (roles and responsibilities) and procedures (the actual operational processes that make controls work). Auditors now look carefully at whether the people and procedures descriptions are substantive or formulaic.
DC 200.D — System Boundaries
You must describe the boundaries of the system being reported on. What is inside scope and what is outside? Which cloud environments, applications, and processes are included? A common failure here is a scope that is described as broader than what is actually being tested. If your description says the system includes your development environment but your auditor has not tested development controls, there is an inconsistency.
DC 200.E — Applicable Trust Services Criteria
The description must indicate which Trust Services Criteria apply and include a high-level description of the controls relevant to each. This does not require listing every control individually, but it must give the reader a clear picture of how the control environment addresses each criterion. Auditors flag descriptions where the controls described do not match the evidence they observed during testing.
DC 200.F — Complementary User Entity Controls
If your service has controls that rely on the customer doing something, you must disclose those complementary user entity controls (CUECs). Examples include requirements for customers to manage their own access credentials, configure their own MFA, or review access logs you provide to them. CUECs are often underspecified. Customers then fail to implement them, which creates a gap in the overall control environment that is now appearing more frequently in enterprise security reviews.
DC 200.G — Complementary Subservice Organization Controls
If you rely on subservice organizations (AWS, Stripe, Okta, and so on) and use the carve-out method, you must identify those organizations and describe the nature of the services they provide. You must also describe what controls at the subservice organization level are necessary for your controls to be effective, and acknowledge that those controls are not included in the scope of your report. Many system descriptions list subservice organizations but fail to describe the complementary controls those organizations must implement. That omission is a DC 200 gap.
DC 200.H — Significant Changes During the Period
For SOC 2 Type 2, the description must disclose any significant changes to the system that occurred during the audit period. This includes major infrastructure migrations, acquisitions, changes to key personnel, or material modifications to controls. Omitting a significant change that the auditor identifies during fieldwork creates an internal inconsistency in the report.
DC 200.I — Incidents and Related Disclosures
The description must disclose any incidents during the period that had a material effect on the system's operation or on the organization's principal service commitments. The AICPA's implementation guidance on this criterion was revised in 2022 to clarify what constitutes a disclosure-worthy incident. A minor outage that was resolved within SLA is generally not disclosable. A significant breach, a prolonged unavailability event, or an incident that affected customers' data may be.
Common Failures in Practice
The most common DC 200 failure is a mismatch between what the system description says and what the audit evidence shows. A description that states daily log reviews are performed, when the evidence shows they are performed weekly, is an internal inconsistency. The auditor must either report that the description is not fairly presented or qualify their opinion. Neither outcome is good.
The second most common failure is an incomplete treatment of CUECs and complementary subservice organization controls. Service organizations often underinvest in these sections because they feel like legal boilerplate. They are not. Customers' auditors read them carefully to understand what controls they need to implement on their side. A CUEC that is vague or incomplete creates questions about the overall effectiveness of the control framework.
The third common failure is a system description that was accurate when the audit period opened but was not updated to reflect changes that occurred during the period. If you migrated from one cloud provider to another, changed your identity provider, or restructured your security team during the audit window, those changes need to be reflected in the description under DC 200.H.
The practical testBefore your auditor reviews your system description, ask yourself: can a knowledgeable reader understand exactly what our system does, who is responsible for what, what we depend on our customers and vendors to do, and what changed during the period? If any of those answers are unclear in the description, you have a DC 200 gap.
Writing a System Description That Passes
A system description that meets DC 200 is specific, internally consistent, and accurate as of the end of the audit period. It names roles rather than abstractly referencing "personnel." It describes actual procedures rather than policy aspirations. It identifies specific infrastructure components and their function. And it is updated before the auditor arrives to reflect any material changes during the audit window.
The AICPA's 2022 implementation guidance for DC 200 added examples and clarifications, particularly around the level of specificity required for system components and the disclosure threshold for incidents. If your system description was written before 2022 and has not been meaningfully updated, it should be reviewed against the revised guidance before your next audit.
Working with a readiness firm to review your system description before the audit is one of the most efficient investments you can make. The readiness firm will evaluate it against the DC 200 criteria before the auditor does, which means any gaps are found and fixed rather than documented in the report. A finding that the system description is not fairly presented is visible to every customer who reads your report. A revision made during readiness is not.