The difference between SOC1 and SOC2 reports.

One of the key concepts we will go over in our discussion about vendor management at the IBA Workshop on March 26th will be “third party assurance.”   

Clients often ask me what the difference between a SOC1 and SOC2 report is, and my answer USED TO BE:

“who cares, you need a SOC2.”

However, I’m having to change that response, now that many bank providers are submitting SOC1 reports with the hope that you’ll accept them as third party assurance.

So instead of who cares, my answer is now:

“Who is ordering the audit reports?”

Here’s why:

The reason we’re seeing SOC1s acquired instead of SOC2s, is probably because Sarbanes Oxley wants a SOC1 report and we IT people want the SOC2 report, and they’re very expensive to get. Thus, since SOC1 reports are required by accountants and we information technology people are still scratching our heads, and because let’s face it, the beancounters are often more powerful in these organizations than the IT folk, we get to learn why a SOC1 is not really what we want.

See, the SOC1 report is meant to test internal controls over financial reporting. This covers a great deal of typical IT risks, but the focus is on internal fraud related to the INTEGRITY of information going into the financial statements.

The SOC2 report is designed for entities such as data centers, I.T. managed services, software as a service (SaaS) vendors, and many other technology and cloud-computing based businesses. And within the SOC 2 framework is a comprehensive set of criteria known as the Trust Services Principles TSP) that are composed of the following five (5) sections:

• The security of a service organization’ system.
• The availability of a service organization’s system.
• The processing integrity of a service organization’s system.
• The confidentiality of the information that the service organization’s system processes or maintains for user entities.
• The privacy of personal information that the service organization collects, uses, retains, discloses, and disposes of for user entities.

So though it’s obvious why we want the SOC2 report, many organizations required to get the SOC1 are hoping we’ll accept the SOC1 in lieu of a SOC2. Let’s face it, if we accept SOC1’s, our vendors can cut their audit costs in half.

Accountants care that the information going into the financial statements is secure, has integrity, and is available when it’s time to print those statements. But that doesn’t cover many threats to the information that is NOT going into the financial statements. So if you get a SOC1, you might have more questions to ask.  Or do you?

Because when you review a SOC2, the underlying question is “what controls should I expect.”  And then you make sure (assure) the SOC2 covered those controls.  Likewise, when reviewing a SOC1 the same question and assurance should take place.

So the real question isn’t what’s the difference in general, the real question is what is NOT being tested in the SOC1 process for THIS PARTICULAR VENDOR offering THESE PARTICULAR SERVICES requiring us to share THIS PARTICULAR INFORMATION . . . . that we would expect to have tested. Which, incidentally, is the same question you need to ask for the SOC2 process.

So whether or not you get a SOC1 or SOC2 report, you still need to decide what should be tested and look to ensure it is tested. And then risk rank any missing tests as missing controls.

(Clients:  If you do not already have our SSAE-16 review checklist, be sure to e-mail us!)

Dan Hadaway CRISC, CISA, CISM
Founder and Managing Partner, Infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”