Incomplete Thought: The Crushing Costs of Complying With Cloud Customer “Right To Audit” Clauses
As Cloud Computing continues to capture the hearts, minds and other assorted organs of business folk everywhere, the economics of outsourcing services to the Cloud come more and more into focus. Here’s one element that I don’t think is being paid much attention, however*:
While most of the cost/benefit analysis is being discussed as it relates to the “consumer” side of Cloud, the providers themselves have an equally burgeoning issue surfacing as it relates to cost; satisfying right to audit clauses.
Almost all of the Cloud providers I have spoken to are being absolutely hammered by customers acting on their “right to audit” clauses in contracts. This is a change in behavior. Most customers have traditionally not acted on these clauses as they used them more as contingency/insurance options. With the uncertainty relating to confidentiality, integrity and availability of Cloud services, this is no more. Cloud providers continue to lament that they really, really want a standardized way of responding to these requests**
These providers — IaaS, PaaS and especially SaaS — are having to staff up and spend considerable amounts of time, money and resources on satisfying these requests from customers.
When I negotiated contracts for outsourced services, I always required an RTA clause. It was non-negotiable. I also acted on them several times in response to an issue or request from an auditor/regulator.
If you aren’t writing these clauses into your contracts, you should be. For those of you who have done so, good on you for being diligent. To those providers who are eating it with the load this renders, I feel your pain but I fear it will only get worse.
/Hoff
* This WordPress theme makes indented captions look like quotes. This is a highlighted section written by me and is not a quote from someone else. Sorry for any confusion.
** This is where/why Cloud providers should get involved with the Cloud Security Alliance — we can, as a community, facilitate both expectations and deliverables from both the consumer and provider perspective…
I wish you had written this before I published my article "SOA, Cloud and the Rise of the IT services-based Economy". In that article I discuss how SLA reform is going to be necessary to really help the IT Service-based Economy to take off. This is an excellent example of how SLAs (I am considering the RTA facet to be a component of the SLA) are a significant hurdle to just jumping out into the cloud. However, this time the burden falls on the provider versus the consumer.
For me this is also another nail in the ROI coffin for cloud providers being able to have a sustainable business model without VC infusions.
Well done piece Hoff!
A good start for SaaS providers is a 3rd party code audit. We performed one recently for Coagutrak: http://bit.ly/cdnsQ
At Veracode we also have a SysTrust certification which is updated quarterly by E&Y. http://www.veracode.com/about/certification.html
These two reports are typically enough evidence so that most customers do not need to audit.
Couldn't agree more – that's the same I've been hearing and not something many providers anticipated. As an example, one large SaaS provider stated they are hosting different customer audits *every single day*.
Ultimately, the cost of this auditing has to be accounted for which means providers have to factor into their service costs…thus the customer will pay, therefore its in the interests of Cloud customers as well as providers to work together on this to lower the costs through agreeing smarter ways to handle this.
I don't think this approach is sustainable long term.
Hoff, it would be reasonable to assume that, in the cloud era, the notion of auditability is likely to fall into (at least two) buckets.
(1) the auditability offered / demanded by the customer to assure vendor's compliance and performance against criteria (or, presumably suffer the financial consequences)
(2) the auditability required by two or more operating entities, to act as the authoritative source or system of record in such things as charge-back, multi-party accounting and settlement, etc.
The second bucket is clearly a commercial opportunity. As companies like Verisign and NeuStar have demonstrated in the past, the economic and operational model on the internet can turn a requirement into a business. (Yeah… I know, it can also lead to some rather abusive approaches as well, not to mention pricing of the so-called neutral services at levels that bring the word 'gouge' to mind.)
I'd like to get your take (and that of other commentators) on the potential for the first bucket of auditability requirements to become something less onerous by virtue of an 'open services' or 'freemium' model. [Truth in advertising:] I'm in the midst of working through the requirements for a commercial offer, based on the freemium business offer. Among the candidate services to consider for this idea, we're looking at various aspects of accounting, record-keeping and audit that would be used in a variety of scenarios. I'd be interested in hearing from your readership about their requirements in this regard, and of course from any folks interested in a deeper conversation about the idea. (I'll take the answers off the air. kthxbye.)
Interesting- there's a parallel here to how the financial services industry has evolved in 3rd party risk assessments. Traditional (non-cloud) service providers to that industry were getting similarly crushed by assessment requests, and by onsite audits for the most critical service providers. BITS did some good work in defining a standard assessment questionnaire (SIG) and set of audit tests (AUP) for this industry as a part of their "Shared Assessments Program". Their work didn't go far enough perhaps (the assessments aren't really "shared"), but nonetheless they did at least reduce the burden on the service providers by defining a standard set of assessment questions and audit tests. This is in contrast to what had been the case- every large financial institution had a proprietary risk assessment questionnaire, and the SP's had a mess to deal with.
The cloud service providers (and consumers) would do well IMHO to use this sort of a model in assessing risk in cloud computing, and the CSA would be a great place to develop this approach.
Jim
Chris, is this your quote? Or someone else? If its something you're read, can we get a link?
Thx
Forgot to mention the obvious. These RTA clauses are *NOT* in the standard subscription agreements you see from Salesforce.com or most any other I/SaaS provider.
http://www.salesforce.com/company/msa.jsp
http://aws.amazon.com/agreement/
The self-service aspect of CC pretty much disappears if you've got to negotiate an individual subscription agreement.
FWIW, I went back and read Amazon's HIPPA whitepaper and they say there:
"Using Amazon EC2, customers can run activity log files and audits down to the packet layer on their virtual servers, just as on traditional hardware. They can also track any IP traffic that reaches their virtual server instance. Customer’s administrators can back up the log files into Amazon S3 for long-term, reliable storage."
Which isn't quite what an auditor is probably looking for…..
Good point, there is already a standard for this kind of third party reporting. The Statement on Auditing Standards No. 70: Service Organizations, SAS 70 for short, there are various localized versions around. It's used to alleviate the audit burden on service organizations from RTA clauses. I dont know it in detail but I imagine it would be as good for a cloud provider as it is for other service providers.
Geir.
The good news is that the SaaS providers are learning from every RTA exercised and we're building additional features that were not planned by the creators of said services.
The miss above in the some of the comments is that despite SAS70s, Systrust, and other attestations, customers are in great fear and the only recourse left is to audit the situation themself and find out what's going on under the hood before they make a commitment.
Good luck gang,
Phil Agcaoili
Great post!
Good to see that this wasn't just an issue we were seeing here. We've been engaging (due diligence-ing/reviewing) all 3rd parties involved with potentially impacting information or processes, and *aaS providers are no different, but sometimes I get the impression they feel that they are outside the realm of having to explain their processes, procedures and technology.
If we're paying for a service, surely we're allowed to understand how it works? We can't "outsource" the impact-costs if that *aaS has a risk-event (or any other problem) – I mean that is our data isn't it?
-C
Hi Hoff
I had the same problem in managed services provider. The only way I could keep RTA clauses from bleeding me dry was to share audit data across clients.
Basically, I had one set of controls that applied across the board to all my customers–think personnel clearances, data center availability, physical access–that applied to every client. I document this and I provide this to all my customers as part of the basic service I provide. I do this because I only really have to do this once.
I then get an audit on those controls. This can be a client exercising their RTA, it can be a SAS-70 that I pay for, it can be any kind of independent assessment, the key is that it's scoped to at least the common controls that I provide.
The important thing to remember is once again contract requirements. If you get the right to audit, I get the right to the audit results and to be able to use a version of them that does not have the client's name on it. It's cheaper for you, it's cheaper for me, and you always have the option to audit anything above what I've already been audited for using whatever methods you like, as long as I can reuse the results.
Come on, the idea behind any outsourcing of any kind is economy of scale, the auditing needs to be scaled in the same way.
Crushing indeed.
I suspect a BITS-like audit response framework with more merit and proof of actual security than SAS70s appearing.
In the Cloud security model, SAS70s are a waste.
What are the general audit policies that an audit team considers in terms of encryption of data at the disk level as well as at the network level.