Service level management ISO 20000 guide: agreeing, measuring and reviewing SLAs under clause 8.3.3

What does service level management mean in ISO/IEC 20000-1?

In ISO/IEC 20000-1, service level management is the discipline that turns a customer's expectations into targets both sides agree, then proves month after month whether those targets were met. The standard places it in clause 8.3.3, titled "Service level management", under 8.3 Relationship and agreement, next to business relationship management (8.3.2) and supplier management (8.3.4).

ISO/IEC JTC 1/SC 40, the committee responsible for the standard, notes that under clause 8.3.3 every service in the scope of the SMS should have an SLA. Because the standard does not accept the exclusion of any requirement in clauses 4 to 10 when conformity is claimed, a provider cannot certify its service desk while leaving service levels undefined. What the standard leaves to you is the form: one SLA per customer, one per service, a master agreement with service schedules, or an internal agreement for an IT department serving its own business.

This guide covers the process. How to write and control the SLA document itself is covered in the ISO/IEC 20000-1 documentation guide, and the full clause map sits in ISO/IEC 20000-1 requirements explained.

The service level management cycle

Read clause 8.3.3 against the rest of the standard and a five-step cycle appears. Each step leaves a record, and the certification body samples each of them.

1. Understand the service requirements

Start from what the customer's business needs from the service, not from what the tool happens to measure. Complaints, satisfaction feedback and planned changes on the customer side, gathered through business relationship management, all shape them. The catalogue entry (8.2.4) then describes the service the agreement will cover.

2. Agree the services and the targets

The provider and the customer agree which services are delivered and the measurable targets for each. Typical targets cover availability, response and resolution times by priority, request fulfilment times and support hours. Agreement is the operative word: a target the customer never saw is not an agreed service level.

3. Measure the performance

Each target needs a defined data source, a calculation rule and an owner. If the SLA says 99.9% monthly availability, someone must be able to say which monitoring tool produced the figure, whether planned maintenance counts and how partial outages are treated.

4. Report and review

Results reach the customer through service reporting (9.4) and are reviewed with the customer on a schedule you plan and keep. The review is where trends, workload changes and upcoming business changes are raised, and where the SLA itself is questioned if it no longer fits.

5. Act on the results

A missed target leads somewhere: a problem record, a capacity decision, a supplier conversation, a revised target or an improvement logged under clause 10.

Setting targets that survive an audit and a bad month

Most SLA problems start at the drafting stage. Targets are copied from a previous contract or a sales proposal, then nobody can measure them. Four tests help before anything is signed.

• Measurable from your own data. If the ITSM tool cannot report the metric, either change the tool configuration or change the target. A manual spreadsheet reconstructed at month end rarely survives sampling.
• Defined in words the customer understands. "P1 restored within four hours, 24x7" says more than "Severity A MTTR 240". Priority definitions belong in the agreement, not only in the tool.
• Supported by what sits behind them. A four-hour restoration target needs staffing, spares and supplier response times that allow it. That is the job of capacity management (8.4.3), availability management (8.7.1) and supplier management (8.3.4).
• Bounded. Write down what the service covers and what it does not: support hours, volumes the price assumes, planned maintenance windows and dependencies on the customer.

Experience-level agreements (XLAs) are sometimes proposed as a replacement. SC 40's guidance paper treats them as a complement that sits closer to business relationship management; the SLA remains the part clause 8.3.3 asks for.

The chain behind the SLA: suppliers, internal teams and group companies

Few IT services are delivered by one team alone. Hosting, network links, licences, field engineers and second-line support often come from external suppliers, other departments or a parent company. ISO/IEC 20000-1 requires the services, service components and processes operated by other parties to be identified (8.2.3), contracts with external suppliers, and documented agreements with internal suppliers or with customers acting as suppliers (8.3.4).

The practical test is alignment. Lay each customer SLA next to the agreements that support it and check every target line by line. Where the supplier's commitment is weaker than yours, you either strengthen the contract, add your own mitigation, or change what you promise.

A worked example: one service, one quarter

Take a managed service provider in the Philippines that runs end-user support for a fintech business in India. The catalogue lists "Workplace support: service desk, device support and access requests". The SLA agrees service desk hours of 07:00 to 22:00 India time on weekdays, first response for high-priority incidents within 30 minutes, restoration within eight business hours, and access requests completed within one business day for an agreed monthly volume.

In month two, restoration performance falls to 88% against a 95% target. The service report shows it, and the monthly review with the customer's IT lead records three causes: a laptop supplier's replacement times had slipped, a new office in Pune doubled requests, and two engineers left. The actions are logged with owners: a problem record for the device failures, a supplier performance review against the replacement terms in the contract, a capacity decision to add one engineer, and a note that the request volume now exceeds what the SLA assumed, so the agreement goes back to both parties for revision.

By month three the target is met again. That trail, from target to measured result, review, decision and evidence of effect, is exactly what the certification body wants to see.

What the auditor asks for, and the mistakes that show

At Stage 2, service level management is usually tested by sampling. The auditor picks a customer or a service and asks for the catalogue entry, the current SLA with its version history, three to six months of service reports, the minutes or record of the last reviews, and the actions raised when targets were missed. Interviews with the service owner and a service desk lead confirm whether people know the targets they work to.

The findings we see most often are predictable:

• Services in scope with no SLA, or an SLA that expired and was never renewed.
• Targets the tool cannot report, filled in by hand each month.
• Service reports sent to the customer but never discussed, so there is no review record.
• Supplier contracts with weaker terms than the customer SLA, and no mitigation recorded.
• Internal IT departments with "informal" service levels that nobody on the business side has agreed.
• Missed targets explained in the report but not followed by any recorded action.

Service level management under ISO/IEC 20000-1: questions buyers ask