Let’s Talk SOC 2 System Descriptions—What They Are and How to Write Them

Not sure what to include in your company’s SOC 2 report system description? You’re not alone. Some of the most common questions we get from our clients are related to the system description—specifically what it is and how to put one together that accurately outlines the boundaries of your SOC report. Let’s dive in.

What is a system description?

The system description, part of Section III within a SOC 2 report, includes important information regarding the people, processes, and technology that support your product or service.

As the auditor, BARR’s team is charged with confirming you are fulfilling the trust services criteria applicable to your report scope. The system description sets the stage for how your auditor will identify any gaps in the control environment and determine if the controls in place were “suitably designed and operating effectively in order to achieve commitments and system requirements based on the applicable trust services criteria.” The five potential trust services criteria include security, availability, confidentiality, processing integrity, and privacy. A SOC report always includes security as one of the trust services criteria, but could also include one, two, or any mix of the others.

Who writes the system description?

Companies write their own system descriptions, largely led by their management team. Gathering these details can be challenging for some companies, but the good news is the auditor (e.g., BARR) is your partner throughout the entire process, working with you along the way to identify missing elements. 

What is the purpose of the system description?

The system description serves as a summary of your company and its system(s). A good way to think about this is it helps any reader understand the internal controls you have in place. Crafting the best possible system description will help BARR assess whether or not your system components are effectively functioning and protecting your company and customer data. The stronger your system description, the better your clients will understand the services being audited and, in turn, less questions will arise.

What information do I need to include?

The AICPA recommends including the following in your SOC 2 system description:

1. Types of services provided. Describe the services your company provides using the system. We recommend including a short company boilerplate description, along with a description of the system being audited. Avoid marketing language, keeping it straightforward and not too sales-y. 
2. Principal service commitments and system requirements. Here, you’ll detail commitments you have to customers, business partners, etc., as well as your commitment to adhere to laws and regulations. Things like service-level agreements and contracts with vendors would fit here. Detailing this provides context behind your in-scope trust services criteria.
3. Components of the system. This is where you talk about all the infrastructure, software, people, procedures, and data that support your system. Your BARR rep can help you identify what goes where and how detailed to get. 
4. Trust services criteria and corresponding controls. Start by sharing which criteria are in scope. From there, describe your control environment and the controls you have in place to support it (i.e., change management, logical access, risk assessment). This list of controls guides the BARR team as we test each of them. 
5. Complementary user entity controls. Your company’s controls were designed with the assumption that certain internal controls would be in place at customer organizations, right? Here’s where you list the controls your customers need to implement so that your system and control environment can operate securely and achieve its objectives. A few examples include the user entity’s responsibility to: protect established user IDs and passwords within their organization, remove terminated employee access, and establish endpoint protection of workstations.
6. Complementary subservice organization controls. Think about which vendors you need in order to meet criteria, customer commitments, and/or system requirements. These are the organizations performing controls on behalf of the client. This becomes your official list of subservice organizations. It may not include all third-party organizations, and that’s ok. Once identified, discuss the subservice organization controls that support your company’s system and control environment. You’re likely a cloud service provider (CSP), so be sure to list your hosting provider (i.e., AWS, Azure, GCP, etc.) and describe what criteria they help you meet.
7. System incidents. Here, you’ll share whether or not there were any security incidents during your reporting period. If there were, be sure to detail where your company failed to meet specific criteria, customer commitments, or system requirements.
8. Significant changes to the system during the period. Pretty straightforward—discuss any noteworthy changes that occurred during the reporting period, along with any effects from those changes. 

Writing a system description can feel like a daunting task, but breaking it out into these pieces can help bring it all together. And remember you have BARR as your partner along the way. 

If you’re a current client in need of assistance writing your system description, or if you’re new to BARR and looking to ask questions to learn more about the overall SOC auditing process, contact us.