Service Level Agreements (SLAs) are critical to the computer industry but they are rarely fully understood.

Under an SLA, a supplier undertakes to supply a service to a client at a particular level.


  • defines the service required (i.e. what the client wants and what the supplier is prepared to commit to supply);
  • sets quality standards (i.e. what standards or levels the supplier must achieve);
  • defines any deliverables (e.g. regular reports);
  • defines a means of compensating for failure to meet the standard of service required (e.g. by service credits).

Ideally, an SLA should be a self-enforcing agreement within a continuing relationship. Changes required should be dealt with through a change control procedure.

In some ways the process of creating the SLA is as valuable as the agreement itself. SLAs can be between different businesses or between different parts of the same organisation (such as the IT department and its users).

A Service Level Agreement should cover:

  • Quality standards, such as host/terminal response times, batch processing times, 'uptime', or processor availability, by specifying what? when? how? and by whom?
  • The consequences of failing to meet service procedures or standards.
  • Procedures for the client to monitor performance of obligations by the supplier.
  • Procedures for change control (ie changing part of the service that is being provided by the supplier under the agreement).
  • Terms dealing with access to, and security of, the client's site and data.
  • A procedure for disaster recovery (either upon a system failure or a catastrophe).
  • The agreed frequency of meetings between the client and the supplier to review the supplier's performance of the agreement, properly minuted with subsequent action plans and awards of priority.

Facilities Management Agreements, Software Maintenance Agreements and Managed Data Network Agreements are all examples of SLAs.

Alternatively, the SLA may be one aspect of a larger agreement for services, i.e. it is the schedule that stipulates how well the services have to be provided and what happens if the supplier does not provide this.

What form should a Service Level Agreement take?

At its weakest, an SLA may be a simple oral understanding, documented by an exchange of letters. The best form is a formal legal agreement with the technical procedures and specifications annexed as separate schedules.

What happens if the terms of a Service Level Agreement are broken? If the breach is fundamental, the party not in breach will be entitled to terminate the agreement and sue for the loss suffered as a result of the breach.

In other circumstances there will be a system for measuring breach and apportioning cost. These systems range from an event-based system (if... then...) to a more sophisticated system of 'failure points' (if there are more than five examples of ... then ...).

The functions of such compensation systems vary from simply drawing attention to a problem to compensation for loss. Compensation for loss is difficult to quantify and, if it is excessive, will be unenforceable by a court (which will regard it as a penalty).

In practice, the right to withhold payment is a valuable weapon. The end (or slowing down) of payments into the supplier's accounts department is likely to put pressure on the supplier.

Escalation clauses are undervalued and should be more widely used. These provide for a problem to be escalated up the various tiers of management on both sides if it cannot initially be resolved.

Even the best SLA does not last for ever and there must be a procedure for orderly termination and (if necessary) migration from the supplier's system to another system.

Migration is critically important in relation to facilities management contracts and, as a rule of thumb, a year is generally allowed for this. The supplier should also be required to provide all reasonable assistance to the client with the migration to another system.

About the author

Jeremy Holt is the head of the Computer Law Group of Clark Holt Commercial Solicitors ( He is the co-author of A Manager's Guide to IT Law published by BCS in 2004.