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. We don’t ever want any customer to be blindsided by this requirement, so we hope that this article and our recommendations can help to make producing this document a smooth process!
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 System Descriptions 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, such as your organizational structure, how the organization is governed, what systems you rely on to deliver your service, what controls your customers have to implement on their end, and which third parties 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.
How is the System Description Written
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. Your auditor will then take your responses and create the System Description for you to review. In either approach, when you are writing the System Description using a template or reviewing the description your auditor generated for you, it can be tempting to use subjective or “marketing/sales” type language when writing your description, 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 in the System Description Written
The System Description can realistically be written at any point before the conclusion of the audit. Oftentimes it is 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.
Can an Inaccurate System Description 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.