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,
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
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.
Originally published on Canadian Lawyer Online - IT Girl Column
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.