A Quick-Start Guide of the SOC 2 System DescriptionThe SOC 2 system description describes the boundaries of your SOC 2 report and includes important information about the people, processes, technology, and controls that support your service or product. Here's what you need to know to get started.
The system description in a SOC 2 report is a document that we get a lot of questions about. After writing all of your policies and implementing the required controls, it can be daunting to have to provide a lengthy write-up of your organization and the system being audited.
In this article, we walk you through our recommendations to help make producing this document a smooth process.
What is the SOC 2 System Description?
Section 3 of a SOC 2 report is known as the “System Description.” This section of the report describes the system that the audit was conducted against and the boundaries of that system. It describes the people, processes, technologies, and controls that are included in the boundaries of the system.
Why Are They Required?
As part of your SOC 2 audit, your audit firm is required to issue an opinion on whether the system description is accurate, complete, and includes coverage of the defined system description criteria as defined by the attestation standards.
Additionally, the description includes information that your customers might not be aware of, but are still relevant to how your system is managed.
Your organizational structure.
How the organization is governed.
The systems you rely on to deliver your service.
The controls your customers have to implement on their end.
The third parties that may impact the security of your system.
Who Writes the System Description?
It is also important to note that you are responsible for writing the system description. Your auditor will typically provide guidance on what to include.
There are two common approaches auditors take in assisting with the description.
The first is by providing a template that contains guidance which will help you to complete each section of the system description. The second approach is to have you answer a series of questions via a questionnaire which your auditor will then use to create the system description for you to review.
In either approach, it can be tempting to use subjective or “marketing/sales” type language, but the description is meant to be an objective overview of the system that was audited. The AICPA specifically calls this out as “advertising puffery” in their SOC examination guidance. For that reason, try to avoid that type of language where possible.
When Should You Write It?
The system description can realistically be written at any point before the conclusion of the audit. Oftentimes it’s written prior to the conclusion of audit fieldwork for a SOC 2 Type 1 audit or close to the end of the monitoring period for a SOC 2 Type 2 audit.
While there is no hard time limit on when the description has to be completed, the reporting process for the audit cannot proceed without a completed system description. This is because the description has to undergo the same quality control process as the actual audit itself. Not having the system description in place prior to the conclusion of the audit may result in delays in getting your final audit report back from your auditor.
An Inaccurate System Description Can Cause a Qualified Opinion
There is a possibility that a misstated or inaccurate system description could result in a qualified opinion.
For instance, if you refused to include a description of the services a specific subservice organization (i.e. a vendor) was providing to you and your auditor felt the system description would be misleading if that subservice organization was not included in the system description, then your auditor could call out a qualification for an inaccurate system description.
Simplifying SOC 2
Becoming SOC 2 compliant is a complex, time-consuming process for most companies.
Drata can help simplify this process with dedicated support from compliance experts, continuous monitoring, real-time alerts, automated evidence collection, simple dashboards and reports, and more—everything we do is designed to take as much burden as possible off your teams.
If you’re ready to see how, book a demo with our team.