Service Level Agreements form an integral part of many IT related agreements, and are often agreed upon between the customer and a Software (as a Service)- or cloud/hosting provider. Drafting (or validating) such Service Level Agreement requires both technical and legal expertise, and is essential for your organization both as a user or provider of software. In this blogpost we explain the key take-aways when it comes to Service Level Agreements.
Service Level Agreement: what is the importance?
Service Level Agreements (SLA’s) are typically agreements between the supplier and customer of a product or service (e.g. SaaS), in which particular aspects of the service (such as: quality, availability and responsibilities) are agreed upon. The main goal of a SLA is to provide certain service level objectives, that describe the agreed upon minimum requirements which the service needs to meet. Most of the time SLA’s form a part of the main agreement that describes the services delivered by the supplier. It is possible that these services are described in the SLA itself, but since cloud computing contracts tend to be very extensive contracts already, this is not recommended in order to promote clarity.
An example of an industry that uses these SLA’s a lot is web hosting. A company rents a web server will most likely be very concerned that this server is consistently accessible and performs well. Thus, an SLA will in this case determine how the server is maintained (e.g. updates), what percentage of the time it has to be accessible (often 99,9%) and when/how the customer is entitled to support. The importance of a SLA becomes apparent when it is not clear what will happen if one of the parties do not hold up their end of the bargain. It allows for transparency about what the service level objectives are as well as what happens if the required objectives are not met. With a service level agreement in place, both parties are protected.
Indispensable service objectives
Although it is possible that the SLA defines some responsibilities for the customer (e.g. a duty to report problems within a specified time window), it mainly describes performance goals for the supplier (e.g. network availability and response time). It is important that these performance goals or service level objectives are unambiguous, concrete and measurable in order for their compliance to be verifiable. The SLA has to be clear on its legally binding character. As such the kind of SLA we are talking about in this blogpost is a result commitment for the supplier, which may or may not be achieved, but where you can modulate the concrete consequences of not achieving.
The European Commission has set forth some SLA standardization guidelines as well as a model for cloud computing services and SLA agreements, which are not legally binding but nonetheless provide some useful guidance for companies. Some common/essential components of a service-level agreement may include:
Agreement overview – This first section sets forth the basics of the agreement, including the parties involved, the start date and a general introduction of the services provided. This section might also be included elsewhere, depending on the structure of the entire agreement.
Description of services – The SLA needs detailed descriptions of every service offered, under all possible circumstances, with the turnaround times included. Service definitions should include how the services are delivered, whether maintenance service is offered, what the hours of operation are, where dependencies exist, an outline of the processes and a list of all technology and applications used.
Support – Defines the levels of support to be achieved by the supplier. These are the maximum response times which the supplier must respect when answering assistance questions from the customer and or timeframes within which the software provider should provide a resolution for the incident occurred.
Service availability – The SLA will determine the level of availability, or uptime, of each of the IT services to be delivered, often in the form of a percentage. Additional clarity may be added by providing a definition of availability as well as the period of time over which the availability will be measured (usually on a monthly basis). It is also possible to use different levels of availability during and outside working hours and for weekends.
Service performance – Performance measurement metrics and performance levels are defined. The client and service provider should agree on a list of all the metrics they will use to measure the service levels of the provider.
Exceptions and exlusions – The SLA may also determine which service level inadequacies will be exempt from liability, such as force majeure, planned maintenance or acts/omissions of the customer. Also client induced incidents are often excluded, as the cause of the incident does not relate to the service provider itself. Specific services that are not offered should also be clearly defined to avoid confusion and eliminate room for assumptions from other parties.
Service tracking and reporting – This section defines the reporting structure, tracking intervals and stakeholders involved in the agreement.
Sanctions – Compensation or payment should be defined in the event that a provider cannot properly fulfill their SLA. Also other remediations can be included such as specific termination possibilities, penalty clauses, applicable discount rated or the issuance of service credits.
Periodic review and change processes – The SLA and all established key performance indicators (KPIs) should be regularly reviewed and evaluated. This process is defined as well as the appropriate process for making changes. For example, quarterly committee meetings might be a fit for purpose, depending on the project.
Dispute resolution – Description of the fact when mutual consultation takes place and what the procedure is in the event of mutual conflicts or disputes regarding the settlement and involvement of third parties. It is also important to mention the procedure that has to be followed, whether or not an independent third party will be involved (internal procedure/mediation/arbitration) and whether or not a decision of such a third party will be binding. When these methods don’t work, the conflict may be brought before a judge.
Stakeholders — Clearly defines the parties involved in the agreement and establishes their responsibilities.
Risk management, business continuity and disaster recovery — Risk management processes, business continuity plan and a disaster recovery plan are established and clearly communicated. These topics may also be included in separate annexes or policies and are not always included in the SLA as such.
Focus areas when drafting/validating your SLA
When drafting your SLA, there are some key-take aways to take into consideration in order to make sure the agreement fits your specific needs:
- As a customer it is important to ask the supplier about warranties. You want specific agreements related to service levels offered and want the follow-up of these service levels to be as convenient as possible (e.g. by automated measurement reports). Nevertheless, don’t request your provider to sign off to service levels which are not realistic. Take into account the service you are buying, and the actual service level you need. Otherwise this might extensively impact the pricing of the solution you are looking into.
- As a software provider it is important to define the service levels your are offering, exclude typical circumstances which do not trigger the service levels and make sure to include reimbursement of costs for client induced incidents which you assisted in to resolve. Additionally you may want to limit the consequences in case the service levels are not and to define the exact repercussions in such case (liability, service credits, etc.). In case you resell services of third party software vendors, do also make sure you do a back-to-back exercise on the service levels to avoid promising service levels which you cannot provide due to a third party dependency.
- For both parties, it is key to agree upon a clear service level agreement which is sufficiently descriptive and which can be used in the real world. Service levels should be discussed between both legal and technical/business stakeholders to make sure it is a fit for purpose.
Finally, SLAs must be made with a case-by-case approach and should not be copy pasted from a general checklist. Some articles (such as the ones mentioned above) may not apply or have to be added depending on the circumstances of the agreement.
If your require advice on your SLA or want us to draft one for you, we can offer specialized assistance.
Date: 14 August 2020
