The service management processes in ISO 20000-1

Clause 8 is the heart of ISO 20000-1. This is where the processes that run your day-to-day IT service are set out, from fixing a fault to rolling out a new version. In a certification audit, half the time is often spent on this chapter. You can find the official standard via ISO  and via NEN . For an overview of all the requirements, see the requirements of ISO 20000-1, and for the context, see what ISO 20000-1 is.

On this page, we go through the main processes with concrete examples for non-technical readers.

On this page

Below, we discuss the processes that the standard requires. For each process, you can read what it involves and how it works in practice. Use the links to jump quickly to a specific process.

Service level management (SLA)

Service level management is about the agreements you make with customers on the quality of your service. You record those agreements in a service level agreement (SLA). The standard therefore requires you to monitor and report on those agreements.

For example, an MSP promises a customer that faults will be resolved within four hours. Service level management covers who measures this, how the customer is informed if it looks likely to fail, and what happens if the four hours are exceeded.

Incident management

An incident is an unexpected interruption or drop in quality of a service. Incident management has one goal: restore the service as quickly as possible. For the fields a ticket needs to show this, see the ISO 20000 ticket system.

An installation company loses access to its planning software. That is an incident. The incident process says: register it, categorise it, assign it to the right person, inform the person who reported it, and resolve it. The speed of resolution counts, not the cause. The cause is for the next process.

Service requests

Not every report is a fault. Someone asks for a new password, an extra screen or access to a system. These are service requests: predictable requests that you handle through a fixed process.

The difference from incidents is the expectation. A service request is planned work with an agreed lead time, not an emergency. The standard requires you to register these requests, categorise them and handle them within the agreed time.

Problem management

Problem management is the in-depth analysis after incidents. Why did the system fail? What is the root cause? And how do you prevent it from happening again?

For example, a webshop has had three outages in one month caused by an overloaded database. Each incident was resolved by restarting the server. Problem management asks: why does this database keep becoming overloaded? The solution (more capacity, better queries) fixes the problem and prevents future incidents.

Change management

Every adjustment to your IT environment is a change: a software update, a new server, a different configuration. Change management makes sure such changes are made in a controlled way.

Without a fixed process, things go wrong. Someone quickly adjusts something, and three other systems fail. The change process asks: has the change been approved, has it been tested, who is informed, and what do you do if it goes wrong (rollback)?

Release management

Release management is closely related to change management, but it focuses specifically on rolling out new software or services to the production environment. Think of a new version of an application or a firmware update for network equipment.

The process makes sure releases are planned, tested and documented before they go live. Who handles it, when, and how do you know it has worked?

Configuration management

Configuration management keeps track of which IT components you have, how they are connected and what their status is. This register is called a configuration management database (CMDB). Without an overview, you do not know which systems exist and how they are linked when a fault occurs.

For example, an MSP manages 50 servers for a customer. The CMDB shows which servers exist, which software runs on them, and which services depend on them. If server 12 fails, the help desk employee immediately knows which customers are affected.

Capacity and availability

These are two separate but related processes. Capacity management makes sure you have enough resources for today’s demand and future demand. Availability management focuses on guaranteeing the agreed uptime.

A cloud provider promises 99.9 percent availability. That requires planning: how many users are coming, what the peak load is, and what you do if a component fails. You answer these questions proactively, not during an outage.

Supplier management

Almost every IT service provider relies on other suppliers: data centres, software vendors, telecom providers. If that supplier fails, your service fails too. Supplier management covers the agreements with those parties and checks whether they are being kept.

The standard requires you to map your suppliers, record agreements and evaluate them regularly. An MSP that buys hosting from a data centre records the following: what the agreed uptime is, how outages are communicated, and what the consequences are if the supplier does not comply.

Overview: processes in one table

How the processes fit together

The processes are not isolated islands. An incident can turn into a problem. A problem leads to a change. That change reaches production through a release. Configuration management keeps track of what has changed. The auditor checks this whole system under clause 8.

Want to know how to build this? Read the step-by-step plan. Are you combining it with information security? See ISO 20000 and ISO 27001.

Next steps