Gartner walks into SAS 70 SNAFU - or does it?

Gartner opens up a discussion around SAS 70. It's high time but I disagree with the author's conclusions.
Written by Dennis Howlett, Contributor

Jay Heiser, research VP at Gartner has walked into something of a SNAFU. He says:

SAS 70 is  a) not a certification, b) not a standard, and c) isn’t meant to be applied the way it is being applied now.

I had to double take on that. What part of Statement on Auditing Standard did Jay miss? But then he goes on to explain something of what he's thinking:

To be fair, all service providers are under huge customer pressure to provide SAS 70, but instead of explaining their security, continuity, and recovery capabilities in more appropriate terms, most vendors make the unfortunate decision to exaggerate the  significance of their having undergone a SAS 70 evaluation.

Yep - SAS 70 and especially Type II has become something of a CXO's 'tick in the box' item and especially when evaluating cloud solutions. But it is here where Jay sets the cat among the pigeons. I'll take this in two pieces:

Why should a potential customer accept SAS 70 as being proof of anything? They don’t know what was evaluated, they don’t know who evaluated it, or what form the evaluation took.

My colleague Vinnie Mirchandani often says of SAS 70 that very few of the companies with which he consults bother to take the time to find out what was behind the evaluation. I've seen that as well. Even fewer validate what the SAS 70 certificate says. Box ticked? Move on.

Even if the evaluation did look at design and build considerations, it was almost certainly a very small part of the overall assessment, and do you really want an accounting firm evaluating security architectures and encryption implementations?

Well yes I do. Auditors have had a bad rap the last few years with corporate failures coming back to haunt what they certified in past accounts. Having recently brushed up my knowledge on SAP security and audit, I can see where there is a definite bi-partite role for both internal audit and IT that in turn can be independently tested by external auditors.

If accounting types are left out the loop then there is a potential for vulnerabilities to sneak in that might remain unchecked. Auditors are in prime position to understand how security is impacted by business rules applied to topics such as separation of duties in AP/AR/GL. These are critically important to ensuring the business behaves in an honest fashion. The failure to apply strong separation was a factor in the Satyam debacle.

You can always argue whether auditors are competent to assess the design to which Jay alludes but that's an entirely different argument to the one he presents.

So while I applaud Jay for bringing the topic forward, I disagree with his throwaway about who does the policing.

Editorial standards