A Quick-Start Guide of the SOC 2 System Description

The 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.
Richard Stevenson

by Richard Stevenson

March 10, 2023
SOC 2 System Description

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. 

This includes:

  • 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. 

Getting Started

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.

Trusted Newsletter
Resources for you
pci-roc-hero

What Is a PCI ROC + When Do You Need One?

SOC 2 Compliance Checklist hero image

SOC 2 Compliance Checklist: 9 Key Steps To Take

PCI Audits hero

PCI DSS Audit: What It Is + How to Prepare

Richard Stevenson
Richard Stevenson
Richard Stevenson is Manager of Compliance Advisory Services at Drata. He advises customers on building sound cybersecurity risk management programs and security policies that meet security compliance requirements. Richard is an AWS Certified Cloud Practitioner, CompTIA CySA+, and Shared Assessment Certified Third-Party Risk Assessor specializing in SOC 2, ISO 27001, NIST 800-53, NIST 800-171, SOX, HIPAA, third-party risk management, and enterprise risk management.

Put Compliance on Autopilot

Close more sales and build trust faster while eliminating hundreds of hours of manual work to maintain compliance.

Related Resources
SOC 2 Compliance Checklist hero image

SOC 2 Compliance Checklist: 9 Key Steps To Take

SOC 2 Type 1 vs Type 2 hero

SOC 2 Type 1 vs. Type 2: How They Differ

SOC 2 Report Example hero

What Is a SOC 2 Report? [+ Example]

SOC 2 Audit Hero Image

SOC 2 Audits: What You Can Expect From Start to Finish