SOC 2 has become the de facto standard for businesses in all industries to build trust and unlock sales. Most security professionals have experienced a SOC 2 audit and understand the details of what goes into earning these coveted reports.
When companies receive SOC 2 reports, it is challenging to uncover the critical details. SOC 2 reports help companies evaluate the security risks of their vendors and validate that your vendors have basic security practices in place to protect your sensitive information. This article will help demystify what to look for when receiving a SOC 2 report and where to find technical details and security configurations.
Sections of the SOC 2 report
In most SOC 2 reports, you will find four sections and an optional fifth section:
- Section 1 - Independent Service Auditor's Report
- Section 2 - Management's Assertion
- Section 3 - Description of the system
- Section 4 - Trust Services Criteria and Related Controls
- Section 5 - Other information provided by management
Section 1
How do you know if the SOC 2 audit was "passed" or completed successfully? Section 1 of the report contains the independent service auditor's opinion, which outlines whether or not the organization undergoing the SOC 2 assessment passed the assessment. You should be aware of two common opinion types: qualified and unqualified. A qualified opinion means the auditor found at least one issue during their evaluation. This issue could be something as simple as a new hire who didn't complete security awareness training or something more severe like a data store that is not encrypted at rest. A qualified opinion is not the end of the world and is pretty standard.
The other opinion type is unqualified. An unqualified opinion means the auditor did not find any issues, every control tested was designed appropriately (Type 1) and operated effectively (Type 2). While section 1 gives you the overall status of the assessment, there aren't many details here beyond the opinion.
Section 2
Section 2 of the SOC 2 report is management's assertion which is where the company undergoing the SOC 2 states that they prepared the system description (Section 3) and that the controls in that description were suitably designed as of a specific date and operating effectively over a period of time if a type 2 report. This section does not contain technical details and is essentially your customers' management acknowledging that the information they provided was accurate and relevant.
Section 3
If you don't read any other section of the SOC 2 report, read section 3. The description of the system outlines the actual scope of the SOC 2 examination covered. For example, imagine receiving a SOC 2 report for a SaaS vendor that you are evaluating. You remember from conversations with them that they host their application on Amazon Web Services (AWS). You flip to Section 3 of the report, and you don't see AWS mentioned anywhere. It is possible this SaaS vendor earned a SOC 2 but not on the service or application that is relevant to your organization.
This is why Section 3 is so important. You want to ensure that the scope of the SOC 2 report is relevant and applicable to your company, and the auditor assesses the technical environment of the application or service that you are planning on utilizing. There are nine sections in Section 3, and this is usually the longest section of the report:
- Overview of Services Provided: You'll find a brief overview of the services provided by the company undergoing the SOC 2. Pay particular attention to what is described here and ensure that this section discusses the service or application you plan to use. You shouldn't find any marketing language like "best ever" or "first in class" here, as every section of the SOC 2 report should be objective and factual information that an auditor can formally assess.
- Principal service commitments and system requirements: An interesting aspect of SOC 2 is choosing which Trust Service Categories (TSCs) to include in the scope. Most people choose these based on customer demand. However, your in-scope TSCs should be based on the commitments you make to customers in Master Services Agreements (MSAs), Service Level Agreements (SLAs), and other contractual agreements. This section of your system description includes your commitments to your customers as they relate to your in-scope TSCs. For example, if you have Availability as an in-scope TSC, we expect to see commitments related to uptime levels.
- Components of the system: This section is where you'll find valuable technical details such as where the company is hosted, software tools used to help with change management, vulnerability management, access control, etc. If you want to quickly understand the tools and technologies in place at this company, this is the section of the report to find that information. As we mentioned earlier, if they are hosted on AWS, you'd want to see details about their AWS environment here.
- System incidents - If an incident resulted in the company failing to meet its commitments, that incident would be described here.
- Control Activities: You'll find a narrative of the control activities here. Suppose you want to know how this company onboard new employees or their vulnerability management process details. You can find that here. This section puts the controls in Section 4 (described below) in narrative format. You should see a direct correlation between the controls described here and those listed in Section 4.
- Complementary user entity controls (CUECs): CUECs are the controls this company expects you to have for its system to achieve its goals and meet its commitments. A simple example here that you will see listed is around access control. If you terminate an employee, you and your team must inform the SaaS company to remove their access or remove their access yourself. If the SaaS company is not told the user is terminated, they won't delete their account. It is essential to review this section to ensure you have controls in place that accomplish what this company expects you to handle.
- Complementary subservice organization controls (CSOCs): We all heard of the shared responsibility model and understand those cloud providers are responsible for the security of the cloud and cloud users are responsible for security in the cloud. This section of your description outlines the controls that are the responsibility of those cloud providers (aka subservice organizations in SOC 2).
- Specific trust services criteria not applicable to the system: If there were any not applicable criteria, they would be described here.
- Significant changes to the system during the period (Type 2 reports only): Did the company change cloud providers? Did they acquire a new company that is now in scope? This is where that material change would be described in detail.
This section of the report is critical to ensuring the SOC 2 report is relevant and helps you decide whether to conduct business and trust this company. So invest the time reading and thoroughly understanding this critical section of the report.
Section 4
Most people get a SOC 2 report and immediately flip to this section because this is where you will find all of the controls listed that were evaluated in the SOC 2 examination. The first three sections of the SOC 2 report will be the same whether the company is undergoing a SOC 2 Type 1 or SOC 2 Type 2. Section 4 is where you'll find some significant differences between these two types of reports.
In a Type 1 report, Section 4 will include a list of all controls tested in the examination. However, you won't find any service auditor tests or results of tests. Type 1 is a point-in-time assessment that includes the auditor's evaluation of whether controls were suitably designed at a specific point in time. The AICPA does not require auditors to have test steps or results since we are not assessing operating effectiveness here.
In a Type 2 report, you will find the list of all controls, the auditors' test steps, and the results of those tests. This is why most people flip to this section of the report. They are looking to see if the auditor identified any exceptions or deviations during their testing. An exception or deviation is when the auditor performs a test and identifies a control activity that was not operating effectively.
Whether Type 1 or Type 2, it is essential to review the control activities and assess whether the customer you are evaluating has controls in place that you expect to protect your data. In Type 2, pay attention to any controls where exceptions were identified and assess the risk of that control not operating effectively.
Section 5
This is an optional section of the SOC 2 report, but you could potentially find some valuable technical information in this section as well. There are two common reasons you'll see this section included in a SOC 2 report. The first is a response to any exceptions or deviations identified in the SOC 2 report. For example, when an auditor determines a gap or control failure in a SOC 2 Type 2 report, they will document the finding in Section 4. Most professionals think this is the end of the story, but it's not. In Section 5 of the report, customers can respond to any exceptions or deviations, providing additional context and information to help you understand the circumstances surrounding the issue identified by auditors. As an example, let's say you receive a SOC 2 report that includes a deviation for terminated users. The exception language from the 3rd party auditor will not involve many details that provide context around the finding. You'll find those additional details in Section 5 of the SOC 2 report, where the customer undergoing the SOC 2 report get an opportunity to provide context around the exception and explain any mitigation strategies or remediation steps that they performed.
SOC 2 reports are long (longer than this article) and contain confusing information. Leverage this article as your guide when reviewing SOC 2 reports. Not all SOC 2 reports are created equal, and diving into the details of the reports you receive will help you effectively evaluate the security of critical vendors in your supply chain.
