Editing Service level agreement

== Definitions ==

A '''service level agreement''' ('''SLA''') is 

{{Quote|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]].}}

{{Quote|An 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.}}

{{Quote|a formal negotiated [[agreement]] between two parties. It is a [[contract]] between [[customer]]s 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.<ref>[[Cloud SLA Considerations for the Government Consumer]], at 2.</ref>}}

== Overview ==

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]] [[contract]]s. 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 [[employee]]s charged with supervising the [[service provider]] relationship and [[monitor]]ing the SLAs.

{{Quote|As a [[best practice]], SLAs should clearly define how performance is guaranteed (such as [[response time]] [[resolution]]/[[mitigation]] time, [[availability]], etc.) and require [[CSP]]s to [[monitor]] their [[service level]]s, provide timely [[notification]] of a failure to meet the SLAs, and evidence that problems have been [[resolve]]d or [[mitigate]]d. SLA performance clauses should be consistent with the performance clauses within the [[contract]].<ref>[[Creating Effective Cloud-Computing Contracts for the Federal Government: Best Practices for Acquiring IT as a Service]], at 8.</ref>}}

A well-designed SLA will recognize and reward, or at least acknowledge, good service. It will also provide the measurement structure &mdash; or [[performance metric]] &mdash; 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."<ref>[[Cloud SLA Considerations for the Government Consumer]], at 2.</ref>

"In the current commercial [[cloud computing]] market, offeror fixed SLAs are the most prevalent. Some SLAs can be [[negotiated]] within advertised bounds. Potential government [[consumer]]s of the first two categories of SLAs should evaluate the SLAs against their requirements and understand any gaps and associated [[risk]]s. It is important to evaluate providers and decide on a best fit. A "best fit" may not be achieved initially, and [[consumer]]s may need to change providers or performance management approaches. Alternatively, [[consumer]]s 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 [[acquisition]]s organizations to consider."<ref>[[Cloud SLA Considerations for the Government Consumer]], at 3.</ref>}}

== Structuring and developing SLAs ==

A typical SLA includes the following components and is tailored to fit the nature of the [[outsource]]d 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.

{{Quote|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.<ref>[[Best Practices for Negotiating Cloud-Based Software Contracts]], at 11..</ref>}}

== Issues ==

Issues that are typically addressed in an SLA include:

<div style="{{column-count|2}}">

* [[licensing]] of [[services]]
* [[acceptable use policy|criteria for acceptable use]]
* [[service suspension]] and [[termination]]
* [[limitations on liability]]
* [[privacy policy]]
* [[modification]]s to the [[terms of service]]
* [[uptime]]
* [[security]]
* [[throughput]]
* penalties, and
* [[back-up]] procedures.

</div>

== References ==
<references />

== Source ==

* [[FDIC]], Tools to Manage Technology Providers’ Performance Risk: Service Level Agreements ([http://ithandbook.ffiec.gov/media/resources/3551/fdi-fil-50-2001_3_docs.pdf full-text]).

== See also ==

* [[Cloud SLA Considerations for the Government Consumer]]
* [[Creating Effective Cloud Computing Contracts for the Federal Government, Best Practices for Acquiring IT as a Service]]
* [[Service Level Agreement (No. 1)]]
[[Category:Outsourcing]]
[[Category:Contract]]
[[Category:Definition]]