I saw an interesting article about cloud provider liability limits, including some quotes from my esteemed colleague Drue Reeves (via Gartner’s acquisition of Burton). A quote in an article about Eli Lilly and Amazon also caught my eye: Tanya Forsheit, founding partner at the Information Law Group, “advised companies to walk away from the business if the cloud provider is not willing to negotiate on liability.”
I frankly think that this advice is both foolish and unrealistic.
Let’s get something straight: Every single IT company out there takes measures to strongly limit its liability in the case something goes wrong. For service providers — data center outsourcers, Web hosting companies, and cloud providers among them — their contracts usually specify that the maximum that they’re liable for, regardless of what happens, is related in some way to the fees paid for service.
Liability is different from an SLA payout. The terms of service-level agreements and their financial penalties vary significantly from provider to provider. SLA payouts are usually limited to 100% of one month of service fees, and may be limited to less. Liability, on the other hand, in most service provider contracts, specifically refers to a limitation of liability clause, which basically states the maximum amount of damages that can be claimed in a lawsuit.
It’s important to note that liability is not a new issue in the cloud. It’s an issue for all outsourced services. Prior to the cloud, any service provider who had their contracts written by a lawyer would always have a limitation of liability clause in there. Nobody should be surprised that cloud providers are doing the same thing. Service providers have generally limited their liability to some multiple of service fees, and not to the actual damage to the customer’s business. This is usually semi-negotiable, i.e., it might be six months of service fees, twelve months of fees, some flat cap, etc., but it’s never unlimited.
For years, Gartner’s e-commerce clients have wanted service providers to be liable for things like revenues lost if the site is down. (American Eagle Outfitters no doubt wishes it could hold IBM’s feet to the fire with that, right now.) Service providers have steadfastly refused, though back a decade or so, the insurance industry had considered whether it was reasonable to offer insurance for this kind of thing.
Yes, you’re taking a risk by outsourcing. But you’re also taking risks when you insource. Contract clauses are not a substitute for trust in the provider, or any kind of proxy indicating quality. (Indeed, a few years back, small SaaS providers often gave away so much money in SLA refunds for outages that we advised clients not to use SLAs as a discounting mechanism!) You are trying to ensure that the provider has financial incentive to be responsible, but just as importantly, a culture and operational track record of responsibility, and that you are taking a reasonable risk. Unlimited liability does not change your personal accountability for the sourcing decision and the results thereof.
In practice, the likelihood that you’re going to sue your hosting provider is vanishingly tiny. The likelihood that it will actually go to trial, rather than being settled in arbitration, is just about nil. The liability limitation just doesn’t matter that much, especially when you take into account what you and the provider are going to be paying your lawyers.
Bottom line: There are better places to focus your contract-negotiating and due-diligence efforts with a cloud provider, than worrying about the limitation-of-liability clause. (I’ve got a detailed research note on cloud SLAs coming out in the future that will go into all of these issues; stay tuned.)
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
Lydia-thanks for your thoughtful piece. I very much enjoyed working with your colleague Drue on the Cloud Law and Order panel at the Catalyst conference in late July (the article you read, quoted in your blog post, was based on that panel presentation). I agree with you that it would be be unreasonable (well, usually but not always) for a customer to expect to obtain “unlimited liability” in connection with most contracts for cloud services. But what I said at the conference is NOT that companies should insist on unlimited liability. To the contrary, what I said (quite consistent with the quote in the first paragraph of your blog post) is that potential cloud enterprise customers should be prepared to walk away from a deal if a cloud provider is UNWILLING TO NEGOTIATE on liability terms. If a cloud provider insists on a blanket limitation of liability (say the spend on a contract in the prior 12 months) and a customer’s risk associated with a potential data breach far exceeds that fixed amount, a cloud customer should be prepared to talk to other cloud providers, who might offer more in the way of indemnification for a security breach (some really do), or might consider avoiding the cloud for now. That is a risk assessment that the customer should undertake, whether in traditional outsourcing or the cloud. One way a cloud customer can get a rough (but underestimated) sense of the risk (a method I cited during the panel presentation with Drue) is to look to the Ponemon Institute’s current study showing that a security breach costs an organization approximately $204 per record compromised. That figure does not take into consideration all of the reputational harm to a company associated with such a breach, but it is a start. I think it would be “foolish and unrealistic” for any company to consider placing sensitive employee or customer data with a third party cloud provider that simply refuses to negotiate on liability. Many companies simply won’t use the cloud for sensitive data if the risk is too high and the cloud provider refuses to even discuss the issue, or they will take their business to the competition out there that will negotiate.
Thanks for the thoughtful and detailed clarification.
We’re actually talking about slightly different things — security breaches vs. outages. But I agree with you nevertheless.
It’s fairly common for outsourcers to accept no liability for security breaches unless it’s specifically a portion of the infrastructure that they protect — for instance, if they manage the firewall, they’ll accept some liability for any breaches related to compromising the firewall, but if there’s a compromise due to the customer’s application code, they are not responsible.
Moreover, data-breach SLAs are very unusual today, in infrastructure outsourcing deals in general. Cloud providers are actually on the leading edge of this, particularly on the SaaS side of the world. I agree that there should be both financial-penalty-backed SLAs as well as a limited-liability clause around security for not just cloud deals, but outsourcing deals in general.
I recently tackled this issue myself (in a piece that Tanya and I subsequently discussed), but I come at it from a slightly different point of view. I agree that prospective cloud users should attempt to negotiate contracts — and, if necessary, walk away from deals until they find an accommodating provider — but the reality is that the delivery model of cloud services akin to Amazon EC2 simply does not lend itself to negotiation over provider liability. After all, we’re not dealing with an arms-length transaction.
When a provider is serving millions of users who sign up anonymously via a simple web transaction, it can’t possibly negotiate with every user, and it would be imprudent to willingly accept liability when a single outage or breach could result in countless lawsuits. Users need to accept cloud computing a la Amazon EC2 for what it is — a fast, convenient and cheap source of computing resources. Whether it meets their needs around data security or availability — or whether the risk is worth the reward — is a personal choice. It appears Eli Lilly wasn’t comfortable furthering its use of EC2 under the current Terms of Service, so it made the right decision by maintaining the status quo.
Until we see a legal challenge to cloud computing terms of service, or until general-purpose cloud providers decide they are willing to do what it takes to win security/availability-concerned customers, I wouldn’t expect to see anything change.
I have to agree with Tanya, liability has to be negotiated…and is a bigger issue than this blog leads people to believe. Today, liability is negotiated as part of enterprise cloud service contracts and growing all the time. Just ask Amazon. In fact, Dervish Tayyip — chief legal counsel for Microsoft — said at Catalyst EU that “liability will become a competitive differentiator in the cloud”. Meaning: providers who can negotiate liability will have a competitive advantage over those that don’t or can’t.
Here’s the real deal: In cloud computing, liability has to be shared by both the provider and the consumer. Why? Because if the provider assumes all of the liability in a multi-tenant, pay-as-you-go environment, the provider’s liability can grow so quickly that they would never be able to afford the premiums for insuring that liability and the liability on the provider’s infrastructure could grow to more than the value of the company (a bad thing for business).
If the consumer were to assume all the liability, then consumer’s won’t place their most critical applications in the cloud because essentially, the consumer is “self insuring”. if the consumer has to “self insure” then many customers would rather keep their most critical applications in house or at least where they have some control over the environment because then we have reasonable accountability. If a consumer places a critical app in the cloud, and the cloud provider assumes no liability, then the accountability for any failure, breach, etc falls back to the consumer.
The first question everyone asks is “How is the liability different than hosting or outsourcing?” Well, there are a couple of ways. First is control. Outsourcing has many forms, but in some cases, companies maintain control of a portion of the infrastructure. In cases where they don’t maintain control of the infrastructure, companies almost always have the ability to inspect and review the outsourcing environment on a regular basis…and request changes. Not so in the cloud. Second, cloud introduces chained liability, which outsourcing typically doesn’t. have IOW — a cloud provider might be using additional cloud providers underneath his cloud. This introduces a chain of liability that any consumer can hold liable but is darn hard to do. Last, and probably the most important is, the outsourcing model was made to deal with liability by building liability into the price. Hosting typically involves a long term contract that guarantees the hosting provider millions of dollars in revenue over time. Thus, hosting companies covered their liability through assured profitability. The cloud business model is different.A cloud provider isn’t assured a consumer’s long-term business. Consumers can come and go in an instant. However, if a consumer wants the provider to assume some liability, the consumer must be wiling to enter into an enterprise agreement. IOW — if the consumer is willing to spend enough money and assure the provider of longer term revenue, then the provider will negotiate liability.
It is true that hosting provider contracts are not completely different than cloud providers in terms of denying liability. But, I think IT has learned it’s lesson on from hosting providers. IT now realizes that they accepted too much liability from providers. However, just like cloud providers are doing today, hosting providers DID negotiate liability in contracts. Check it out.
One of the ways for the customer to protect itself against lost business from an outage such as American Eagle Outfitters and now the State of Virginia, is to ensure they have business interruption insurance. It is part of P&C coverage in the US. Obviously, you have to ensure your policy includes coverage for 3rd party service providers. This insurance is SOP for business continuity management practitioners.
Good comment! You’re right. Consumers can buy cyber risk insurance from companies like The Hartford, Chartis, Marsh, Beazley, etc.
The fact that these policies exists reinforces the point that liability is a cloud issue we must face.
Hosting providers (and outsourcers) do negotiate liability, as do many (but not all) cloud providers. The real question is to what the limits of that liability should be, and also if the limitation-of-liability clauses in the contracts will hold up if damages are determined by trial.
Most cloud click-through agreements today have a limitation of liability clause that is based on some multiple of what the customer has paid. Most cloud enterprise agreements (i.e., traditional contracts that define custom terms for pay-for-use services) have similar limitations of liability, and like all contracts, may be subject to negotiation. But what I haven’t seen, broadly, is accepting liability based on the customer’s potential business losses — for this, other instruments, particular insurance, are used instead, and that insurance is bought by the company and not the service provider.
Cyber risk insurance is different from business interruption insurance. What I protest though for any 3rd party service provider is that the penalties or liability levels are limited to fees reimbursement. ESPECIALLY for cloud service providers. IF the customer and SP contract for a certain level of recovery and the SP doesn’t meet it, then fees compensation is a drop in the bucket for potential business loss. That they rely on the customer’s business interruption insurance – by design or ignorance – doesn’t square with me.