The IT Law Wiki

Service level agreement

32,060pages on
this wiki
Add New Page
Add New Page Talk0

Definitions Edit

A service level agreement (SLA) is

a contract between a service provider and a customer that specifies the nature of the service(s) to be provided and the level(s) of services that the provider agrees to provide to the customer.
[a]n abbreviated service agreement stating the technical performance promises made by a provider, including remedies for performance failures. An SLA is composed of three parts. The first part is a collection of promises made to subscribers, (2) a collection of promises explicitly not made to subscribers, i.e., limitations, and (3) a set of obligations that subscribers must accept.[1]
a formal negotiated agreement between two parties. It is a contract between customers and their providers, and it should document a common understanding about agreement features such as priorities, responsibilities, and guarantees. Key objectives of SLAs include reducing areas of potential conflict and encouraging issue resolution before a dispute materializes. SLAs typically are governed by a master agreement (e.g., a contract or 'Terms of Service'); in the event of conflict between the terms of SLAs and the master agreement, the master agreement typically prevails.[2]

Overview Edit

The SLA ensures that the organization receives the services it wants at the expected performance standard and price. As such, the SLA is a key component in managing the financial and operational risk involved with outsourcing contracts. It also can be one way to help mitigate risk. By specifying the measurement unit and service range for the selected category, the risk of poor service may be diminished because it becomes an area of focus and is designated as the service provider’s responsibility.

The SLA's primary purpose is to specify and clarify performance expectations, as well as establish accountability. Therefore, balancing the need for precise measurement standards with sufficient flexibility is important. A common pitfall is excessive oversight or "micro-management" of the provider responsible for the service, which can also burden the employees charged with supervising the service provider relationship and monitoring the SLAs.

As a best practice, SLAs should clearly define how performance is guaranteed (such as response time resolution/mitigation time, availability, etc.) and require CSPs to monitor their service levels, provide timely notification of a failure to meet the SLAs, and evidence that problems have been resolved or mitigated. SLA performance clauses should be consistent with the performance clauses within the contract.[3]

A well-designed SLA will recognize and reward, or at least acknowledge, good service. It will also provide the measurement structure — or performance metric — to identify substandard service and trigger correction or cancellation provisions as warranted. Incentives or penalties in the SLA can be an effective tool for managing service. If services received do not measure up to expectations, direct consequences, such as reduced levels of compensation or a credit on future services, would result.

"SLAs must be applied consistently, maintained, and updated throughout the contract period of performance to ensure that performance objectives are achieved effectively. All SLAs supporting a particular effort should be managed collectively, and interdependencies should be identified and managed. To form a 'meeting of the minds' between parties who may have competing agendas, SLAs should not be applied exclusively as a transactional and computer-generated communication of performance. SLAs also should be applied as a mechanism for managing how the provider and consumer are expected to communicate and coordinate with one another. . . . To ensure that SLAs are enforceable, they should be formalized at the same time as the governing contractual documents are created, negotiated, and approved."[4]

"In the current commercial cloud computing market, offeror fixed SLAs are the most prevalent. Some SLAs can be negotiated within advertised bounds. Potential government consumers of the first two categories of SLAs should evaluate the SLAs against their requirements and understand any gaps and associated risks. It is important to evaluate providers and decide on a best fit. A "best fit" may not be achieved initially, and consumers may need to change providers or performance management approaches. Alternatively, consumers may negotiate their SLAs. Fully negotiable, Customer-Driven SLAs are rarer, but are available to Government organizations that have unique requirements and sufficient funding to procure the capabilities. SLAs for these types of offerings are not as visible in the public domain as providers' standard SLAs, but they are important tool for acquisitions organizations to consider."[5]}}

Structuring and developing SLAs Edit

A typical SLA includes the following components and is tailored to fit the nature of the outsourced service or application:

  • Service category (e.g., system availability or response time).
  • Acceptable range of service quality.
  • Definition of what is being measured.
  • Formula for calculating the measurement.
  • Relevant credits/penalties for achieving/failing performance targets.
  • Frequency and interval of measurement.

Before an SLA is signed, the service provider and the customer should clarify and establish expectations. Unless these expectations are clearly measurable, the service category will be difficult to manage due to the customer's and the vendor's differing goals and perspectives.

The key components of any solid SLA should contain specific, measurable and enforceable terms and conditions that the [service] provider must adhere to for each component of the service provided. If the provider fails to meet an obligation under the SLA, the SLA must have the 'teeth' to help mitigate such failure from happening again. The 'teeth' to SLAs are the specific remedies that apply when the provider's obligations are not met. The remedies usually take the form of monetary damages that are pre-agreed between the parties for specific failures and/or credits for future services.[6]

Issues Edit

Issues that are typically addressed in an SLA include:

References Edit

  1. FG Cloud Technical Report, Part 1, at 4-5.
  2. Cloud SLA Considerations for the Government Consumer, at 2.
  3. Creating Effective Cloud-Computing Contracts for the Federal Government: Best Practices for Acquiring IT as a Service, at 8.
  4. Cloud SLA Considerations for the Government Consumer, at 2.
  5. Cloud SLA Considerations for the Government Consumer, at 3.
  6. Best Practices for Negotiating Cloud-Based Software Contracts, at 11..

Source Edit

  • FDIC, Tools to Manage Technology Providers’ Performance Risk: Service Level Agreements (full-text).

See also Edit

Also on Fandom

Random Wiki