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.
@ragjonlong asks why #CPAs keep abusing #SSAE16 and why doesn't @aicpa stop it.riskassuranceguy.blogspot.com/2013/06/irrega… #GRC #riskmanagement
— French Caldwell (@iTGuru) June 6, 2013
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.