Irregardless, Begs the Question, and SSAE 16 Certified

Tuesday, June 04, 2013

Jon Long


imageThese 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?

imageCalling 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.

Jon Long, CISA, QSA is a Senior Manager and Practice Builder at CompliancePoint  and is currently championing an audit approach that allows organizations to combine multiple compliance requirements into a single SOC2 engagement.

Cross-posted from The Risk Assurance Guy

Possibly Related Articles:
Cloud Security General HIPAA PCI DSS Budgets Enterprise Security Policy Security Awareness Security Training
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.