How to read a SOC 2 Report (When You Don’t Really Want To), Part I

Last Updated on January 15, 2024

View our free cybersecurity resources »

View Now!

“The Bourne Ultimatum,” by Robert Ludlum. “The Hunt for Red October,” by Tom Clancy. “SOC 2 – Type II Service Auditor’s Report,” by Random & Random, CPA.
One of these things is not like the others. SOC 2 reports generally don’t make it to the top of the New York Times best-seller list. They are long, complicated, and boring… and incredibly important to understanding the risks posed to your company by third parties. But few people read them, and part of the reason is that they can be daunting and hard to understand; they were expressly designed as communication between professional auditors and, much like practitioner-to-practitioner communication in other professional fields, they can be hard to decipher if you’re not “on the inside.”
This blog post is intended to help you (as a non-auditor business or IT professional) understand what a SOC 2 really is, what information it contains, and how you can use it. If you have a SOC report available, it might be helpful to look at it as a reference. While not every SOC 2 will contain everything here, and/or it may have a different name, this is generally applicable to most SOC 2 – Type II reports you will review.
A “SOC 2” is a “Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy,” managed as a standard by the American Association of CPAs. In information security, the traditional “axes” of security are Confidentiality, Integrity and Availability (the CIA Model). So this report is oriented towards information security, and is designed to communicate the results of an independent auditor’s review of the security-related controls at a company that provides services (“service organization”) to other companies.
One very important element of this report is that it is independent. That is, it is conducted by a third party. It is not performed by the internal audit group or IT security group at the company being reviewed. This increases the value of it, since the auditor is not supposed to have a vested interest in the findings of the report. An outside, independent, professionally-skilled auditor is brought in, and evaluates the controls related to those three axes. While there is a fair amount of latitude in what is covered in a SOC 2 (we’ll cover this later), the format is fairly standard, and there are several things that are important to understand when reading a SOC 2 that can be gotten to fairly quickly, once you understand what you are looking for.
There are two types of SOC 2: Type I and Type II. This is one of the critical things to look for when reading a report. A “Type I” report is an analysis of whether the controls appear to be designed correctly. No testing is really done to ensure that the controls are being performed as designed, and no testing is done to determine whether (even if they are) they are accomplishing the end goal (or “control objective” in auditor-speak).
A Type II report is much more in-depth and valuable. For this type of report, the auditor is required to test the effectiveness of the controls; to go in and really look at how they work, and review samples to see how they are functioning. It is helpful to know what controls are in place at an organization (Type I), but it is much better to know that they are actually working (Type II). Many organizations start their SOC 2 process by having a Type I done, and will later move on to a Type II. A good question to ask your supplier, if you receive a SOC 2 – Type I report, is whether they intend to have a Type II performed subsequently.
Another thing to remember is that you will often have to expressly request a SOC 2 from your supplier. By design, these reports are sensitive and intended for limited distribution. You should not find a SOC 2 posted on the web. There is a different type of report (a SOC 3) that is designed for this kind of public consumption. The SOC 3 leaves out the highly sensitive information, while still providing a mechanism to communicate that a review was performed, and what the auditor’s opinion was.
Which brings us to the next part: The Auditor’s Opinion. While there are some parts of a SOC 2 that can be safely skipped over in some cases, it is important to read and understand what this section says. It will usually be the very first section in a report. It will list what the scope of the review was (i.e., what it included), when it was performed and what time period it covered, and what the auditor’s overall opinion was about the audit. One of the things you will want to look for in this opinion (often this is not explicitly stated, but sometimes it is) is whether the opinion is “qualified.” In true paradoxical auditor-speak, a “qualified” opinion is not good… it basically means there were exceptions or deviations that are important to note.
The next section in the report is usually “Management’s Assertions,” which are the company’s description of what is contained in the report, and how they approach the review. One thing to note here is how the organization deals with controls at their own suppliers and contractors (called “subservice organizations”). Most of the time, the auditor will not test the controls at the subservice organization. They will use a method called the “carve-out method,” which essentially states that the subservice organization is responsible for its own controls. While this makes sense and is very common, it means that downstream suppliers (often called “fourth parties”) may or may not have adequate controls in place to ensure the security of your data. Often, critical suppliers will be expressly named in one of the subsequent sections. This part can be very helpful to understand where your data is going, who has access to it, and where it is residing.
This post covers the first few sections of a typical SOC 2 report. We will pick up more in Part 2.
Wondering where to start with third-party risk management, contact Pivot Point Security.