Service levels can sometimes be the “orphan children” of a cloud transaction — often neglected and not given the attention they deserve.
Some technology lawyers are reluctant to review and comment on service levels, preferring to leave their negotiation to the client’s business or technical experts. However, lawyers can play a crucial role in vetting service-level agreements as part of creating an effective cloud arrangement.
While many cloud providers will be reluctant to negotiate customized service levels for specific customers in the absence of a large-volume public cloud deal or the acquisition of a private cloud solution, there are still ways to improve even the most vanilla of service-level agreements. The following tips are intended to help demystify service levels/service-level credits and include some suggestions for creating better service-level agreements.
Service levels are important
At their most basic, service levels are intended to compensate customers for a cloud provider’s failure to deliver cloud services to their promised levels, usually by way of service credits (providing customers with rebates against further billings). As service levels are not standardized, customers sometimes find it difficult to compare the offerings of various cloud providers. Depending on the nature of the cloud service, service levels can include measuring for uptime/availability, performance and response times, incident priority/correction times, etc.
Service levels are often made available in a stand-alone SLA separate from the cloud provider’s master services agreement, which may cause its own difficulties from a contract perspective. This SLA may or may not be hyperlinked to the cloud MSA and is often available on the cloud provider’s web site, allowing the vendor to amend it at will.
The onus is thus on the customer to monitor for changes. Regardless of where the SLA is to be found, in the cloud 2.0 world, almost every reputable vendor will offer basic service levels. The failure of a prospective vendor to offer even minimum service levels is a definitive “red flag” that should strongly signal that particular vendor is not right for your organization. At the same time, any cloud provider that offers a customer an overly generous service level or service credit, i.e., “10,000-per-cent service credit equivalent to 100 times the customer’s fees” on the service, is not to be trusted, either.
Ensure the SLA is understandable
Some SLAs are written so poorly or technically that their plain meaning is difficult to understand. While service levels and service credits can be complex, they still have to be intelligible. Start with the basics — what is the service level actually measuring? Will the cloud provider be monitoring the service for breaches of service levels or is it the customer’s responsibility to do so and to alert the vendor? Do the vendor’s proposed planned-maintenance downtime windows align with the customer’s requirements? What is the measurement period? If there is a formula/calculation to receive credits, does it make sense? While generally credits are calculated as a percentage of the fees (i.e., monthly fees) the customer has paid, where does the measurement begin? Is there a maximum credit cap? Are the exclusions clear? Focus on the key definitions, such as “availability”, “downtime”, “excluded downtime”, etc. If the language used by the vendor is not clear, demand clarifications as it is likely that a judge wouldn’t understand it either.
SLAs or SLOs?
When reviewing a proposed SLA, be careful to distinguish between service levels and service-level objectives. SLOs are essentially “aspirational” — often there are no repercussions if they are not met. Any aspect of the cloud service that a customer wishes to meaningfully measure must, therefore, be a service level with a definitive remedy for breach. Following any incident that affects performance, the cloud vendor should perform an analysis to identify the cause of the failure, provide the customer with a written report of the results of such analysis and the procedure for correcting the failure, and keep the customer informed of the status of the cloud vendor’s remedial efforts regarding such failure. Remedies should also start immediately following the first missed service level — unlike one vendor that stated that, in the first month of missed availability, the vendor’s sole commitment was to promise that “the parties would meet to discuss possible corrective actions.”
Watch for those carve-outs and “gotchas”
It is standard for SLAs to contain many “carve-outs,” including excluding the provision of emergency maintenance from “downtime” calculations (and often intermittent downtime does not count toward downtime calculations either). Most cloud providers will not take responsibility for factors outside their immediate control, including Internet routing, traffic issues affecting Internet links, third-party software, customer-provided software, or missed service levels due to force majeure events. However, what about jurisdictional limits? Should the cloud vendor be able to exclude meeting a service level because of system work at the request of customer, system shutdowns caused by customer customizations, or faults in the customer’s network, LAN, or firewall? What about “non-fulfilment or violation of customer’s duties of collaboration”? Be mindful of unreasonable exclusions and request their deletion if possible.
Review customer responsibilities carefully
Service credits often come with “strings” attached. Many SLAs now tie the provision of credits to a customer’s obligation to meet ever-increasing obligations. For example, a customer is obliged to notify the cloud provider via e-mail within a certain number of days of any claims for credits following an incident (and be obliged to provide such details as downtime information with dates and time period for each instance of downtime during the relevant period, and an explanation of the claim made under the SLA, including relevant calculations). Failure to do so within such period will result in forfeiture of any credits.
Many cloud vendors consider the responsibilities around the use of the cloud service to be “shared” and will withhold credits if a customer fails to meet its own obligations. These may include: misusing access rights, violating the cloud agreement or the acceptable use policy, or if customer’s use of the cloud service is not in accordance with the documentation for such cloud service.
Cloud providers have also refused to be responsible for failures to meet an SLA if the failure is caused by a customer declining to accept patches, configurations, or maintenance changes recommended by the cloud vendor. Consider, for example, whether your customer would be comfortable giving a representation that it can make the software hosted by the cloud vendor rightfully available to such vendor, or provide a representation that the customer’s data is virus-free, has been collected/supplied in compliance with applicable laws (including data privacy and export compliance laws), or that it changes its passwords at regular intervals?
Failure to comply with the above has led at least one cloud provider to deny its obligation to meet its stated service levels. It is now fairly common for many SLAs to state that the cloud vendor will not have responsibility to meet service levels if the customer is late with its payments or otherwise has monies owing to the cloud vendor. If your organization typically does not meet its payment schedules, it will be critical to ensure that you modify the cloud agreement’s standard payment terms so that your enterprise is not caught without a service-level remedy.
Negotiate termination rights
Most SLAs state that the provision of service credits is the customer’s sole remedy for breach of a service level/SLO and that failure to meet an SLO is not a material breach of the cloud agreement. This limitation can serve as an important disincentive to vendors as there will be no real penalty for continued service interruption. However, customers that continually experience ongoing intermittent outages or service-level failures will not likely wish to continue with a cloud vendor that has offered poor service, and even generous credits against future billing will be of little or no benefit if such customer now wants to switch providers following inconsistent service. A better approach is to draft in a requirement that repeated service-level failures measured over a period of months — i.e., failure to meet the same SLA within any rolling three- or six-month period — be grounds for termination.
To conclude, having robust service levels with actual credits involved for breaches of performance remains an important part of any balanced cloud-computing arrangement. As no two cloud vendors have the same offerings, careful review of the SLA prior to the deal should be part of the due diligence and negotiation process during the acquisition of mission-critical cloud services. If service levels are important to you or your clients, be certain to escalate their negotiation to the front of the deal rather than left as an after-thought.
Once the language in the SLA has been clarified, you must also ensure that your cloud contract/cloud service is governed by the updated version of the SLA rather than boilerplate version hyperlinked on the cloud vendor’s web site.
