How do you evaluate cloud service agreements and SLAs? Very carefully.

Checking the contract details for cloud services can be messy, boring as tooth enamel, and a seemingly thankless job. But don't overlook the details. Mistakes have painful consequences.

Whenever a company depends on a vendor, both parties need a contract to set expectations and identify remedies when those conditions are not met. That rule applies to traditional IT and is even more important in a hybrid cloud environment, where so many services (and people) depend on one another.

Cloud service agreements (CSAs), service-level agreements (SLAs), and other contracts exist in a continuum from simple to sophisticated. They all need to be in sync and orchestrated to ensure an agreed-upon quality of user experience. It pays—financially and otherwise—to take the time to evaluate who is responsible, what you can negotiate, and how to extricate your company from a relationship if necessary.

Stirring the alphabet soup

As cloud services have matured, the terminology has changed. Let's start by getting our terms straight.

Over the past three years, SLAs have largely been replaced by CSAs. The CSA references the overarching agreement established between customer and provider. A CSA typically is comprised of three documents: an acceptable use policy (AUP), a customer agreement, and an SLA.

The customer agreement describes the relationship between the customer and provider, including explicit definitions of the roles, responsibilities, and execution of processes. It also spells out pricing and other business terms.

AUPs detail acceptable, as well as prohibited, use of the service, platform, or infrastructure. Because they tend to deal mainly with illegal use, AUPs typically generate the least amount of concern—but don't make assumptions. For example, if your business sends many online newsletters, an AUP prohibiting mass email should clarify how the provider defines mass email.

The SLA is thus one piece within the broader CSA. SLAs specifically address service levels and acceptable thresholds for service delivery, such as performance, uptime, and serviceability, including the ability of the firm's technical support to configure its tools, debug faults, and provide maintenance. It specifies financial penalties in the case that thresholds are not met.

Get the Forrester report - The Proliferation of Hybrid Cloud: A Look at Current Global Hybrid Trends and Approaches

These documents may go by different names because cloud service providers frequently change their terminology, contract terms, and structure. For examples of typical CSA and SLA content, the vendor-agnostic Cloud Standards Customer Council (CSCC) offers several useful documents. The most relevant include the Practical Guide to Cloud Service Agreements V2 and Public Cloud Agreements: What to Expect and What to Negotiate V2When CSAs are well written, they can significantly help avoid conflict. After all, if both sides understand what they agreed to, it's easier to resolve matters before a dispute becomes heated. But as with any contract, vendors' lawyers serve the vendor first. Pay attention.

IaaS, PaaS, or SaaS: Know your aaS

Infrastructure as a service (IaaS) is the foundation for other cloud services, including virtual servers, firewalls, virtual LANs, and so on. Platform as a service (PaaS) is IaaS with a software development stack added. Software as a service (SaaS) is applications that run in the cloud; these can be either enterprise proprietary or third party. Third-party products are typically monetized by usage-based subscriptions. The metrics used by SaaS, PaaS, and IaaS service providers need to be relevant for your own IT shop and your internal or external customers. It's not unusual to encounter a disparity between service provider metrics and customer needs. For example, SaaS customers need acceptable metrics at the application level. But a lot can go wrong for a SaaS customer, including issues related to data, server uptime, storage, and networking. SaaS cloud service providers know this; their lawyers write CSAs so that the SaaS provider is responsible for as little as possible.

IaaS providers, with their easily identifiable set of responsibilities, may be clearer about promised service levels. With services including storage, compute, networking, and security, the definitions are clearer. IaaS SLAs typically are stringent, non-negotiable contracts that limit the vendor's liability; they put the onus on the customer to prove an SLA violation and to argue for credit. You can either sign it or look elsewhere. "Typically, the bigger providers won't sign customer-originated documents as part of their agreements, so those customers will have to go with second- or third-tier providers," says David Linthicum, senior vice president at Cloud Technology Partners.

PaaS, which serves both enterprise development operations and production needs, has its own set of issues. Customers typically are responsible for business processes, applications, and their data, with the PaaS provider's responsibility line ceasing after runtime issues. That doesn't leave a lot of room for provider support when things go south. "PaaS is kind of a weird animal. It's way more analogous to IaaS than SaaS," says Linthicum. "Because it's a development platform, you have to put in limitations [in the SLA] as to its use, and you have to ensure safeguards are in place to make sure no one steps too far out of bounds." For example, a customer might take more resources than necessary, running the system into the ground by saturating the processors.

