How long should a SOC 2 system description be?

There's no AICPA-prescribed length. Most SaaS Type II descriptions run 30 to 60 pages once you include the controls matrix in DC 5. The driver is system complexity, not page count.

Who writes the system description — management or the auditor?

Management is responsible for the description. Auditors often provide a structural outline or templates, but independence rules require management to own the content. The auditor evaluates whether the description meets DC 200.

Do we have to disclose every incident that happened during the period?

Significant incidents only. The bar is whether a reasonable report user would consider the incident relevant to assessing the service organization's controls. Public incidents and incidents that triggered regulatory notification almost always meet that bar.

What's the difference between the carve-out method and the inclusive method?

Carve-out lists the categories of controls you assume the subservice organization performs (e.g., AWS data center physical security) but doesn't bring them into the audit. Inclusive pulls those specific controls into the description and tests them directly. Carve-out is by far the more common choice.

Do Type I reports need DC 9 — significant changes during the period?

No. DC 9 only applies to Type II reports because it's about changes during a reporting period. Type I covers controls at a single point in time, so the criterion doesn't apply.

DisclosureIndependent directory. Not a CPA firm. Nothing here is legal, audit, or tax advice. Methodology.

SOC 2 system description: AICPA DC 200 outline

A structural outline of every section a SOC 2 system description must cover, mapped directly to the nine description criteria in AICPA DC Section 200.

The system description is the longest narrative section of a SOC 2 report. Management writes it; the auditor evaluates it against AICPA DC Section 200 — a set of nine description criteria covering everything from services provided to system incidents. This page lays out the structure your description has to follow.

The nine description criteria

DC Section 200 organizes the description around nine criteria. A description that's missing any one of them fails the auditor's evaluation. Here's what each one demands.

DC 1 — Types of services provided

Open with what your service does. Name the product, who uses it, and the nature of the services delivered. Focus on the services relevant to the majority of users; you don't need to enumerate edge cases.

DC 2 — Principal service commitments and system requirements

Service commitments — promises to customers, drawn from contracts, terms of service, SLAs, and privacy policies. Examples: encrypting customer data in transit and at rest, maintaining 99.9% availability, restricting access to data classified as confidential.
System requirements — the specifications the system must meet to deliver on those commitments. Examples: redundant systems for availability, MFA for privileged access, data classification rules, 24/7 monitoring.

DC 3 — Components of the system

The five components, each as a labeled subsection:

Infrastructure — hardware, servers, workstations, networks, facilities, data storage. Note system boundaries and third-party access.
Software — application programs, operating systems, mobile apps, utilities supporting the services.
People — departments, roles, responsibilities (governance, security, development, operations, customer support). Note segregation of duties.
Procedures — key policies and procedures that operationalize the service commitments and system requirements.
Data — types of data, how it flows in and out of the system, classification scheme, encryption at rest/in transit, retention and disposal.

DC 4 — System incidents

If significant incidents occurred during the reporting period (or as of the report date for a Type I), disclose them. Cover the nature of the incident, when it occurred, and how it was resolved. Materiality is a judgment call, but a published incident — security breach, prolonged outage, data integrity event — almost always belongs here.

DC 5 — Applicable trust services criteria

This is typically the longest part of the description. List the trust services criteria categories you've selected (security is mandatory; availability, processing integrity, confidentiality, and privacy are optional). Then map each criterion within those categories to the controls you've designed to meet it.

DC 6 — Complementary user entity controls (CUECs)

Controls your customers must operate themselves for your control framework to work end-to-end. Common examples: customer-side password complexity, customer-side user provisioning and deprovisioning, customer-side review of admin activity logs your service exposes.

DC 7 — Complementary subservice organization controls (CSOCs)

If you use a subservice organization (typically a cloud provider like AWS, GCP, or Azure) and elect the carve-out method, list the categories of controls you assume the subservice operates — physical security of data centers, environmental controls, hypervisor isolation, hardware lifecycle management. The inclusive method instead pulls those controls into the report and tests them directly.

DC 8 — Significant aspects of the control environment

Cover the broader control environment beyond the technical controls: governance structure, risk assessment process, monitoring activities, communication and information flows, the integrity and ethical values function (code of conduct, whistleblower process). Don't skip risk assessment — DC 200's 2022 implementation guidance specifically calls out the risk assessment process as a required disclosure.

DC 9 — Significant changes during the period (Type II only)

If the system materially changed during the reporting period — new subservice organization, major architecture change, significant new product line in scope — describe the change, when it happened, and what's different before and after. Type I reports skip this criterion because they cover a single point in time.

Structural outline

Common drafting pitfalls

Skipping CUECs — almost every SaaS has them, and forgetting them is the most common DC 200 finding. If your customers manage their own users in your product, that's a CUEC.
Generic risk assessment language — DC 200's 2022 guidance specifically asks for the risk assessment process and specific risks. Boilerplate copied across companies is a red flag.
Forgetting system incidents — if there was a public incident during the period, the auditor expects to see it disclosed.
Ambiguous system boundaries — be explicit about which products, environments (prod/staging), and integrations are in scope. Vague boundaries lead to scope disputes during fieldwork.
Subservice method ambiguity — pick carve-out or inclusive and apply it consistently. The most common choice for SaaS is carve-out for the cloud provider.