The system description is one of the longest sections of a SOC 2 report, and the main one written by you rather than your auditor. Teams often treat it as a formality: a template, some architecture paragraphs, and a list of tools. Then the auditor tests it, and finds it describes a system that does not quite exist.
The description is not marketing copy and not a policy. It is management's account of the system, and the auditor's opinion covers whether that account is fairly presented. Anything it says can be tested.
This article covers what the description must contain, how the auditor evaluates it, and how to write one that remains true for the whole period.
What the description is for
A SOC 2 report usually opens with the independent service auditor's report, followed by management's assertion, then the system description. In a Type II report, a later section sets out the criteria, your controls, the auditor's tests, and the results. Some reports end with other information provided by management, which the auditor's opinion does not cover.
The description is what makes the rest readable. A buyer cannot judge whether your access controls are adequate without knowing what system they protect, who operates it, and which parts sit with someone else. The auditor's opinion says whether the description is fairly presented, along with whether the controls were suitably designed and, for Type II, operated effectively. A description that is inaccurate can lead to a modified opinion on its own, whatever your controls look like.
What the description must contain
The AICPA publishes description criteria for SOC 2, known as DC 200, with implementation guidance it revised in 2022. They require the description to cover these elements:
The types of services provided. What the system does for customers.
Principal service commitments and system requirements. What you have promised customers, and the requirements you set to meet those promises.
The components of the system. Infrastructure, software, people, procedures, and data.
Significant system incidents. Incidents that resulted from controls not being suitably designed or not operating effectively, or that otherwise caused a significant failure to meet your commitments, with their nature, timing, and extent.
The applicable trust services criteria and related controls.
Complementary user entity controls. Controls your design assumes customers will operate.
Subservice organizations. For a carve-out, the vendors whose controls your system relies on, the services they provide, and the controls you assume they operate.
Criteria that are not relevant. Any criterion in the categories you chose that is not relevant to the system, and the reason.
Significant changes during the period. For a Type II report, changes to the system that a reader should know about.
Read the DC 200 text itself before you write. The elements are short, and the implementation guidance gives examples of the level of detail expected.
How auditors test the description
The auditor reads the description against what they find in fieldwork. Three kinds of problem come up:
Describing something that does not exist. A monitoring tool named in the description that was replaced mid-period. A quarterly review that ran twice.
Leaving out something material. A second production region, a subsidiary whose engineers have production access, or a subservice organization nobody listed.
Inconsistency with the controls. The description says changes require two approvers. The control tested says one. The auditor has to resolve which is true.
Each of these is cheaper to fix in a draft than in fieldwork. Have the people who operate the system read the parts that describe their work.
How to write it so it stays true
The best descriptions are specific about what matters and quiet about what does not. Some working rules:
Describe what exists, at the level a reader needs
Write about the system as it operates during the period, not as it will look after a planned migration. Name categories of tools where the specific product is not important to the reader, such as "a centralized logging service". Name specific products where they define the boundary, such as your cloud provider. Every named tool is a fact the auditor may check, and a fact that may change.
Keep commitments consistent with your contracts
The principal service commitments section should match what your contracts, service level agreements, and public statements say. If your standard terms commit to encrypting customer data at rest, say so. If an enterprise addendum commits to something unusual for one customer, it usually does not belong in a description written for all customers. Agree that boundary with your auditor.
Disclose incidents plainly
Teams hesitate over the incidents element. If an incident meets the DC 200 threshold, it belongs in the description. Leaving it out turns an incident into a misstatement. A short, factual account of what happened and what changed reads as competence to most buyers.
Make customer and vendor responsibilities specific
Complementary user entity controls and subservice organization controls should be concrete enough that a reader can act on them. "Customers are responsible for security" is not a control. "Customers are responsible for removing access for their own users who leave" is.
Write for change
The description must be accurate for the whole period, and your system will change during it. Keep a running log of significant changes as they happen: new regions, replaced tools, reorganized teams, new subservice organizations. At the end of the period, the log becomes the significant changes element rather than something reconstructed from memory.
Common mistakes
These patterns come up repeatedly:
A template that was never rewritten. Generic text about "a mature, layered security program" tells a reader nothing and cannot be tested. Replace it with what you do.
Marketing language. Words like "industry-leading" have no place in a description. Buyers reading it are looking for facts.
Architecture detail that helps attackers more than readers. Describe components and boundaries. Leave out internal hostnames, IP ranges, and similar detail. Agree the level with your auditor.
Overclaiming the categories. A description that talks about uptime commitments when availability is not in scope invites questions. Should you include availability in your SOC 2? covers that decision.
Ownership by one person. The description is written once by whoever led the project, then nobody updates it. Assign an owner for each section, the same way you assign control owners.
A workable process
Outline from the DC 200 elements and your scope memo.
Draft each component section with its owner. Infrastructure from platform engineering, people from HR and leadership, procedures from control owners.
Reconcile against the control matrix. Every control described in the narrative should match the control your auditor will test.
Review with your auditor before the period starts, or early in it. They cannot write it for you, but they can say where it falls short.
Maintain the change log through the period.
Finalize after the period ends, adding significant changes and any incidents, then have the final version reviewed by the people who signed off on each section.
The SOC 2 framework page covers how the description fits with the other parts of the report.
How TrustLynce helps
TrustLynce's auditor portal keeps auditor requests, drafts, and findings in one place, so description review happens alongside fieldwork rather than in email. Compliance automation keeps your control matrix mapped to the criteria, which makes reconciling the narrative against tested controls a check rather than a hunt.