It's always a good idea to ensure the quality of service your business continuity/disaster recovery programs provide by establishing service-level agreements (SLAs). Likewise, if your BC/DR program depends on the provisioning of specialized services, such as a hot site or collocated data center, SLAs are essential tools to ensure that the services you obtain are acceptable.
Service-level agreements apply to internal departments, as well as outside vendors and service firms. In addition, service-level agreements should be part of any IT program involving the provisioning of products or services.
Having a service-level agreement is vital for the provider and the customer. It is a contract that sets clear expectations for both parties, and benefits go both ways.
As you'll see in our free service-level agreement template, creating an SLA presents the opportunity to go into great detail on what is required from the service provider. Many SLAs include specified financial penalties and remedies if performance or response time is unacceptable, which can be used to hold vendors accountable.
Types of service-level agreements
Service-level agreements are used in a wide variety of IT fields. IT service providers, cloud computing providers, network service providers and corporate IT organizations create SLAs with customers to establish expectations and even create a comparison with competing vendors.
There are three general types of service-level agreements:
- A service-based SLA is for a service, and it sets the same parameters for all customers using that service.
- A customer-based SLA is based purely on the agreement between the provider and the individual customer. It covers all services being provided to that customer.
- A multilevel SLA focuses on the corporate level, and it is applied to all users in the customer organization. This type of SLA is used to avoid duplicate or conflicting agreements across the company.
Components of a service-level agreement
A comprehensive service-level agreement usually has most or all of the following components:
- description of services to be provided;
- scope of the services;
- location(s) where services are to be provided;
- responsibilities and duties of the service provider;
- responsibilities and duties of the service recipient;
- description of acceptable performance levels;
- metrics to be used for evaluating performance;
- process for monitoring, tracking and evaluating performance;
- process for resolving poor performance;
- remedies for failure to provide acceptable performance, time frames and escalation procedures;
- protection of intellectual property, as applicable;
- compliance with legislation, standards, regulation and acceptable practices; and
- termination of the agreement.
A service-level agreement can cover broad-based or precise requirements for service provisioning. Most importantly, the parties in the SLA must agree on what is to be provided, the metrics to be satisfied (e.g., the time frame needed to provide service, the percent of successful vs. unsuccessful delivery of service), the method of monitoring and reporting service delivery, and remedies for failure to satisfy SLA requirements.
What services are appropriate for service-level agreements?
Let's briefly review examples of services that ought to have service-level agreements in place. On an internal basis, a BC/DR program might require the following:
- Satisfaction of agreed-upon recovery time objectives (RTOs) in the event of a disruption, e.g., certain systems are restored within eight hours of the disruption.
- Satisfaction of agreed-upon recovery point objectives (RPOs) in the event of a disruption, e.g., data being used can be recovered to within 0.25 hours of the disruption.
- Completion of one risk assessment for each business unit per year.
- Completion of one tabletop exercise for each BC/DR plan annually.
- Review and update of business impact analysis data annually.
Further, service-level agreements are particularly desirable for externally provided services, such as:
- Hot sites, particularly how quickly the organization has access to its agreed-upon hot site resources upon declaration, such as eight hours or 24 hours.
- Recovery of network connectivity to the internet following disruption of local access facilities, such as within four hours.
- Time required to fail over from primary to backup servers, such as one hour.
- Time required to recover and restart downed systems via a cloud-based recovery service, such as one hour.
Disaster recovery metrics and SLAs
To evaluate performance, benchmarks or tier one and tier two metrics must be in place. High-level BC/DR metrics are called tier one.
By contrast, tier two metrics are often more detailed and granular than tier one, and are typically found in technology-focused disaster recovery plans. Many of these are based on BC professional practices as defined by the "Business Continuity Institute (BCI) Good Practice Guidelines" and "DRI International's Generally Accepted Practices."
Key parts of the SLA process include the provisioning of metrics, the agreement to them by all parties, a process for monitoring the provisioning of service against the metrics, as well as a process for evaluating performance and resolving SLA violations.
Reviewing the service-level agreement
As with any kind of legal document, your organization's legal department should review and approve the service-level agreement before it's signed. Depending on how the SLA is structured, it can protect your organization, the service provider or both.
When reviewing an SLA, make sure customer requirements and service provider requirements are covered. As a customer, you'll likely want an SLA to ensure that your service provider delivers products and services according to a set of agreed-upon expectations. Downtime and uptime requirements are common concerns for customers, and they should be included in the agreement.
The service provider may require a customer to take steps to protect any intellectual property made available to them. Service providers may also designate circumstances where they are not liable to meet performance requirements, such as outside circumstances (fires, natural disasters) that damage the provider's equipment or cause an outage.
Free service-level agreement template
Don't be surprised if most of your vendors have their own service-level agreement template. If they are proactive about SLAs, it's probably a good thing, as it suggests they take the provisioning of service seriously.
If a vendor seems reluctant to accept your desire for an SLA, it's probably a strong clue that their performance may not fulfill your expectations. The best strategy is to have your own SLAs in place, review the vendor's SLA, make your decision as to the way to go and have your legal staff review everything before signing.
Watch out for unexpected disaster-recovery-as-a-service costs
Crafting a cloud DR plan
What's the difference between a service-level objective and a service-level agreement?