The system description is the most important document in a SOC 2 report. It is the document that enterprise clients’ security teams read most carefully: it tells them what was actually audited, what the organization’s infrastructure looks like, what data flows through the system, who has access to it, and what commitments the organization has made to its clients. A system description that is accurate, complete, and well-written instills confidence; one that is vague, incomplete, or contains errors undermines the credibility of the entire report.
Required Elements of the System Description
| Section | Required Content | Common Error |
|---|---|---|
| Nature and purpose of the service | What the service does; who the clients are; how the service is delivered | Too brief — “we provide a SaaS platform” without describing what the platform does or who uses it |
| Principal service commitments and system requirements | The specific commitments made to clients: uptime guarantees, security commitments, data handling obligations | Vague commitments (“we take security seriously”) without specific, testable statements |
| Infrastructure components | Servers, cloud accounts, networks, data centers, and CDNs that form the system; hosting provider; geographic locations of data storage | Out-of-date infrastructure descriptions; missing cloud accounts or sub-accounts that are actually in scope |
| Software | Applications, APIs, databases, middleware, and third-party software components that process in-scope data | Missing internal tools that handle client data; failing to mention key third-party integrations |
| People | Employee roles with security-relevant responsibilities; approximate headcount; outsourced functions | Too vague (“our engineering team”) without describing relevant roles; omitting contractors with significant access |
| Procedures | Key control procedures: how access is provisioned, how changes are deployed, how incidents are handled, how vendors are assessed | Procedures described at a high level that cannot be tested; inconsistency between described procedures and actual practice evidenced in audit fieldwork |
| Data | Types of data processed, stored, and transmitted; data classification; geographic storage locations | Missing personal data processing description; data retention omitted |
| Complementary user entity controls (CUECs) | Controls the client (user entity) is expected to maintain to complement the service organization’s controls | CUECs too broad or generic; expectations that are not communicated to clients |
The Complementary User Entity Controls (CUECs)
CUECs are controls that the service organization’s clients are expected to implement to achieve the security commitments described in the system description. For example, a SaaS provider might state that it assumes clients will: manage their own user credentials, configure IP allowlisting for sensitive access, and review and respond to security notifications sent by the provider. If clients don’t implement these controls, the system as a whole may not achieve its security commitments.
| IMPORTANT | CUECs must be communicated to clients — not just listed in the SOC 2 report. If your system description says clients are expected to maintain their own access controls, but you have never communicated that expectation to clients in a contract, DPA, or trust center documentation, the CUEC is not effectively implemented. Enterprise security reviewers will ask whether CUECs are communicated; auditors will ask for evidence of that communication. |
Common Errors That Generate Qualifications
Certain errors in the system description are serious enough that auditors issue qualified opinions — meaning the auditor’s opinion notes a material discrepancy or scope limitation. The most common causes of qualified opinions related to the system description include:
Infrastructure inaccuracies: the system description describes a system that differs materially from the actual system tested. This happens when system descriptions are written during initial implementation and not updated as the infrastructure evolves. Annual review of the system description against the actual infrastructure inventory is essential.
Material omissions: the system description excludes infrastructure, software, or personnel that play a material role in achieving the service commitments. A cloud account that holds production database backups but is omitted from the system description creates a scope gap that auditors will note.
| BITLION INSIGHT | The most efficient approach to maintaining an accurate system description is to treat it as a living document, not an annual production exercise. Keep the system description in a version-controlled document management system; update it whenever significant infrastructure changes occur (new cloud accounts, new critical SaaS tools, personnel changes in key roles); and review it in full before each audit engagement kickoff. A system description that is maintained continuously takes hours to update for each audit; one that is written fresh annually takes weeks. |