In some cases, you may need to examine the SLA for products that have elements of all three service models. Steven Woodward, founder of Cloud Perspectives, is a participating member of CSCC. Woodward, who contributed to the CSCC guideline documents referenced earlier, uses Salesforce as an example. "You might buy Salesforce Travel, which is SaaS. However, when you do your customization coding, you're using its Force.com product, which is PaaS. The underlying IaaS for Salesforce is there but largely hidden."

So who is responsible at each point? Woodward says, "Typically, the cloud service provider offers management services at or below the service responsibility line (SRL) [see diagram] as part of the standard cloud service offering. The customer is usually responsible for the elements that are above the SRL." Woodward notes that hand-offs, overlaps, and gaps between systems and service providers are defined by governance and service levels for the hybrid IT cloud environment.

Credit: Cloud Standards Customer Council, 2016

What IT and business folks need to care about

Who should be involved in reviewing cloud procurement agreements? More people than you'd think. The business customers and end users who consume SaaS products need to participate in the process to ensure the product meets their needs, and IT expertise helps identify issues—such as corporate governance requirements—that business customers might miss. PaaS users are typically developers and testers, so they need to be in the procurement loop for those decisions, particularly technical elements of the SLA. The operations group should be at the table for IaaS analysis and procurement.

Expect overlap in cloud services and thus in the evaluation process. Few enterprises were born "cloud first," which is one reason so many adopt a hybrid approach to cloud and on-premises IT systems and resources.

One of the few existing examples of an "all-in" cloud approach is Drybar, a blow-dry hair salon franchise with 75 existing franchises and another 25 opening by the end of the year. Steve LaBrie, its CIO, says, "We haven't had an on-premises server since I got here. It was an interesting opportunity to build something entirely cloud for a company that was growing quickly and had the resources to build correctly."

The public cloud is not necessarily the right answer for all workloads. Some enterprises are "de-clouding," or moving certain applications from the public cloud to private clouds or traditional IT, for reasons that include security, cost, and manageability. Obviously, this was the right path for Drybar, and thus it needed to ensure its cloud platforms (and SLAs) matched the company's needs. LaBrie looked for systems that had robust API connectivity, so he could hook together custom applications. LaBrie chose multi-tenant cloud systems, including NetSuite, some SaaS products, and Amazon Web Services as a platform.

Hard lessons to learn

Data accuracy. Data security. Data recovery. The cloud provider's data policies contained in the CSA are the most crucial pieces of the contract for business stakeholders. Go over these points with a fine-tooth comb to ensure they meet and protect your needs as a customer.

"Mostly we live with the SLAs we get, but frankly we try to negotiate where we can," says LaBrie. "We have a great legal department. Typically, the cloud provider won't negotiate uptime, so we focus on the critical security aspect. We have our own security addendum that we require any company we work with to sign." Drybar has implemented both single sign-on and two-factor authentication. He makes sure that vendors agree to support his company's security processes. 

Some larger cloud-based providers may be willing to work with you on customized addendums like Drybar's. "Spell out who's responsible for breaches like cross-tenant breaches, where bad actors are getting into the root operating system," suggests Linthicum. He thinks the cloud provider should be responsible. Larger enterprises need to leverage the law of tonnage to negotiate multiyear contracts with bigger providers, pushing more of the risk back on the provider.

It's also important to ensure that you have redundant means of Internet access, providing a way to store and forward data, sales transactions, and the like in case your primary access goes down.

Breaking up is hard to do

Divorce happens. Whether it's because your provider was acquired, merged, goes out of business, or fails to deliver services as contracted, the change of relationship affects your company. Be sure the CSA explicitly addresses how your data will be handled and delivered back to you, how long it will be kept, and when it will be destroyed. "The first and foremost thing that needs to be clear in a CSA is how the customer will egress their data out of the system," says Linthicum. He advises his clients to keep a replicated portion of their data somewhere not in the cloud, in off- or on-premises storage, or they could get stuck holding the (empty) bag. "It doesn't matter if they violate your contract or go bankrupt; there's not much you can do, so replicate your data nightly."

Most cloud SLAs offer only service credits against future service and don't give refunds. Credits from a dicey provider against future billing are of no benefit to you, so limit your exposure if these start to mount up. Try to hedge your bets going into the relationship and negotiate refunds into your contract.

CSAs will eventually become more favorable to customers, offering better terms and more flexible options as the larger customers stand firm and negotiate and competition increases. In the meantime, the shrewd play is to heed Dirty Harry's advice in "Magnum Force": "A good man always knows his limitations."

Cloud service agreements and SLAs: Lessons for leaders

  • Make sure your data is protected in all situations.
  • Negotiate refunds instead of service credits.
  • Have an iron-clad exit strategy that protects your IT and business concerns.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.