The following conversation about reviewing a SOC 2 report is one to avoid.
Potential Customer: “Hi Vendor Co., do you have a SOC 2?”
Vendor Co. Sales Rep: “Yes!”
Potential Customer: “Great! We can’t wait to start using your service.”
The output of a SOC 2 audit isn’t just a stamp of approval (or disapproval). Even companies that have amazing cybersecurity and compliance programs have a full SOC 2 report written about them by their auditor that details their cybersecurity program. SOC 2 reports facilitate vendor risk management by creating one deliverable that can be given to customers (and potential customers) to review and incorporate into their own vendor management programs.
Vendor security management is an important part of a company’s cybersecurity program. Most mature organizations’ process of vendor selection includes a vendor security review – a key part of which includes the review of a SOC 2 report.
SOC 2 reports can vary greatly in length but even the most basic SOC 2 report is dense with information that can be difficult to digest, especially if you aren’t used to reading them. This article will teach you how to read a SOC 2 report by providing a breakdown of the report’s content, with emphasis on how to pull out the important parts to look at from a vendor security review perspective.
Please note that you should not use this as a guide to hunt and peck your way through a SOC 2 report. It is important to read through the entire report to gain a full understanding of the system itself. However, this should help draw attention to the particular points of interest you should be looking out for when reading a report.
Many different auditing firms perform SOC 2 audits, some reports may look a little different from the others but the overall content is generally the same.
How to read a SOC 2 report: the Cover Page Even the cover page of a SOC 2 report has a lot of useful information. It will have the type of SOC 2 report, date(s) covered, the relevant trust services criteria (TSC) categories, and the auditing firm that conducted the audit.
What Type of SOC 2 Report? There are two types of SOC 2 reports that can be issued: A SOC 2 Type I and a SOC 2 Type II . The type of report will be denoted on the cover page. The key difference is the timeframe of the report:
A SOC 2 Type I is an attestation that the company complied with the SOC 2 criteria at a specific point in time.
A SOC 2 Type II is an attestation that the company complied with the SOC 2 criteria over a period of time, most commonly a 6 or 12 month period.
VIDEO
SOC 2 Type II reports are more valuable because they demonstrate a long-term commitment to a security program – and any issues over the time frame will be revealed. It’s possible for a company to get a SOC 2 Type I report then fail to adhere to their controls.
Key takeaway: If a company only has a SOC 2 Type I, ask if and when they are working on achieving a SOC 2 Type II. If they say they are not getting a Type II, this is indicative of a lower commitment to security.
Trust Services Criteria
There are 5 different SOC 2 trust services criteria : Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is required, the rest are optional. Each criteria is best thought of as an area of focus for a cybersecurity compliance program, and may or may not be relevant based on the product a business provides. Consequently, organizations themselves decide which trust services criteria they include in their SOC 2 audit.
Key takeaway: Make sure the trust services criteria a vendor includes aligns with their product offering. For example, a cloud storage vendor should certainly include Availability so you can learn details about their data availability controls!
The Auditing Firm There are many different auditing firms that offer SOC 2 auditing services. Not all are created equal. It is important to note whether or not the auditing firm has a good reputation for performing SOC 2 audits.
If the vendor is being audited by the same auditor as companies like AWS or Google, then you can be pretty certain they are conducting a thorough audit for the vendor you are looking into as well. If the auditing firm is relatively unknown in the SOC 2 realm, or if it has a reputation for conducting subpar audits, then you may want to investigate the vendor’s security practices beyond reading their SOC 2 report.
Key takeaway: The reputation of an auditing firm matters. Any CPA firm may technically be allowed to perform a SOC 2 audit, but you may not want to take “Bob’s Back Alley Family Tax CPA Firm” at their word without further investigation.
Note: this is one of the reasons it’s important to avoid using a bad auditor for your own SOC 2 report!
“Independent Service Auditor’s Report” Section This is where the auditing firm states that they performed an examination of the described system/services. They provide a summary of the auditor’s responsibilities and the service provider’s responsibilities, as well as some details of how the audit was performed.
The main point of focus in this section is this is where the auditor states their opinion of whether or not they are SOC 2 compliant.
This opinion is given as either an unqualified or a qualified report. Unqualified is good – that means there are no qualifying factors that need to be made in order for a company to be SOC 2 compliant. A Qualified report indicates non-compliance, which is a red flag.
Key takeaway: A qualified report means the vendor is not in compliance. If you care about security, avoid that vendor. Unqualified does not mean they’re out of the woods, because there could still be exceptions. Always review the exceptions in case there is anything concerning.
Management’s Assertion Section In the Management’s Assertion, the audited organization’s management states that their description of services is accurate and the organization fulfilled the requirements for the applicable TSC for the selected categories to the best of their knowledge. There is nothing to read too deeply into here.
Description of System/Services The Description of System/Services provides a brief company and/or services overview, then provides details of the services/system within the scope of the audit. The scope can be the entire company, one system/service, or a set of services.
This is the bulk of the SOC 2 report. It describes the system in detail, including architecture/environment, subservices and customer delineations and responsibilities. Network and architecture diagrams are often included in this section. The relevant aspects of the organization’s internal controls are composed of five components: Control Environment, Risk Management, Information and Communication, Monitoring, and Control activities. The characteristics of these controls are implemented through policies, communications, procedures, and monitoring. Each of these components and characteristics are described in detail.
There is no one key takeaway here, it should be carefully reviewed to understand how the system in question works and is controlled to keep data secure.
Reviewing this section takes time, but you will get improve and get faster at identifying the most important and relevant information to your business as you better learn how to read a SOC 2 report.
Complementary User Entity Controls (CUEC) Complementary User Entity Controls refer to certain policies, procedures, and controls which must be implemented by the customer. Multi factor authentication and single sign on are common CUECs.
Sometimes CUEC is pulled out into its own section, sometimes it is within the System Description. Either way, it’s important to note which controls you will need to implement when using the system.
Complementary Subservice Organization Controls (CSOC) Most organizations utilize subservices for their system/service. These subservices are expected to be responsible for certain control activities for the system. For example, cloud providers such as Azure/GCP/AWS are all examples of subservices which are responsible for the physical safeguarding of their server rooms.
One situation you would want to perform an independent review of a subservice is if it is a smaller or unknown company. You will want more information about Messy Mike’s Cloud Server Emporium than what is present in the CSOC section of the SOC 2 report.
Like CUEC, CSOC is sometimes put within its own section and other times is placed within the System Description.
Shared Responsibility This is not always pulled out in detail in SOC 2 reports, but if present describes the control criteria where responsibility for aspects of the control are shared between the vendor, customer, and/or subservice provider. If one party does not carry its weight, then the control is not fully in compliance.
Access control is a common shared responsibility, from the vendor’s perspective they are responsible for their employee’s access. From the customer’s side, they are responsible for their user’s permissions. AWS is not responsible when one of its customers makes the (bad) decision to give out root login information to everybody.
Key takeaway: The Shared Responsibility section, if present, will tell you what your organization’s responsibilities will be to ensure control effectiveness.
Control Criteria, Service Controls, Testing, and Results Mapping This section is a massive table with each control criteria and control activity listed. It presents the finer details and information of the performed audit. Information about each control’s implementation is given and the auditor tests each control to verify compliance. The auditor’s testing is explained along with any notes the auditor may have.
Exceptions are listed in this area.
How to read a SOC 2 report: Exceptions An exception is a note on the report given for each control activity test the audited company fails or partially fails. If a control is verified, there is no exception noted.
Common exceptions are in change management where they didn’t submit a ticket for some sort of privileged user access change or forgot to put an employee in employee onboarding. The auditor will state whether or not the exception affected the overall effectiveness of the control implementation.
Each control should be reviewed for any exceptions because any exceptions not severe enough to cause a qualified report will not be brought to attention in the “independent service auditor’s report” section.
For any exception, the management is allowed a response to the exception to explain or provide any applied remediations. These responses are either included in the Control Criteria Mapping table or in its own section following the table.
It is important to review each exception with a fine-toothed comb because the details can be very helpful in understanding the service organization’s security posture. Exceptions may be minor, they may or may not be relevant to your particular use of the system, or may reveal a trend of company non-compliance to written processes.
Sometimes (but not always), the auditor will include a list or table of exceptions in the report. If it’s present, it’s a convenient way to make sure you have reviewed all of them.
Some of the common exceptions listed above that can be chalked up to minor administrative human errors are forgivable if they are sporadic. Multiple or repeated small offenses like this add up to a red flag that indicates a weakness on the managerial/process level. Another red flag is a failure to remediate vulnerabilities within a reasonable amount of time.
Key Takeaway: The key to reading exceptions is to find the answer to the following question: Does the vendor actually prioritize security? If the answer is no, you should be wary of using them.
It’s also important to watch for exceptions that are relevant to your use of the vendor’s product. If you are reviewing a cloud-based SaaS solution but they haven’t performed good vendor reviews for the cloud tools they’re using, you should be wary.
Understanding exceptions and their impact on your business is one of the most important skills to develop when learning how to read a SOC 2 report!
Conclusion on How to Read a SOC 2 ReportYou can’t just confirm that a vendor has a SOC 2 report and feel confident about their security program. Without reviewing it, you can’t be sure they’re even actually compliant! Digesting a long and detailed document can be intimidating, but once you know how to read a SOC 2 report, you will learn a lot about the vendor’s security posture and be able to make much better decisions about vendor management.
Want to get great cybersecurity content delivered to your inbox? C lick here to sign up for our monthly newsletter, Tales from the Click.
