Does That Contract Properly State SOC Reporting Requirements?
A company recently contacted us requesting a SOC Audit. The request was based on a vendor contract which read “Supplier shall conduct a SSAE16 audit (SOC 2, Type II Report).” This request is simply inaccurate, and is a symptom of a larger problem we are seeing in the marketplace, which is confusion and improper guidance when it comes to SOC reporting.
We see many organizations requesting SOC reports from their business partners due to a corporate compliance mandate. It appears to be a default company request even though the business relationship may not fit the purpose and scope of a SOC report. For example, if the business is not sharing sensitive information with the supplier, or the supplier is not completing some financial duty on behalf of the requesting party, a SOC report is likely not warranted. In other words, just because there is a business relationship between the two organizations doesn’t mean that a SOC report is needed – or could even be completed.
Unfortunately, when we see contract language detailing SOC reporting requirements stated inaccurately, the company that received the request starts to question the credibility of the company that made the request. Let’s take a look at exactly what a SOC report is, and when it is applicable in a particular business relationship.
What is a SOC Report?
SOC stands for Service Organization Control. A SOC report is the end product of the completion of a SOC audit. A SOC audit must be performed by a licensed CPA firm according to the AICPA attestation standards. An example of an attestation standard is SSAE 16. SSAE stands for Statement on Standards for Attestation Engagements. There are three different types of SOC audits/reports: SOC 1, SOC 2 and SOC 3.
What’s Included in a SOC Report?
Each of the three different SOC reports (SOC 1, SOC 2 and SOC 3) have a different scope depending upon the business relationship between the organizations. A SOC 1 report is applicable if one organization completes a financial duty of behalf of another. An example of this would be a company completing payroll processing on behalf of another. A SOC 2 report is generally applicable if an organization is sharing sensitive information with another organization. For example, a company that is a technology cloud provider and stores sensitive data on behalf of another. Finally, in its simplest form, a SOC 3 report is a “subset” of the information that would be included in a SOC 2 report. The SOC 2 business relationship example would also apply to a SOC 3 report.
To complicate it further, within the SOC 1 and SOC 2 reports there is additional definition as to the type of report (Type I or Type II) a company can get. A Type II report requires and includes more audit evidence than a Type I report, thus providing the reader a higher degree of credibility.
A SOC 2 report also has different reporting sections which are called “criteria”. There are five criteria sections available: Security (Common Criteria), Availability, Processing Integrity, Confidentiality and Privacy. The only required section in a SOC 2 report is Security (Common Criteria), the other sections are optional. Why is this important? Because too often the request by an organization for a SOC 2 report doesn’t specify a listing of criteria to be included in the SOC 2 report, causing the organization receiving the request to either ask for clarification or decide on its own which criteria sections to include.
What AICPA Attestation Standards are Followed for Each SOC Report?
A SOC 1 report follows attestation standard SSAE 16, whereas SOC 2 and SOC 3 reports follow attestation standards SSAE 10-12 and SSAE 14. In our opening example, the company requested that “Supplier shall conduct a SSAE 16 audit (SOC 2, Type II Report)”. Based on what you have now learned, you can see that the organization mistakenly requested two reports: A SOC 1 report (SSAE 16) along with the explicit SOC 2 Type II report.
SOC reports can provide significant value between partnering organizations, but SOC language is complex and there are many nuances to understand.
When helping your clients include SOC reporting requirements in their vendor contracts, Olsen Thielen’s SOC Practice Area experts can assist you in getting it right. Contact Daniel Owens, CPA at 651-621-8623 to discuss your situation.