SOC 2 is being Ignored by the Data Center Industry

On the anniversary of SOC report launch,  of Reckenen Accountants & Associates published the following results of their survey of data centers in the U.S.  The results clearly indicate the market's response to the AICPA's attempt to correct the misuse of SAS 70 that was so pervasive in the industry before SSAE 16, and that continues under the new attestation standard.

With the rejection of SOC 2, the data center industry is telling the AICPA, we hear you, but we are not interested.  Our customers are not asking for SOC 2 because our SOC 1 (SSAE 16) reports contain the information they are looking for with regard to the security, availability, processing integrity, confidentiality, and privacy of the services we provide them.

Until the AICPA gets tough on CPAs that are issuing opinions under the SSAE 16 attestation standard on engagements that include testing of controls that are not relevant to internal controls over financial reporting (non-ICFR controls), there will not be a significant change in this reality.  Two years after the launch of SOC reports, the data center industry is ignoring SOC 2.

Celebrating SOC’s 2nd Birthday (Infographic) - An Infographic from SOC Audit Examinations & Outsourced Accounting for Private Companies

Hosting.com is in the Elite Group of CSPs with SOC 2 Reports

I have been observing the transition of SAS 70 to SOC reports over the past two years, and have noted that the same misuse that was occurring with SAS 70 reports carried forward to SOC 1  (SSAE 16) reports.  I would be remiss, however if I did not highlight cloud service providers (CSPs) that have chosen to undergo the more applicable and rigorous SOC 2 attestation engagement.  Based on my observations, Hosting.com is among the Top 10% in SOC compliance rigor – not only keeping up with key details behind compliance – but actually ensuring that compliance is a part of their solutions, so their customers have less to worry about.

In the embedded webinar below, Sean Bruton of Hosting.com explains why they decided to pursue a SOC 2.  Here are a few of his note worthy quotes:

2:18 “SAS 70 has a long history of having nothing to do with IT service providers.”

4:10 “SSAE 16 retains the original purpose of SAS 70.  That is, compliance around internal controls over financial reporting.”

5:18 Gartner Weighs In – SAS 70 is useless for security

5:35 Now there are options.

6:08 “The AICPA is saying that SOC 1 is the wrong report for IT service providers to run.”

6:45 “If your service provider has passed a SOC 2 assessment; if you got a SOC 3 report, then what you have is assurance that they met a minimum standard of due diligence.”


7:30 “SOC 3 is great for marketing purposes, but get a copy of the [SOC 2] report!  The reason you do this is because at the end of the day, [without the detail a SOC 2 report provides], you have no knowledge of specifically, what controls the service provider has implemented, what is ultimately your responsibility to implement with the applications you are hosting in the cloud.”

Sean is an extremely rare individual, and I hope to be able to interview him in person very soon.  Connect with him on LinkedIn here:

Irregardless, Begs the Question, and SSAE 16 Certified

These are words that resemble the sound of nails scratching a chalkboard to me.  "Irregardless" is not a word, and is not a substitute for irrespective or regardless.  "Begging the question" is a logical fallacy, not a substitute for "...which raises the question...", and there is no such thing as an "SSAE 16 certification".

For the past two years, I have supported the AICPA's efforts to correct the misuse of SAS 70 by replacing it with SOC reports, yet day after day I read press releases and blog posts by companies claiming that their SSAE 16 certification proves that their services are secure and available.

I think I may have finally begun to realize the futility of it all though.  We used to say, "Ain't ain't a word, because it ain't in the dictionary", but that's not the case anymore.  It's there!  It has just been labeled "non-standard."  Just as widespread use of "ain't" and irregardless have led to them being added to the dictionary, maybe it's time to just label the misuse of SSAE 16 reports as "non-standard" and let it go.

What about serving the public interest though?  The Code of Professional Conduct says: A distinguishing mark of a profession is acceptance of its responsibility to the public (Rule 201 Section ET 53 – Article II – The Public Interest).  What about the customer of an outsourcing vendor who sees a fake SSAE 16 logo, reads that the company they are doing business with has been "SSAE 16 certified", and proceeds to place reliance on a report that the AICPA says is not designed to provide assurance regarding security or availability?  If the CPA firm who issued the SSAE 16 report does not disassociate themselves from such a company, and if the AICPA does not hold them accountable for doing so, then has the public interest been served?

Calling the report a certification is only part of the problem though.  This slide from an AICPA presentation (that you can download by clicking on it), says that SAS 70 reports contained controls related to subject matter other than internal control over financial reporting (ICFR).  That problem persists today...two years after SOC reports replaced SAS 70.

We cannot really blame service organizations or their customers for thinking a report containing environmental and operational controls, tested by an independent CPA firm, provides assurance about the security and availability of their services though can we?  After all, what's wrong with relying on my data center's SSAE 16 report if I need to know that they have a diesel generator for backing up commercial power in case there is a power outage, and the report includes that testing?  The same thing goes for having UPS units, fire extinguishers, raised flooring, etc.

The problem is that these things have nothing to do with my data center's role in assuring the accuracy of my financial statements, and they are not supposed to be included in the report.  To comply with their professional standards, every CPA must require their clients to remove non-ICFR controls.  Yet two years after the launch of SOC reports, every SSAE 16 report I have seen contains non-ICFR controls, and the auditor has issued an opinion as to their effectiveness.  I have seen guidance from CPA firms that list removal of these kinds of controls as optional, and have clients who tell me their CPA firm has never even mentioned the need for a re-evaluation of their controls for ICFR applicability.

At the risk of sounding like the annoying guy who corrects people's use of the word irregardless, I will say the following:


  • If you are a company relying on service providers, and your service provider gives you their SSAE 16 report as assurance that their services are secure and available, demand a SOC 2 report, or walk away.  
  • If you are a service provider, and your CPA firm has not walked you through re-evaluation of your controls for ICFR applicability, contact me, or a CPA firm that will help you through that process.  
  • If you are a CPA firm who has clients who still want to include blatantly non-ICFR controls in their SSAE 16 reports, then have the courage to say you will not opine on them this year, and that they must be moved to the other information section.

Let us all do our part to stop the misuse of SSAE 16 reports.


Thank you for the endorsement French.  It is indeed an honor to have the ear of the Gartner Risk Management analyst who first reported SAS70 abuse in 2010.