How to Review a Vendor’s SOC Report

When Microsoft reported a 12% increase in revenue in their latest quarterly earnings report, the company attributed much of that growth to the ongoing development of businesses continuing to migrate to the cloud.

In what’s been a turbulent 2020, to say the least, many companies are still operating remotely and a number of those are preparing to remain remote for an extended period of time. In this volatile climate, monitoring your organization’s vendors has never been more important, and one way to do that is to request and review the reports a vendor provides created by an independent third party. A popular narrative that companies can have to provide to existing and prospective clients is a System and Organization Controls (SOC) report.

What is a SOC report?

A SOC report is an attestation detailing the work performed by a CPA firm. The standards behind the report, the Statement on Standards for Attestation Engagements No. 18 (SSAE 18), are written and maintained by the American Institute of Certified Public Accounts (AICPA). These standards define two types of reports for detailing the work CPA firms carry out when they examine the controls in place at service organizations: the Type 1 (point-in-time), which examines only the design of controls, and the Type 2 (period), which also examines the operating effectiveness of a control throughout a specified period.

Okay, but what's the difference between a SOC 1 and a SOC 2 (and others)?

In addition to the two primary types of SOC reports, there are also different reporting standards, as defined by the AICPA. Here’s a brief comparative summary that should allow you to determine the specific SOC report you need for your vendor. (For a more in-depth overview, check out our article, SOC reports.)

• SOC 1 are examinations related to internal control over financial reporting at a service organization.
• SOC 2 are examinations related to specific criteria set by the AICPA around the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and/or Privacy at a service organization.
• SOC 3 are general use reports. They’re essentially the same as a SOC 2, but do not include a description of the auditor’s testing or the results of the testing. These reports can be made publicly available.
• SOC for Cybersecurity deal with an organization’s cybersecurity risk management program. They’re a bit different in that they can be performed for anyone, not just service organizations.
• SOC for Supply Chains is the newest SOC, intended to help suppliers or logistics providers validate the effectiveness of their controls.

How do I get these reports from my vendor?

After determining which SOC report(s) you need, you’ll want to request the actual report. This process can vary from vendor to vendor; some might have a section on their website for clients to log into and download or request the SOC report, while others may require you to reach out to a designated point of contact.

Alright, I have the report, now what?

Now you can begin the actual review. Fortunately, all SOC reports follow the same basic structure, which helps when you’re reviewing multiple reports from different vendors. Before getting into the actual substance, though, there are some items you should note, including:

• Who reviewed the report?
• When was the report reviewed?
• Which vendor is being reviewed?
• What specific SOC report is being reviewed? (SOC 1 Type 2, SOC 2 Type 1, etc.)

Documenting these items alongside your review of the actual report will help your organization keep track of its ongoing oversight of the vendor in question.

Now it’s time to review the report itself. The first items to note are when the report was issued and the period of time the SOC report covers (if it’s a Type 2 report). Make sure this report is the most recent version. After you’ve recorded these details, you can move onto the first section, The Independent Service Auditor Report.

The Independent Service Auditor Report

Portions of this section you’ll want to review are Scope, Limitations and Opinion. Scope identifies the report period or as-of date for the examination, which services are covered by the report, whether the vendor relies on any subservice organizations (third parties that your vendor uses) and whether there are Complementary User-Entity Controls (CUECs) that you, as the client, need to have in place. Limitations will tell you if there were any events that occurred during the examination that limited the service auditor’s ability to perform their work and Opinion will note the type of opinion the service auditor has issued. There are four types:

• Unqualified – The service auditor has determined that the description of the system is fairly and accurately presented, and controls were operating effectively throughout the specified period (for a Type 2) or designed effectively as of a given date (for a Type 1). There could be exceptions noted, but the auditor has determined that they do not result in a modified opinion.
• Qualified – The service auditor has determined that the system description and most controls are fairly and accurately presented and operating effectively, but the service organization identified some controls that failed to operate effectively. These are described by the auditor in the opinion, with details of the exceptions that resulted in the modified opinion.
• Adverse – The service auditor has determined that the service organization failed to meet one or more control objectives (SOC 1) or criteria (SOC 2). These failure(s) are described in the opinion.
• Disclaimer of Opinion – The service auditor states that they cannot issue an opinion and gives the reasons, which could be anything from lack of evidence to controls that might not have operated during the period that are pervasive enough for the auditor to issue a disclaimer.

