Author: Jeff Cook
When thinking of SOC 2 reports, most people think about the auditor’s opinion and the controls (in section 4). But there is another important section of a SOC 2 report, and that is the System Description (section 3). The System Description is important because, ultimately, it is what your SOC 2 report opinion is on. Wait; what? The opinion isn’t just about controls, you say? That is absolutely the case, and the system description is probably the biggest reason why it’s vital for your SOC 2. This blog post will let you know more about the SOC 2 System Description, what it is, what it should include, and some tips on how to make it easier when developing your SOC 2 report.
This blog post is going to let you know more about the SOC 2 system description, what it is, what needs to be included in it, and some tips on how to make it easier when developing your SOC 2 report.
What is the system description and why is it important?
The system description is exactly what it says. It’s a description of the system that is being reported on in your SOC 2 report. It is important because it gives your report users an overall understanding of your service and the system that is supporting it.
In your management assertion, the very first statement is, “we have prepared the accompanying description of XYZ’s __ system…”. That statement goes on to have language about the description being presented in accordance with the AICPA’s description criteria (DC 200) and what the purpose of the description is (to inform report users about useful information related to assessing the risk of using your system – including the controls). There is also an explicit statement that the controls stated in the description were suitability designed (and operating effectively – type 2) in order to achieve commitments and system requirements based on the applicable trust services criteria. So really, the controls are already in the description. Section 4 of the SOC 2 report is a means of displaying those controls, how they map to criteria, and (in type 2) the auditor’s tests of controls and results of tests.
That in turn means that the CPA’s opinion, because it is essentially an opinion on the reasonableness of management’s assertion, is really about the system description in addition to the testing of those controls for suitability and operational effectiveness. That’s why the system description is so important. A poorly written description will not meet the requirements and therefore delay your SOC 2, or worse yet, result in a qualified opinion.
OK, so what’s in the system description?
The AICPA has provided a benchmark of 9 criteria for system descriptions of SOC 2 reports. They are as follows:
- Types of services provided – this is pretty straightforward. Here you will describe what services your company provides as it relates to the system in scope. There are a couple of key things to remember for this criterion. Some companies opt to describe their entire business in general, which is acceptable, but really this criterion should mostly focus on the system under examination. Another common theme we have seen in the past is companies using their marketing language in this section to describe the system (think “XYZ corp, a world-leader in ________” or “providing the best service in the industry” and even “______ system saves customers money by…”. Think about what we discussed above. Management’s assertion is about this description, and then the CPA’s opinion is about the reasonableness of the assertion. These types of statements are not measurable and are really just “sales” language. Stick to the facts of what the system is and does.
- Principal service commitments and system requirements – as we discussed in another blog, commitments and system requirements are crucial for the entire SOC 2 report. This section lets the reader know what those commitments and system requirements are, and where they come from (SLAs, contracts, etc.). This helps give the reader context as to what trust services categories are in-scope and why.
- Components of the system – This is where the description begins to get a little technical. The components described here include the infrastructure, software, people, procedures, and data that support and make up the system. For many Cloud Service Providers (CSP), the infrastructure section will include their hosting provider (such as Amazon Web Services). The software section should list your software and applications that support service delivery1. The people section should include a high-level overview of the departments or key personnel that support the system and what they do. Procedures should also be high-level, stating what procedures are and their purpose, but we recommend leaving the details of controls for later in the description. Data should discuss what the data is that the system processes (what is your customer data), as well as any other data that directly supports the system.
- System incidents – this part of the description should discuss any security incidents that rose to the level where your company failed to either meet criteria, your commitments to customers, or your system requirements. We go into much greater detail about system incident disclosures on the ByteChek blog.
- Applicable trust services criteria and related controls – this is probably the most “bulky” criterion of the system description. In this section , you will state the criteria that are in-scope so that the reader understands the criteria you are being measured against. That part is pretty standard. After that though, is where it gets super detailed. This is where you are going to discuss your control environment and describe the controls that support it. Things like logical access, change management, risk assessment and mitigation, communication, and other information are all included here, and essentially, this is where your auditor would find and pull your controls from that get tested in section 4. We recommend that you lay this section out similar to how the criteria are set up in section 4, which makes it easy for your report users to be able to understand your control environment as it relates to the criteria. Start with the control environment, information and communication, risk assessment, etc. See the link above to read in more detail about the criteria to help you develop this part of your system description.
- Complementary user entity controls (CUECs) – a very important part of the description, CUECs are the controls that your customers need to have in place in order for the system and control environment to be complete and achieve its objectives. For example, maybe your customers need to have their own logical access controls in place so that only authorized users access your service, otherwise, unauthorized access may cause you to fail to meet your security commitments. The important thing to remember with this section is that it should not be a “laundry list” of things that you want customers to do in order for you to be covered in case something happens. That is what your contracts and agreements are for. This is purely just meant for controls they need to have in place otherwise your system doesn’t work to meet its objectives.
- Complementary subservice organization controls (CSOCs) – this criterion is where you will discuss the subservice organizations that support your system and control environment. Subservice organizations are a bit more involved than your vendors (or sometimes even critical vendors). Think of subservice organizations as a vendor that you cannot meet your criteria, commitments, or system requirements without. For most CSPs, that is going to be your cloud hosting provider (AWS, GCP, Azure, etc.). For example, you cannot meet the physical controls in CC6.4 or CC6.5 without them. So, you would list them here and what criteria they help you meet. Because you are only describing them in the system description, but not testing any of those controls (AWS isn’t letting you visit their DCs), most subservice organizations are “carved out” of the opinion in a SOC 2 report.
- Specific trust services criteria not applicable to the system – this is where you would describe any criterion that is not applicable to your system and why. An example could be where you have privacy in scope for your SOC 2, but you are not a data controller. Therefore things like the notice, choice, and consent criteria in privacy would be not applicable.
- Significant changes to the system during the period (Type 2 reports only) – in a type 2 report, if you had any significant changes (how the control environment operates, control changes in how they meet criteria, key personnel changes, mergers/acquisitions, etc.) during the period, you would state those here and their effect on the report.
System descriptions contain a lot of information, but important information for your users. That information has repercussions throughout the whole report, so making sure your description is well-done and accurate is crucial for your audit. At ByteChek, we understand that writing a system description can be a daunting task, but we can help. Our personnel are well-versed in what is needed in these descriptions, and we understand what good is. Talk to us and we’ll work through how to get the best description of your system on paper for your report users.