Short answer: The SOC 2 system description is the part of your report, usually section 3, where management explains the service being examined: what it does, the commitments made to customers, the systems, people, data and processes behind it, and how controls are organized. It must be accurate and complete, because the auditor gives an opinion on whether it is fairly presented.
First-time SOC 2 teams are often surprised by how much of the report is their own writing. The auditor tests controls and writes the opinion, but the description is management’s document. It sets the stage for everything else and it is the part customers read when they want to know how you really operate.
A weak description can lead to a qualified opinion even when controls work, because the auditor must conclude it is fairly presented. A strong one makes fieldwork smoother and builds customer trust. This guide covers what goes in it, how to structure it and what to avoid.
What is a SOC 2 system description?
It is a narrative, written by your management, that describes your system for the period or date covered by the report. The AICPA publishes the criteria it is judged against, called the description criteria (DC section 200). Auditors compare your text with those criteria and with what they observe during testing.
Two things follow from that. First, the description is management’s responsibility, even when a consultant drafts it. Second, it must match reality. If you describe an access review that does not happen, the problem is not wording, it is a misstatement.
What to include
| Part | What it covers |
|---|---|
| Company and service overview | What the company does and which service or product is in the report, in plain language. |
| Service commitments and system requirements | The promises you make to customers (security, uptime, confidentiality) and the internal requirements that support them. |
| System components | Infrastructure, software, people, data and procedures that make up the system. |
| Boundaries | What is inside the system and what is excluded, with the reason. |
| Control environment and related areas | How governance, risk assessment, communication, monitoring and control activities work at the company. |
| Trust Services Categories | Which categories are in scope, and any criteria that do not apply with an explanation. |
| Subservice organizations | Providers you rely on, how they are treated (carve-out or inclusive) and complementary controls expected from them. |
| Complementary user entity controls | Controls customers are expected to run for your controls to work. |
| Changes and incidents | Significant changes to the system during the period and, where applicable, significant security incidents. |
Your scope decisions feed directly into this section. If you have not yet drawn the boundary, start with how to define SOC 2 scope. For provider treatment, see carve-out vs inclusive method.
How to write it, step by step
- Gather source material. Collect architecture diagrams, data flow diagrams, policies, org charts, vendor lists, contracts and your security page. These hold most of what you need.
- Write the service overview first. One or two paragraphs that a non-technical reader can follow.
- State commitments and requirements. List the customer commitments with their source, such as the master agreement or SLA, and the internal requirements that support them.
- Describe each component. Use the five components as headings. Keep each subsection specific: name the cloud platform, the identity provider, the monitoring tools and the roles involved.
- Explain how controls fit together. Describe governance, risk assessment, communication and monitoring in terms of what you actually do, not what a template says.
- Add providers, CUECs and exclusions. Be explicit about dependencies and customer responsibilities.
- Review with control owners. Ask each owner to read their part and mark anything that is wrong or out of date.
- Agree it with your auditor. They will give feedback on completeness and wording before fieldwork.
A sample outline you can reuse
1. Overview of services. What the company does and what the in-scope service delivers.
2. Principal service commitments and system requirements.
3. System components. 3.1 Infrastructure. 3.2 Software. 3.3 People. 3.4 Data. 3.5 Processes and procedures.
4. Control environment and supporting processes. Governance, risk assessment, information and communication, monitoring.
5. Criteria and categories. In-scope categories and criteria not applicable.
6. Subservice organizations. Providers and complementary controls.
7. Complementary user entity controls.
8. Changes to the system and incidents during the period.
An example of the right level of detail
Instead of writing “access is controlled appropriately”, a good description says something closer to this: “Production access is granted through the company identity provider based on role. Requests are approved by the system owner in the ticketing system. Multi-factor authentication is required. Access reviews are performed quarterly by engineering managers, and access for departing employees is removed within one business day of termination.” That is specific, testable and checkable against evidence.
Common mistakes
- Marketing language. Claims such as “military-grade security” have no place. Describe what you do and how.
- Template text that does not match your environment. Auditors spot descriptions copied from another company.
- Describing controls you do not run. This is a misstatement and the usual way a clean report turns into a modified one.
- Not updating after changes. A cloud migration, a new identity provider or a new in-scope product must be reflected.
- Too thin or too long. Too thin leaves out things the criteria require. Too long hides the important points and creates more statements to be tested.
- Leaving it to the consultant alone. Management is accountable for accuracy, so owners need to read their sections.
- Forgetting CUECs. Missing customer responsibilities weaken the report’s value for readers.
How the description connects to the rest of the report
The description sets what the auditor tests. Section 4, which lists controls and test results, assumes that the description is accurate. When customers read your report they use the description to understand how things work and the test results to decide whether they do. For a reviewer’s view of that process, see how to read a SOC 2 report. If an exception arises from a mismatch between description and practice, the effect can be serious, which is covered in what happens if you get a qualified SOC 2 opinion.
Practical recommendations
- Write for a security reviewer who does not know your product.
- Use consistent names for systems and teams throughout.
- Link each described control to the policy and evidence that supports it. Our list of documentation required for a SOC 2 audit can help.
- Keep a changelog of system changes during the period so the description can be updated quickly.
- Run a mock review before fieldwork. A gap analysis is a good time to test that the description matches practice.
If you would like a second pair of eyes, SOC2.in’s SOC 2 readiness service includes drafting and review support, and the SOC 2 glossary explains the terms you will meet.
A pre-submission review checklist for your system description
Before the auditor sees your draft, test it yourself. The description is management’s statement, so every sentence should be something you can support. Description criteria are published by the AICPA alongside the Trust Services Criteria, so ask your auditor which version they apply.
- Services: does it describe what customers actually buy, in language a customer’s security team would recognize?
- Infrastructure and software: are the main platforms, environments and tools listed, matching what engineers would say?
- People: are the teams that operate and secure the system named by function?
- Data: are the types of data handled and how they flow described accurately?
- Procedures: do the control descriptions reflect real practice rather than policy aspiration?
- Boundaries: are exclusions and subservice organizations stated clearly?
- Complementary user entity controls: do they tell customers exactly what they must do?
- Changes: does it cover significant changes during the period?
Have someone outside the project read it
An engineer who did not write the description should be able to confirm each technical claim, and a customer-facing teammate should be able to confirm that the service is described fairly. If either hesitates, rewrite that passage. Overstated descriptions create exceptions, and vague ones frustrate readers. For related reading, see how to define SOC 2 scope and system boundaries.
Frequently asked questions
What is a SOC 2 system description?
It is management’s written explanation of the system being examined, including services, commitments, components, boundaries, providers and customer responsibilities.
Who writes the SOC 2 system description?
Management is responsible for it. Consultants or auditors may advise, but management must confirm that it is accurate and complete.
Which section of a SOC 2 report is the system description?
It is typically section 3, though numbering can vary between audit firms.
What are the SOC 2 description criteria?
They are the AICPA criteria in DC section 200 that the system description is evaluated against, covering matters such as services, components, controls and incidents.
How long should a SOC 2 system description be?
Long enough to cover each required element accurately and short enough to stay readable. For a small company it is often 10 to 20 pages.
Can the system description cause a qualified opinion?
Yes. If the auditor concludes the description is not fairly presented, for example because it describes controls that did not operate, the opinion can be qualified.
Conclusion
The system description is your chance to explain your service in your own words, and your responsibility to get it right. Gather real source material, write specifically, include every required element, review it with the people who run the controls and update it whenever the system changes. A clear, honest description makes the whole report stronger.