After documenting these, you can move onto your vendor’s description of the system in scope for the report.

The System Description

This section details important background information about the organization and the system the report covers. It should include an overview of the organization, as well as its people, procedures, processes, software, infrastructure, data and any additional relevant information that’s part of the system (e.g., user entity controls, use of subservice organizations, complementary subservice organization controls, etc.). This section should also include relevant aspects of the service organization’s control environment, risk assessment, information and communication systems, monitoring and internal controls. Users should already be familiar with these areas from experience using the vendor’s system but should still review the section to see what was specifically included versus what was specifically excluded from the engagement.

Also take note of the Complementary Subservice Organization Controls, they are the controls your vendor relies on third parties to provide. They’re useful in gaining an understanding of your vendor’s environment (e.g., if they send their backup data to Amazon Web Services (AWS) for storage). More significantly, you should note the Complementary User-Entity Controls, those are the controls your vendor assumes you’ve implemented and need to have in place but might not be pertinent to your organization if the report covers multiple services. Review this section and determine which controls are relevant. Finally, you can now review Section IV, the actual control testing, and Section V, if applicable, other information provided by the service organization (your vendor).

Test of Controls and Other Information

These sections should be reviewed closely to ensure you gain comfort over the controls and for the specific exceptions the service auditor has identified, if any. The exceptions are important because they provide an overview of the areas where the vendor’s controls failed. As you’re documenting your review, be sure to record them. Depending on the exception in question, you may need to follow up with the vendor and ask how they remediated the issue if you believe it’s relevant to your organization.

For some reports, a service organization may decide to include a final section titled, Other information provided by …, which contains information the organization feels users should know about but is not otherwise included within the system description. If a report has any exceptions, this final section typically contains management’s response, which could explain how management at your vendor intends to remediate the exception or if they’ve chosen to accept the risk. You should document these responses in your review as well.

Wait, there’s a gap between the end of the reporting period and my organization’s year end?

You might notice that in some cases, there’s a gap between a service organizations’s reporting period and the end of your fiscal year. To address this, management at your vendor will often write a Bridge Letter, which states whether or not there were material changes between the end of the reporting period and the end of your fiscal year. If your vendor has done this, you should review the letter as well as the SOC report itself to make sure you’re aware of any changes.

That’s the whole report; now what?

Now that you’ve reviewed your vendor’s report, there’s still some work to do. You need to examine the Complementary User-Entity Controls you documented as relevant and determine whether your organization has controls in place to meet the requirements. Document what you’ve specifically implemented. Finally, if the SOC report had any exceptions you felt were not adequately addressed, you should reach out to your vendor and determine what they’ve implemented to alleviate your concerns.

How often do I need to do this?

Only you can decide how often you need to review your vendor’s SOC report. Most organizations issue reports annually, but some release more often, using a six-month or three-month period, like Amazon Web Services, which issues a report every six months. If you rely heavily on AWS, for instance, you might determine that it’s beneficial to review Amazon’s SOC reports every six months. We recommend that a SOC report for each key vendor you use is reviewed at least annually, particularly for those vendors identified as high-risk as part of your third-party risk management program.

SOC report reviews are useful in two ways: they provide an excellent overview of a vendor’s control environment before you decide to contract with them, and they’re a great way to provide continued oversight.

Now that you have a documented review of your vendor’s SOC report, you can refer back to it and ascertain the specific changes that occurred over the past year, whether it’s the remediation of exceptions, changes in the control environment or changes in the system itself. By doing this, you’ll gain a better understanding of the risk that working with a vendor brings to your organization, and you can more accurately measure your own risk.

If you need assistance with reviewing your vendor’s SOC reports, or with evaluation or implementation of your organization’s third-party risk management program, contact our SOC and Third-Party Risk Management Professionals. Also see our SOC and Third-Party Risk Management sites for more information regarding Schneider Downs’ SOC and Third-Party Risk Management Practices.