DC section 200
DC 200: the yardstick for your system description.
DC section 200, the 2018 SOC 2 description criteria, is what the CPA firm measures your Section 3 against. The nine criteria are explained in our system-description guide. This page is about the other side: how an examiner uses them, and how you can check a draft the same way.
Back to SOC 2 services01 · Its role
Two criteria documents, two opinions
DC 200 judges the description; TSP 100 judges the controls.
DC 200
Is the description fair?
- Applies to Section 3 of the report
- Asks whether it presents the system as designed and implemented
- Written by the AICPA's ASEC, with implementation guidance
TSP 100
Do the controls meet the criteria?
- Applies to the controls described
- Asks about design and, in Type 2, operation
- Also from the ASEC
The SOC 2 opinion addresses both. A report can have effective controls and still be qualified because the description is not fairly presented.
02 · How it is tested
How an examiner tests a description
Read, corroborate, compare, and look for what's missing.
- Read the description against each criterion and note where each is addressed, or why it isn't relevant.
- Corroborate statements through inquiry, observation and inspection, often in walkthroughs.
- Trace components named in the description (infrastructure, software, people, procedures, data) to the real environment.
- Compare the controls described with the controls actually tested.
- Check the description stays true for the whole period in a Type 2, including disclosed changes.
- Look for omissions: incidents, vendors or complementary controls the evidence reveals but the text doesn't mention.
DC 200 does not dictate a format. Narrative, tables or a mix are all acceptable, provided each relevant criterion is addressed.
03 · Omit or distort
The omit-or-distort test, from the examiner's side
A description fails if it leaves out or misstates something that matters to users.
| Illustrative statement | Failure | A fairer version |
|---|---|---|
| “All production access requires hardware keys.” | Distortion: two service accounts use passwords | State the rule and the documented exceptions |
| No mention of a customer-data outage in month four | Omission of a relevant system incident | Disclose the incident and how it was handled |
| “Data is encrypted.” | Too vague to evaluate | Say which data, at rest and in transit, and who manages keys |
| Analytics vendor with production data not listed | Omission of a subservice organization | Name it and state carve-out or inclusive |
04 · Description and controls
How the description and the controls tie together
The description is the map the tests in Section 4 follow.
- Every control the examiner tests should appear in the description, in the same words.
- Every frequency stated (“quarterly”, “within one business day”) defines the population the examiner samples.
- Every CUEC and CSOC in the description becomes a caveat on the opinion's scope.
- A significant change disclosed in the description explains why some tests cover only part of the period.
The practical rule
If you cannot point to evidence for a sentence in your description, either produce the evidence or rewrite the sentence.
05 · The 2018 edition
What the 2018 description criteria changed
DC 200 replaced earlier guidance in the SOC 2 guide; implementation guidance was revised in 2022.
- The description criteria became a stand-alone document rather than paragraphs inside the SOC 2 guide.
- Descriptions must disclose the principal service commitments and system requirements.
- Significant system incidents during the period must be disclosed where relevant.
- Each criterion came with implementation guidance, revised in 2022 alongside the revised points of focus.
The current edition is titled “2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022)”. The criteria are the 2018 ones; the guidance around them was updated.
06 · Self-review
Self-review a draft the way an examiner will
Run each check before the CPA firm sees the draft.
| Check | Evidence to have ready | Red flag |
|---|---|---|
| Services match contracts | Customer agreements and the product site | Services sold but not described |
| Commitments are stated | SLAs, security terms, privacy notices | Commitments only in sales decks |
| Components are real | Architecture diagram, asset inventory | Tools you plan to buy |
| Incidents are covered | Incident log for the period | A known incident missing |
| Controls match tests | Control matrix | Controls described but never run |
| Vendors are named | Vendor register with data access | A data processor left out |
| CUECs are truly customer duties | Shared responsibility notes | Duties you could perform yourself |
| Changes are disclosed | Change log, org changes | A migration mid-period not mentioned |
Sources: AICPA 2018 SOC 2 Description Criteria (DC section 200), with revised implementation guidance (2022); AICPA SOC 2 guide; AICPA illustrative SOC 2 report. All statements and vendors are illustrative.
Questions about DC 200
Does every DC 200 criterion have to appear in our description?
Each one applies to the extent it is relevant.
Where a criterion doesn't apply, the description should say so and why. Silence looks like an omission.
Can the opinion be qualified because of the description alone?
Yes.
The opinion covers whether the description is fairly presented. A material omission or misstatement can modify the opinion even if every control test passes.
Do SOC 1 reports use DC 200?
No.
SOC 1 description requirements are in AT-C 320. DC 200 is specific to SOC 2.
Should our description describe controls we plan to add?
No.
The description covers the system as designed and implemented at the date or over the period. Planned work may appear only as clearly labelled other information, if at all.
Get the description right before it's tested.
We review your draft against DC 200 the way an examiner will, and flag every sentence that needs evidence.