Service Level Agreements (SLAs) are enterprise life lines on the Internet. CIOs cannot plead ignorance of the clauses. First, the SLA is often written in plain English, and second, the SLA represents the “consensus” reached between the contracting parties. A focus on the SLA is an imperative; a necessity. So, what does one look for in an SLA?
This paper purports to help readers focus on SLAs for Cloud services and understand the what, why and how of it.
Table of Contents
- Introduction
- Definition of Services
- Performance Measurements
- Problem Management
- Customer Duties – Roles and Responsibilities
- Warranties and Remedies
- Disaster Recovery and Business Continuity
- Security
- Termination of Agreement
- Conclusion
- Introduction
CIOs can not plead ignorance of the clauses in the SLA if enterprise data suddenly vanishes into cyberspace! SLAs are often set out in plain English and a focus on the SLA is an imperative; a necessity for the survival of the organization in this digital age. A focus on the SLA, an understanding of the provisions and sections of the document is a must.
Service level agreements are formal, legally binding documents that are drawn up by the contracting parties. They formally set out the level of service that will be provided by the contractor under the terms of the contract. All Cloud services providers include SLAs that detail the level of service that will be provided for the duration of the contract.
A service level agreement is an “agreement”. It signifies consensus between the contracting parties. It assumes that there is a common understanding about services, guarantees and warranties, responsibilities and priorities. It defines levels of serviceability, availability, operation, performance or other attributes of the service, including billing. It details where and when a customer can expect “minimum” service and how it can be measured or what the target value is.
A few contracts may even contain clauses detailing penalties for failure to meet minimum expected levels of service. To get the right level of service, customers must examine the different sections of the service level agreement in detail.
At a minimum, a typical Cloud service level agreement includes the following sections:
- Definition of services
- Performance Measurements
- Problem Management
- Customer Duties
- Warranties
- Disaster Recovery and Business Continuity
- Termination of Agreement
- Definition of Services
Cloud Service SLAs, like all utility service SLAs are output based. By this, we mean that the level of service that will be provided to the customer is defined in measurable terms. The service provider demonstrates value to the customer by expounding how knowledge, capability, and ingenuity are innovatively organized to deliver the requisite output or service to the customer. This emphasis on the delivery mechanism shifts the risk to the service provider.
The definition of services under the SLA may vary according to the type of service, the type of organization and the needs of the organization. A corporate level SLA may provide generic services to all parts of the enterprise. Multi-level SLAs may split services so that the service provider can cater to the specific service needs of different parts of the organization. Customer level SLAs may provision for services relevant to a particular industry. Service level SLAs may cover specific service requirements of specific service groups.
SLAs may offer layered services. The service provider may define the basic package(s), that will be made available at different prices. Customers can select from a list of “add-ons” (at pre-defined costs) or other specific features that they would like to include in their package. For instance, the basic package may offer the customer 2 GB of space for storage. The customer may choose to “add-on” additional storage by signing up for 20GB of space. The service user may also opt for an email system for the entire organization in addition to the other services being offered as part of the regular package.
All terminology proposed to be used in the SLA are also set out and explained in this section of the document.
- Performance Measures
That which is not monitored is not done. SLAs are drawn up to ensure that Cloud service delivery performance can be measured and the customer has the ability to monitor the performance of the service provider on the basis of a pre-defined set of standards and norms. The service provider also commits to a minimum level of service under this section of the SLA and has the opportunity to define the standards and norms that are to be used to evaluate the performance of the service delivery. For instance, “latency” is a term that describes the time taken for data to be recovered to the client machine from the storage server in the Cloud. “Uptime” is a measure that helps both the customer and the service provider understand whether the services are being delivered as promised. Uptime is usually expressed in 9s. As a client, one needs to think thoroughly on the level of uptime. Uptime can be incorporated with much accuracy by determining the number of 9s in the SLA. For example, the table below shows the co-relation between the number of 9s a client might target and the duration of downtime, which may vary from 5 minutes to over 36 days in a given year.
If your availability target is a mere 90%, there will be 36.5 days of downtime in a year (i.e. 10% of 365 days). If, however, your availability target is 99.999% (dubbed as five nines), then you will only have about 5 minutes of downtime in the entire year!
| Availability Target | Downtime Per Year (Approx.) |
| 90 percent | 36.5 days |
| 99 percent | 3.65 days |
| 99.9 percent | 8.8 hours |
| 99.99 percent | 52.6 minutes |
| 99.999 percent | 5.3 minutes |
Table: Comparison of Downtime Vs Availability Target, using “one to five nines”
- Problem Management
This section of the SLA focuses attention on problem-handling systems integrated into the service. The purpose is to minimize the impact of events, incidents, and problems on the customer’s business. For instance, the Cloud vendor may provision for alerts to be generated whenever a backup or recovery fails or unauthorized entities attempt to access the data. The SLA may detail error handling procedures and set out escalation protocols for handling unexpected problems. Time frames for the resolution may be specified. Stipulations may include activation of audit trails and maintenance of logs and records for all types of incidents that may cause failures in delivery of service.
- Customer Duties – Roles and Responsibilities
The SLA is not a one-way street. The Cloud vendor has some expectations from customers. The service will work effectively only if the organization collaborates regularly with the vendor for technical and support contract issues. The organization must clearly indicate and designate the license administrator. The administrator is responsible for receiving and administrating the software product licenses, updates and upgrades and payment of all bills due or assigning rights and permissions to other users, who are authorized to access the online storage account. Though they may appoint secondary administrators in multi-level contracts, all secondary administrators must report to the primary administrator, who must remain a single point of contact for the Cloud vendor.
- Warranties and Remedies
The Cloud vendor provides the user details of any warranties and remedies under this section of the SLA. This is perhaps one of the most important sections for the customer. The warranties may cover service quality, indemnities, third party claims, remedies for breaches, exclusions and force majeure.
- Disaster Recovery and Business Continuity
Recovery is the raison d’etre for online Cloud backup and storage. The Cloud vendor describes in this section, the disaster management protocols that have been put in place by the company to safeguard against disaster.
The disaster recovery and business continuity guarantees may broadly include:
- Provisioning of geographically dispersed servers for safeguarding against natural disasters such as Tsunamis, earthquakes or tornados
- Continuous data replication or data mirroring to ensure high availability of information at all times
- Seamless failover systems
- Simultaneous creation of local copies of data using the Cloud vendor’s proprietary application even as data is being streamed to the online server over the Internet
- Provisioning for bare-metal restores to any part of the world
- Provisioning for data security with impregnable cryptographic modules, both during transmission and storage
- Security
This section of the SLA elaborates upon the security systems that the Cloud vendor promises to use. Any certifications obtained by the company for its cryptographic module or the type of encryption that is used (bank grade/military grade) is generally specified here. The encryption protocol may be used only for data in transition and not in storage or for both. If the vendor permits the customization of the encryption key, the fact will find a mention here with suitable warnings that the loss of the key could well mean the loss of data as the vendor does not retain copies of the customized keys.
Further, the vendor urges the customer to ensure that the user management systems provided is exploited to ensure that only authenticated and authorized personnel has access to data and enterprise policies are being adequately implemented through the interface settings.
- Termination of the Agreement
The last section naturally talks of when and how the contract can be terminated. The rights and responsibilities of the vendor and the customer are generally detailed in this section. Termination can occur at the end of the initial term, for convenience, and/or for a cause. However, whatever the type of termination, the vendor must undertake to delete all customer information from all primary and secondary servers in which the data has been stored. Some vendors even specify what they will do with the information that is stored by them in their archives and disaster recovery sites. Wherever interoperability of services is possible, the vendor may agree to transfer all customer data and applications to the new Cloud service provider.
- Conclusion
It must be reiterated that the SLA is a binding legal document. Both parties to the contract can enforce it and hence, it must be drawn up after both parties are satisfied that they have clarity on promises and expectations. Imperfect understanding on any side can lead to confusion, dissatisfaction and probable loss of business. Therefore, both parties must negotiate the different clauses before signing on the dotted lines and committing themselves to the contract.
In some cases, despite your due diligence, SLAs might not be met; and you won’t discover this until the unexpected happens and disaster strikes. Therefore, it is highly advisable that you understand and get comfortable with the SLA and that you anticipate disasters and plan accordingly. Sometimes, disasters are not fully understood; and administrators might define them vaguely. For instance, disasters that are defined as small instances may have just as big of an impact as the larger, less likely ones.
