For CFOs: How to Read a SOC 2 Report
February 2, 2023 / by Kristof Holm
Whether in finance, marketing, IT, etc., the proliferation of applications used daily can increase vulnerabilities for cyberattacks. As a result, preventing cybersecurity breaches is something most companies take very seriously. Because of this, many IT departments provide guidelines when engaging with new companies. For example, one of the items on the checklist might be a SOC 2 report.
You may or may not know what a SOC 2 report is? It may sound like a character out of Star Wars, one of R2-D2's pals. Sadly, it is not. However, if it were a movie character from Star Wars, it would be on the Rebel Alliance's side fighting the Empire. SOC 2 reports were created to help protect your organization!
As DataBlend's Chief Information Security Officer, I often review SOC 2 reports. While we may have a culture of compliance, how do I know I can trust a vendor I just met?
As a former SOC auditor and lead for our SOC reporting, this review can be (relatively) painless. In addition, many companies will have a security or compliance team with experience reviewing this. But what if you don't? If you've never seen one before or in the past felt like it's taken an endless amount of time to get through the document, the points below are what I use to get through a report with ease.
What is a SOC Report?
SOC reports supply assurance. SOC stands for System and Organization Controls (SOC). SOC reporting is a standard type of independent examination against criteria published by the AICPA (The American Institute of Certified Public Accountants).
Which type of SOC report is it?
Is it a SOC 1 or SOC 2 report? A SOC 1 report focuses on financial reporting. However, if you're concerned with security, you want a SOC 2 report. There are multiple types of SOC 2 reports. Let's dive deeper into the different types.
Type 1 Report:
Covers a point in time: e.g., the auditors asked for evidence that something was done at the time of the audit but didn't look at anything from further in the past.
Type 2 Report:
Covers a period of time: e.g., the auditors reviewed the company's controls over the period listed. This could be 3 or 6 months, but 12 is the most common. Because SOC 2 reports are always backward facing, these reports will always cover a period in the past.
Typically, a type 2 report is more reliable because it indicates that the controls have been adopted as part of everyday life for the company. If I'm provided a type 1, I'll ask why they didn't get a type 2?
What about the contents? Most reports are over 100 pages. Where do I start?
Now that you know more about the different types of SOC reports and what each is good for, it's time to dig into the components to figure out where to begin. All SOC reports will have a cover page and four sections:
Cover Page:
Includes the type of report (SOC 1 or 2, type 1 or 2) and the audit firm's name. If you need to become more familiar with the firm that completed the audit, I recommend a quick search. Size is only part of it, but if you can’t find out much about the firm's reputation with a basic search, that is a definite red flag.
Section 1:
This is management's (the company's) assertion - also known as their attestation that what is in the report is accurate.
Section 2:
Auditors report - standard disclosures and the auditor's opinion on:
- the description provided by the management
- the design of controls management implemented
- the effectiveness of the controls management implemented
The opinion will either be qualified or unqualified. Unqualified means there are no qualifying factors and is a positive result. Because this vendor voluntarily shares the SOC report, qualified opinions are rare. Still, a qualified opinion would be a significant red flag.
Section 3:
The company's description of its operations. This is the one section that I always recommend reading in its entirety.
Section 4:
All the details of what the auditors looked at. At a minimum, you should scan through to identify whether the auditors had any findings. This is also where I'd suggest homing in on whatever service the vendor provides and spending a few minutes looking at the corresponding controls/tests.
For example, I once evaluated a software vendor whose SOC 2 report said that software development controls were not applicable. As a result, we didn't go with that vendor.
Other potential red flags to be on the lookout for include the following:
- Report Format – SOC reports follow a standard format. Is that format being followed?
- Report Date – If the vendor is providing an old report, you will be unable to assess controls properly. Always ask when the latest report will be available.
- Report Variations – Inadequate testing, testing old evidence as new, modifications to the report, or missing pages. All are signs that something is awry.
- Exceptions – Are there exceptions, and are they repeated exceptions from previous reporting periods? If there are exceptions, management should supply a response to them, and responses should be clear and concise.
SOC reports, like any certification (personal or otherwise), are a great starting point but not a silver bullet. If there is any doubt about the company's security or compliance posture, reaching out and asking a few questions is always a good approach.
DataBlend's Culture of Security and Compliance
Thankfully despite being a young company, we intentionally engrained Security & Compliance requirements in our culture early on. This requires our team to abide by strict controls and consider the security posture of any vendors, subcontractors, or suppliers we may use. If you'd like to chat about how much you love SOC reports, DataBlend's security team can be reached at, security@datablend.com.
About the Author:
Kristof Holm is DataBlend's Director of Security, Compliance, and Chief Information Security Officer. He leads Security and Compliance and builds demonstrable trust in DataBlend's capability to deliver fast, secure and worry-free integrations of everyday finance and accounting applications.
Hear from Kristof about building a culture of security and compliance.
Please accept cookies to access this content