What Is a SOC 2 System Description and Why Getting It Wrong Kills Your Audit
The SOC 2 report has two parts that most people outside the compliance world have never read carefully: the auditor's opinion and the system description. Everyone focuses on the opinion. The system description is where first-time SOC 2 programs quietly derail themselves.
Here is what the system description is, what it needs to contain, and why inaccuracy in this document creates problems that compound throughout your audit.
What the System Description Actually Is
The system description is management's written account of the services your organization provides, the infrastructure and software that deliver those services, the people who operate them, and the controls that protect them. It is your representation of how your environment works — and your auditor will test your controls against what the system description says.
That last sentence is the critical one. If your system description says that access to production systems requires multi-factor authentication, your auditor will verify that. If the description says that change management requires peer review before deployment, that will be tested. The system description is not just documentation. It is the scope agreement for your audit.
What It Needs to Include
The AICPA's description criteria — known as the DC series — specify what a complete system description must address. At minimum, it needs to cover:
The nature of the services provided and the boundaries of the system being described. What does your product do, and where does your responsibility begin and end?
The principal service commitments and system requirements. What have you committed to customers regarding security, availability, and confidentiality?
The components of the system: infrastructure (cloud, on-premise, or hybrid), software (applications, databases, operating systems), people (roles and responsibilities), data (types and flows), and procedures (operational processes). All five components need to be addressed.
The relevant aspects of your control environment. This includes your risk assessment process, your communication practices, your monitoring activities, and the control activities that map to each Trust Services Criterion in scope.
Subservice organizations. If you rely on third-party providers to deliver parts of your service, and almost every SaaS company does, those relationships need to be disclosed and the boundaries of responsibility defined.
Where First-Timers Go Wrong
The most common mistake is writing a system description that describes the environment as it should be, not as it actually is. This happens when the description is drafted by someone removed from day-to-day operations, or when it is adapted from a template without being grounded in the company's actual architecture and processes.
An auditor testing a control that does not match what is described will issue a finding. More specifically, they will note that the description is not fairly presented — which is a qualification on the entire report, not just the affected control.
The second common mistake is omitting subservice organizations or describing their role vaguely. If your product runs on AWS and AWS has a relevant control your system depends on, that needs to be addressed. Auditors know your infrastructure. They will ask about it.
The third mistake is leaving the system description static after initial drafting. Your environment changes. New vendors are added. Architecture is modified. Team structure evolves. A system description that described your environment accurately at the start of your audit period but drifts out of alignment by the time the auditor arrives creates credibility problems.
Why Accuracy Matters More Than Completeness
A system description that honestly acknowledges limitations is more defensible than one that overstates your control environment. Auditors are not looking for perfection. They are looking for accurate representation and effective controls within the scope you defined.
If your monitoring capability is limited, say so and explain the compensating controls. If you rely on a subservice organization for a significant part of your security posture, describe that relationship clearly. Auditors who find that the description matches reality — even imperfect reality — can write a clean opinion. Auditors who find discrepancies between the description and what they observe cannot.
