 and level of service that a cloud service supplier must meet. Service levels are usually set out in the section of a contract known as a service level agreement, or SLA, which is also sometimes known as the cloud service agreement (CSA). Think of the SLA like the ground rules for the cloud service – a robust SLA can protect the stability of the cloud service, protect the customer’s access to data and minimise the expense of any required remedial action. And, if the supplier fails to meet the defined level of service, the customer will usually be entitled to some form of remedy, such as a service credit.
A fit for purpose SLA should contain the following three key criteria:
- Availability – uptime
- Data access
- Performance – response and fix times
While not always workable, a business customer should seek to customise the SLA or to negotiate the inclusion of additional provisions. As the market for cloud services becomes more competitive, it is common to see suppliers being more flexible when it comes to agreeing to bespoke SLAs.
1. Availability – uptime
From a commercial viewpoint, at the core of a cloud computing service contract is the customer’s right to access and use the service ‘on demand’. Given the nature of technology there may, however, be circumstances where the service becomes unavailable, which is sometimes referred to as ‘downtime’. Accordingly, the SLA should directly address the levels of availability or ‘uptime’ that the service provider is proposing to offer.
SLAs usually state the availability of the service to the customer in percentage terms eg 99.5% uptime. The manner in which the service availability percentage is calculated requires close attention from the customer. For example, an availability service level measured over a month compared to one measured over a year can have a significant impact on the calculation of service levels and payment of any service credits.
As cloud services becomes more complex and interconnected, when procuring a bundle of services, a customer may want to ensure that the SLA classifies the non-availability of a single service component as ‘downtime’. In turn, this should assist in assessing whether the guaranteed service levels have been met.
2. Data access
Customers should take care to ensure that the SLA clearly defines what is meant by ‘availability’ and that it covers access to data. For example, if a customer using a cloud storage service can access its data or files previously saved on the cloud but cannot upload new data, it is questionable whether the service is technically ‘available’. Software bugs or accidental deletion can also affect the customer’s ability to access its files. A savvy customer would ensure that this section of the SLA addresses data back-up, data protection and redundancy/disaster recovery.
3. Performance – response and fix times
The customer should consider the performance and support levels that the cloud supplier is offering, in particular, the response and fix times. Response and fix times are often tiered by priority levels, based on the severity of the service downtime, and are usually determined with regard to impact on the customer’s business. For this reason, it is important to ensure that the SLA contains suitable response and fix times so that queries or services most critical to the customer’s business are responded to or repaired with the appropriate priority and are not just aspirational ‘targets’.
Are service credits being offered?
Service credits are the primary financial remedy for a cloud provider’s failure to meet the agreed service levels. An SLA will often include a list of the service credits payable for different levels of service failure. Service credits are often calculated based on a percentage of monthly charges and may be subject to an overall limit or cap.
A customer may try to argue that service credits should be offset against its payment obligations under the contract. The net effect of this is that if a customer suffers downtime, the amount owed on the bill will be reduced.
A supplier will often try to 