What the SOC 2 system description must say and who writes it
Management writes the system description, and it is prepared against the AICPA's 2018 SOC 2 description criteria, known as DC 200. The CPA firm does not write it. The CPA then gives an opinion on whether that description is fairly presented, alongside its opinions on the controls. For a customer or bank that has asked for a SOC 2, this description is usually the first section the reader reviews, so the organization owns its accuracy and must be able to defend every statement in it.
The right level of detail depends on what is in scope. The description must cover the services provided, the principal service commitments and system requirements, the system components, significant incidents, the criteria that apply and the related controls. It must also name the third parties that the system relies on, the complementary user entity controls that customers must operate, and any criteria that do not apply. DC 200 does not prescribe a format, so the test is whether a reader can tell what the system does, where its boundaries lie and what the customer is responsible for. Confirm with the CPA firm early whether its expected level of detail matches your draft, because the description is reviewed before testing begins.
Divide the work clearly. The organization owns the description, the commitments, the component inventory and the controls it describes. An implementation partner such as DeployOpen can help assemble the supporting facts, including infrastructure inventories, configuration baselines and evidence sources for self-hosted platforms. Only the independent CPA firm can issue the report and its opinions. Ask any partner to confirm in writing which parts of the description it drafted, which parts management verified, and that the CPA firm has not been asked to prepare the description it will later test.
Which nine DC 200 criteria management must address
The 2018 description criteria (DC 200) list nine things management must disclose about the system under examination. Read together, they answer one question for a reader: what is being examined, what it depends on, and where the boundary of responsibility sits.
Types of services provided
DC1 asks management to describe the services the system delivers to customers, in terms a customer's assessor can match to the services they buy. For a SaaS product, this means naming the product modules, deployment models and customer types in scope. Check that the description matches what sales and the contract actually promise, because a mismatch here undermines every later section.
Commitments and system requirements
DC2 covers the principal service commitments made to customers and the system requirements that support them, such as uptime, data handling and support response. Each commitment should trace to a control the auditor can test. Confirm that commitments in master service agreements and trust pages are the same ones in the description.
System components
DC3 requires the boundaries of the system described through its infrastructure, software, people, procedures and data. For a self-hosted platform, this includes clusters, identity providers, databases, backup targets and admin consoles. An inventory that lists every component in scope, with its owner, is the fastest way to show the auditor where the boundary lies.
Significant system incidents
DC4 asks management to disclose significant security incidents and system failures that affected service commitments during the period, and how they were resolved. Auditors read this against the incident response and change records. Disclosing incidents plainly is expected, while omitting them tends to surface later in testing.
Applicable criteria and related controls
DC5 links each selected trust services criterion to the controls that address it. This is where the control matrix and the description meet, so the mapping must be complete for each category in scope. Verify that every common criterion maps to at least one control and that each control names a real owner and evidence source.
Complementary user entity controls
DC6 requires the description to state the controls customers must run on their side for the service controls to work, such as managing their own user accounts or reviewing their own access logs. These are shown as CUECs. Keep the list short, specific and tied to the actual dependency, since vague customer duties are hard for an assessor to accept.
Subservice organizations and their controls
DC7 covers third parties that perform part of the service, such as a cloud provider or colocation facility, and whether they are carved out or included. Where the controls of those parties are relied on, DC7 also calls for the complementary subservice organization controls. Collect current SOC reports or equivalent assurance from each subservice organization so these statements can be checked.
Criteria not relevant to the system
DC8 asks management to identify any applicable criteria the service does not need, and explain why. Exclusions must be justified from the system design, not from convenience. A privacy or processing integrity criterion that is excluded should have a short, defensible reason that an assessor can test against the architecture.
Significant changes during the period
DC9 requires disclosure of significant changes to the system during the examination period, such as new hosting regions, a platform migration or a change of identity provider. For a Type 2 report, this is where a reader learns whether the described system matches the one tested across the whole period. Keep a dated change log so this section can be written from records, not memory.
How to describe infrastructure, software, people, data and procedures
Infrastructure is the physical and virtual foundation the system runs on: compute, storage, networks, identity providers, logging pipelines and the boundary where the system meets the internet. A reader judging control design needs enough naming to see where access is enforced and where monitoring happens. A description that says the platform runs on cloud servers gives an assessor nothing to test. A description that names the account structure, the regions, the network segments and the admin entry points does.
- Named environments: Identify production, staging and management environments and state which ones hold customer data.
- Network boundaries: Describe ingress points, load balancers, firewalls and any bastion or VPN path used for administration.
- Hosting model: State whether the platform runs on a public cloud, a private data center or a hybrid setup, and name the provider where that matters for controls.
- Logging and monitoring infrastructure: Name where logs are collected and retained, since CC7 criteria depend on it.
- Illustrative example: A line such as "production runs in two availability zones of one cloud region, administered through a bastion host with MFA" tells a reader far more than "cloud hosting."
Check that every infrastructure item named in the description also appears in the system inventory and the control matrix.
Software covers the applications, services, libraries, operating systems and tooling that make up the system, including the versions that run in production. Open-source components matter here because the description should show what the organization runs, not only what it wrote. A reader needs component names, versions where they affect risk, and the owner of each piece. Without this, change management and vulnerability management criteria cannot be assessed against a concrete system.
- Application inventory: List the customer-facing application, back-office services and any self-hosted open-source platforms, with their purpose.
- Version and patch approach: Describe how versions are tracked and how updates are applied, without stating a cadence unless the organization actually follows one.
- Third-party and open-source components: Identify significant dependencies and how their vulnerabilities are monitored.
- Management and orchestration tooling: Name the deployment, configuration and secrets tools that touch production.
- Self-hosted platforms: When an open-source platform runs in a client's cloud account and the client administers it, state that boundary explicitly so the reader knows which software controls belong to the service organization.
Confirm that version information in the description matches the version the auditor samples during fieldwork.
The people component describes who operates, supports and governs the system and what each group can do. The description should name functions and responsibilities rather than individuals, and show how access is granted to staff. Readers use this section to judge segregation of duties, privileged access and whether the people who build changes are different from those who approve them. Vague statements such as "our engineers manage security" do not show who holds production rights.
- Functional teams: Name teams such as platform engineering, security, support and customer success, with their roles in the system.
- Privileged roles: Identify which roles can reach production data or administrative consoles and how those roles are assigned.
- Support and escalation paths: Explain who handles customer requests and incidents and how they reach the engineering team.
- Contractors and outsourced staff: State whether any operators are contractors or managed service staff, since they affect access controls.
- Illustrative example: "Two platform engineers hold production administrator rights, granted through a ticketed request approved by the security lead" gives an assessor something to sample.
Confirm the role list against the access review population before the description is finalized.
Procedures are the documented and practiced ways the organization runs the system: how changes are made, how incidents are handled, how access is requested and removed, how backups are restored and how vendors are assessed. A reader needs to see which procedures exist and which controls operate within them. The description does not need to reproduce the procedures themselves, but it must show how they connect to the trust services criteria in scope and where they are written down.
- Core processes: List change management, access provisioning and deprovisioning, incident response, backup and recovery, and vendor review.
- Ownership and documentation: Name the document or system of record for each procedure and its owner.
- Triggers and approvals: Explain what starts each procedure and who signs off, which is what the auditor tests.
- Exceptions handling: Describe how emergency changes or deviations are recorded.
- Illustrative example: "Production deployments require a pull request approved by a second engineer and a passing pipeline, recorded in the ticketing system" identifies a control a reader can test.
Check that every procedure named here is in effect for the whole observation period in a Type 2 report, not only on the day the description was written.
The data component describes the information the system stores, processes and transmits, where it lives and how it moves. Readers judge confidentiality, availability and privacy controls against this section, so it needs the categories of data, the locations, the flows between components and the retention and disposal rules. A description that says "customer data is encrypted" leaves open which data, where, and with which keys. Naming data classes and flows is what lets an assessor follow a record from intake to deletion.
- Data categories: Describe the types of customer and operational data the system handles, at a level that matches the commitments made to customers.
- Storage locations: Name the databases, object stores, backups and log stores, and the regions they run in.
- Data flows: Show how data enters, moves between components and leaves the system, including integrations with third parties.
- Retention and disposal: State how long each category is kept and how deletion is performed, which feeds C1 and P criteria where in scope.
- Self-hosted deployments: When the client holds the data in its own account, describe which copies the service organization can reach and which remain fully under the client's control.
Confirm that the data flows match the architecture diagram and the data inventory the team maintains.
How the CPA decides whether the description is fairly presented
In both a Type 1 and a Type 2 report, the CPA gives an opinion on whether management's description of the system is fairly presented, alongside the opinions on the controls themselves. The CPA is not checking that the description is long or polished. The CPA is checking that it describes the system as it was designed (Type 1) or as it operated over the period (Type 2), that it includes the significant incidents and changes the DC 200 criteria call for, and that it does not leave out exclusions or limitations that would mislead a reader who relies on the report. A description that is accurate on every line but silent about a material carve-out can still fail this test.
Because the CPA tests the description against what it sees in fieldwork, every claim in the description has to be supportable. If the description says access reviews run quarterly, shows a named production database, or states that backups are restored and tested, the CPA will ask for the review record, the system inventory, or the restore log, and will sample it. Before fieldwork, walk through each statement with the control owner and ask which artifact proves it. Statements that cannot be evidenced should be corrected in the draft, not defended in the walkthrough. Management should also confirm that the list of incidents and significant changes in the description matches the ticketing and change records, since a mismatch is often what turns a clean description into an exception.
The practical decision is how precisely to describe scope and exclusions. Name the subservice organizations, state whether each is carved out or included, and list the complementary user entity and subservice controls that the reader must rely on. Confirm with the CPA firm early whether its view of fair presentation matches yours, because the wording and level of detail are judgments made with the auditor. Agree the draft description before the observation period or Type 1 date, and record any changes to it during the period so that the Type 2 description reflects what actually happened.
How to draft the description before the auditor asks
This sequence turns the DC 200 system description from an open-ended narrative into a drafted, evidence-checked document that management agrees to before the assertion is signed. Each phase produces a defined output that the next phase depends on.
Confirm scope with the CPA firm
Management agrees with the CPA firm which system, services, locations and trust services categories the examination will cover, and whether subservice organizations are included or carved out. Management writes these choices down, and the CPA firm confirms or corrects them in writing. The output is a scope statement that defines the boundary every later section of the description must match. Ask the CPA firm to confirm the scope in writing before any drafting starts, so later rework does not change the boundary.
Inventory systems and third parties
Engineering, operations and security leads list the infrastructure, applications, data stores, network components, people and procedures inside the scope, along with every third party that handles data or runs part of the service. Each entry records an owner and where it sits. The output is a system inventory and a subservice organization register that show what the description must name. Confirm that the inventory matches what is actually running in production, not only what the architecture diagram shows.
Draft each DC 200 section
The description is written against the nine DC 200 criteria, covering the types of services, principal service commitments and system requirements, system components, significant incidents, applicable criteria and related controls, complementary user entity controls, subservice organizations, criteria not relevant to the system, and significant changes during the period. DC 200 does not prescribe a format, so the team chooses a structure and uses the AICPA's illustrative system description as a reference. The output is a complete first draft in which each DC 200 criterion has a visible section or a stated reason for omission.
Map each stated control to a criterion
Each control named in the description is traced to the Trust Services Criteria it addresses, using the criterion IDs such as CC6.1 or A1.2. Controls with no criterion are either removed or justified, and criteria with no supporting control are flagged as gaps to resolve before fieldwork. The output is a control-to-criteria map that links the description, the control matrix and the in-scope categories. Points of focus are used to test whether a control design is complete, not as a checklist that every control must satisfy.
Validate the draft against evidence
Each factual statement in the draft is checked against an artifact: a configuration export, an access review record, a change ticket, a network diagram or a policy with an approval date. Statements that cannot be supported are rewritten to match what the organization can show, or the underlying control is fixed first. The output is an evidence reference table for the description, so the CPA firm can trace claims to records during testing. Watch for statements describing controls as always operating when the evidence shows gaps or exceptions in the period.
Agree the final version with management
Management, including the leaders who own each control area, reviews the complete description line by line and confirms that each statement is accurate for the examination period. Changes raised by the CPA firm during its review are resolved and recorded. The output is a final description version with a change log, ready to be attached to the assertion. Management should not sign the assertion until this review is complete, because the CPA firm evaluates the description and management's representations against the same facts.
Complementary user entity and subservice organization controls
Complementary user entity controls and complementary subservice organization controls sit at the edge of the system description, where the service organization's controls end and other parties' responsibilities begin. Each card covers one part of how these are defined, disclosed and tested, from the customer's side of the line to the cloud provider's side.
What a CUEC is
A complementary user entity control (CUEC) is a control the service organization expects its customers to operate for the overall system to meet the criteria in scope. Typical examples include a customer reviewing its own user access lists or protecting the credentials it issues to its staff. The description must name each CUEC so that the customer knows it owns that control, because the service organization cannot run it on the customer's behalf.
Why CUECs must be owned
A CUEC that the service organization assumes is being met, but that the customer never implements, leaves a gap no one has evaluated. Management should state each CUEC in plain terms and confirm with its own contracts or onboarding material that customers receive it. Ask whether the description tells customers what to do, not only what the service organization does.
What a CSOC is and who operates it
A complementary subservice organization control (CSOC) is a control the subservice organization, such as a hosting or infrastructure provider, must perform for the service organization's controls to work. The subservice organization operates these controls, not the service organization or its customers. The description should identify each dependency so that a reader can see which controls rely on another company's report.
Inclusive versus carve-out treatment
Under the inclusive method, the cloud provider's controls are described and tested as part of the system. Under the carve-out method, the provider's controls are excluded, and the description lists the CSOCs the service organization depends on. Confirm which method applies, because it changes what the CPA tests and what customers must review separately.
How the description lists them
The description should list every CUEC and CSOC relevant to the criteria in scope, with enough detail that a reader can match each one to a control in the report. Keep the lists current with the system as it changes during the period. Ask the CPA firm and your readiness advisor to check that each listed item has a named owner and a corresponding test.
How customers use them in reviews
Customers and their auditors read the CUEC and CSOC sections to decide which controls they must run themselves and which provider reports they must request. Gaps appear when a customer's vendor review finds a CUEC with no internal owner, or a CSOC whose provider report is missing or does not cover the period. Keep the list simple and specific so that reviewers can close each item quickly.
How much detail is enough for the description
The test to apply is simple: could a customer's auditor read the description and understand what the system does, which controls apply to it, and where its boundaries sit, without the description turning into a control runbook? A description that is too thin fails the test just as surely as one that is too deep. If it names the cloud provider and the product but never says which services handle customer data, which environments are in scope, or which subservice organizations are carved out, the reader cannot tell what the controls are meant to cover. If it lists every firewall rule, IAM policy and host name, it exposes the attack surface and still leaves the reader without the big picture.
The tension is between transparency and confidentiality. The 2018 description criteria, DC 200, set out what must be disclosed but do not prescribe a format, so the right depth depends on who will read the report. A description written for a bank's third-party risk team can name the main components, data flows, hosting regions and key roles in more detail than one written for a small customer that only needs assurance about access control. Security-sensitive configuration, such as specific network segmentation values, detection thresholds or secret storage paths, usually belongs in the controls and evidence the auditor samples, not in the narrative. Describe the mechanism at the level of a control objective, and keep the operational values out of the text.
Confirm the acceptable level of detail with the CPA firm early, before the description is drafted in full. Ask the firm to review an outline or a draft of the system components, boundary and CUEC sections, and to tell you which items it expects to see named and which it will test without publishing. Also ask how it will handle redaction if a customer requests a copy. Make this a written decision, because changing the description late in fieldwork tends to delay the report. The AICPA's illustrative SOC 2 system description, linked from this page, is a useful reference point for the structure and the level of narrative an auditor will expect.
Questions about writing a SOC 2 system description
Who is responsible for writing the SOC 2 system description?
Management of the service organization writes the system description, not the CPA firm. The description is management's own statement of how the system works, and management is also responsible for its accuracy and completeness. The CPA firm then evaluates whether the description is fairly presented under the 2018 description criteria, DC 200, and reports on that judgment. In practice, the people who run the system (engineering, operations, security and compliance leads) supply the facts, and a senior owner signs off. Confirm with your CPA firm which drafts and review cycles it expects before fieldwork begins, because the description and the control matrix need to agree.
Can a consultant draft the SOC 2 system description for us?
Yes, a consultant can help draft it, but the organization must own the content and approve it. A consultant can organize the facts into the structure DC 200 expects, check wording against the criteria and point out gaps. The consultant cannot make the description accurate on your behalf, because only your staff know your architecture, data flows and changes. If the consultant also works for the CPA firm that will issue the report, confirm that the arrangement respects the firm's independence rules, since the AICPA's guidance on preparing and attesting to the same material is a point to check. Ask the CPA firm whether it will accept a consultant-drafted description and what review it expects.
How long does it take to write the system description?
The time depends on how many services, components, locations and subservice organizations the description must cover, and on how well documented your architecture already is. Teams with current network diagrams, asset inventories and service catalogs usually need less time than teams that must reconstruct how their platform works. Drafting is also iterative, because the CPA firm and internal reviewers will challenge wording that is vague or inconsistent with the controls. Ask your CPA firm for its expected review rounds and deadlines, and plan the drafting alongside readiness work rather than after it. No fixed duration applies to every organization.
Does the system description need updates for changes made during the period?
Yes, for a Type 2 report, DC9 asks management to describe significant changes to the system during the period under review, and the description must reflect the system as it operated over that period. Changes such as a new hosting region, a replaced identity provider or a new subservice organization can all be significant, depending on their effect on controls and commitments. Keep a dated log of changes from the start of the observation window so you can judge significance when drafting. Confirm the threshold for significance with your CPA firm, since it applies judgment to your facts.
Can a self-hosted tool be excluded from the system description?
A tool can be left out only if it is not part of the system in scope, and that decision must be justified and documented. If a self-hosted platform stores or processes customer data, supports a service commitment or produces evidence for a control, it is normally part of the system and belongs in the description. Excluding it can also hide a subservice organization or a component that customers rely on. Document the boundary decision, the reason for it and how the tool's data flows are isolated, and confirm the approach with your CPA firm before you finalize the scope.
How do complementary user entity controls appear in the report?
Complementary user entity controls (CUECs) are controls that the service organization expects its customers to operate on their side, and they appear in the system description and in the report so that customers know what they must do. Typical examples include a customer reviewing its own user access or configuring its integrations securely. Management lists them, and the CPA firm does not test them as part of the service organization's controls. Keep the list short, specific and tied to real customer actions, and review it with customers when they ask. Confirm the wording and placement with your CPA firm, because the report's structure determines where they are presented.
What should we bring to the CPA firm when we start drafting?
Bring the facts that let the CPA firm test the description against DC 200 and your controls. That means a current architecture and data-flow diagram, a list of services and components in scope, principal service commitments and system requirements, a subservice organization inventory with their SOC reports, the list of applicable criteria with reasons for any exclusions, and a change log for the period. Also bring the draft description, the control matrix and any known significant incidents. Ask the firm for its own request list and confirm which items it wants in a draft before fieldwork starts.
Gaps that make the description fail review
A system description fails review less often because of missing sections than because it drifts from the environment it describes. The cards below cover the gaps we see most often, and each one names a check that a management team can run before the CPA firm starts fieldwork.
Description that does not match the architecture
The description names a logging pipeline, a region or an identity provider that the production environment no longer uses, or leaves out a component that was added mid-period. Auditors compare the description against architecture diagrams, infrastructure as code and asset inventories, so any mismatch becomes a question about the whole report. Before fieldwork, walk the diagram against a live account listing and have an engineer sign off each component by name.
Omitted subservice organizations
Cloud hosts, payment processors, email providers and managed databases often process customer data without appearing in the description. The description needs to say which subservice organizations are relevant, what each does, and whether they are included or carved out. Confirm each vendor against the production data flow, not the procurement list, and check that each carve-out has a matching complementary subservice organization control.
Missing significant incidents and changes
A description that claims a clean period while support tickets or the incident log show outages, failed restores or emergency changes invites a serious exception. Management needs to disclose significant system incidents and significant changes that occurred during the period. Before fieldwork, reconcile the incident tracker, the change log and the status page history against the period dates.
Service commitments with no matching controls
Statements such as a stated uptime target, a recovery objective or a data retention promise appear in the description, but no control in the matrix tests them. Each principal service commitment should trace to a system requirement and then to a control that operates against it. Check every commitment in the customer contract and confirm that a named control and a repeatable piece of evidence back it.
Unsupported claims about tooling
Descriptions often name a scanner, a SIEM, an access review tool or an encryption method that is only partly deployed, licensed for a subset of systems, or configured differently from the text. Every named tool becomes a claim the auditor must test. Ask the control owner to show the tool running in the in-scope environment, with settings and coverage reports, before the wording is finalized.
Complementary user entity controls no customer can meet
Listing complementary user entity controls that assume customers will run multi-factor authentication, quarterly access reviews or their own vendor reviews is only useful if those customers can realistically perform them. Controls that depend on features the product does not expose, or on roles customers do not hold, will be questioned. Test each one with a representative customer administrator and document how that customer would perform it.
What DeployOpen can prepare for the description
An implementation partner can prepare the factual material that management uses to write its system description, but the organization owns the description and approves every statement in it. For a self-hosted open-source platform running in the client's own cloud accounts, data center or air-gapped network, that work usually starts with a documented architecture: the components that make up the system, where each one runs, how data flows between them, which accounts and network segments hold production data, and which third parties or subservice organizations supply hosting, identity or backup services. Those facts map directly to the components and boundaries that the description has to disclose, so a complete architecture document is often the single most useful input management can receive before drafting begins.
Beyond the architecture, the partner can assemble supporting evidence and a draft control mapping. Typical outputs include a register of the controls implemented in the platform, the configuration baselines and access model behind them, the change and deployment path, and a list of the evidence each control produces, such as exported access reviews, logging configuration or backup test records. Draft inputs for the description can follow from these, covering the principal service commitments, the system requirements, significant incidents and changes during the period, and the complementary user entity controls the customer must operate. Management should check every draft against how the system actually runs, confirm which subservice organization carve-outs apply, and record which criteria are not relevant to the system with reasons.
Two boundaries should be settled before any work begins. The engagement is a preparation service: DeployOpen does not issue a SOC 2 report, opinion or attestation, and the independent CPA firm alone decides whether management's description is fairly presented and whether the controls meet the criteria. Outcomes are not guaranteed, because the auditor's judgment and the operating history of the controls decide the result. Ask any partner to put the deliverables, the boundary between their work and management's, and the review steps in writing, and confirm with the chosen CPA firm in advance which description format and level of detail it expects.
How DeployOpen prepares system documentation for a SOC 2 examination
DeployOpen helps teams running self-hosted open-source platforms put the system description in writing before the examination starts. We work from the systems that actually run in the client's own infrastructure, and the organization keeps ownership of management's description and assertion, while an independent CPA firm performs the examination and issues the report.
How we scope
- We confirm the services, system components and locations the description must cover before work starts.
- Scope, deliverables and timelines are agreed in a written, fixed-scope statement of work.
- We list which trust services categories are included and which are excluded, with the reason for each.
How we build
- We map the infrastructure, applications, data flows and third parties into a system description draft.
- We document complementary user entity controls and subservice organization controls the client must confirm with its CPA firm.
- We record significant changes and incidents from the period so management can review them against the draft.
How we hand over
- We deliver the system description draft, supporting diagrams and an inventory of the source records behind each statement.
- We walk the client's control owners through each section so they can confirm accuracy and correct any gaps.
- We hand over editable files so management can maintain the description after the examination ends.
How we support
- Ongoing support and updates to the description are available as a retainer, scoped in writing.
- We can update the description when systems, subservice organizations or controls change during an observation period.
- Questions about what the CPA firm expects in the description should be raised with that firm directly, since the report is theirs to issue.
