ITSM

Incident vs Problem Management, and Where Change Enablement Fits

Last updated 2 October 2026

Incident vs problem management comes down to speed versus cause. An incident is an unplanned interruption to a service, or a drop in its quality, and incident management exists to restore normal service quickly. A problem is the cause, or potential cause, of one or more incidents, and problem management exists to find that cause and reduce repeat incidents. Change enablement, the ITIL 4 name for change management, controls the alterations to live services that either fix a problem or cause the next incident.

Four kinds of ticket, four different questions

A service desk queue holds more than faults, so incident vs problem management starts with sorting what arrives. Four tests cover most tickets:

Something is broken or running badly for users right now. That is an incident.
Someone is asking for something that is a normal part of the service, such as access or equipment. That is a service request.
The same thing keeps breaking, or nobody knows why it broke. That is a problem.
Someone is about to add, modify or remove something that could affect a service. That is a change.

One failure can touch all four records, as the worked example below shows. They stay separate because each has a different aim and a different pace. Mixing them produces reports that are hard to trust, and an incident vs problem management split that nobody can measure.

Incident vs problem management

The two practices deal with the same failures, which is why incident vs problem management is the pair people confuse most. Emory University’s IT service describes them as separate processes that are closely related and typically use the same tools. What separates them is the goal.

ITIL incident management puts service restoration first

PeopleCert’s description of the ITIL 4 incident management practice centres on restoring normal service swiftly after a disruption and minimising downtime. The measure of success is how quickly users can work again, not why the service failed. That is why a workaround is a legitimate way to resolve an incident: Cornell’s IT service describes incident work as repair or workarounds. Restarting a service or clearing a full disk both count, even though neither removes the cause.

The problem management process goes after the cause

ITIL 4 describes problem management as reducing the likelihood and impact of incidents by identifying actual and potential causes and managing workarounds and known errors. In plain words, a known error is a problem whose cause is understood but not yet fixed. It is recorded together with its workaround, so the next engineer who meets the symptom can resolve the incident quickly while the permanent fix is arranged. In incident vs problem management terms, the known error is the bridge between them, letting the incident side move fast while the problem side takes the time it needs.

The word “potential” matters. A problem record can start from a pattern in the ticket data, not only from an outage that has already happened.

Incident vs problem management at a glance

Question	Incident management	Problem management
What starts it?	A service is interrupted or degraded	Incidents repeat, a cause is unknown, or a pattern points to a risk
What is it trying to achieve?	Normal service restored quickly	Fewer incidents, and smaller ones, by dealing with causes
What counts as done?	Service restored, possibly by workaround	Cause removed, or a workaround and known error documented while a fix is arranged
How fast does it move?	As fast as the priority demands	At the pace the investigation needs
What does it produce?	A resolved ticket and an informed user	A root cause finding, a known error record and usually a request for change

The last two rows describe common practice, not a requirement of ITIL.

Where ITIL change enablement fits into incident vs problem management

ITIL 4 defines a change as the addition, modification or removal of anything that could have a direct or indirect effect on services. The change enablement practice aims to maximise the number of successful changes by making sure risks are assessed, authorising changes to proceed and managing the change schedule. The definition is wide: a software patch, a firewall rule and a configuration setting can all qualify.

A common way to sort changes is into three types, each with its own approval route:

Standard change. Low risk, well understood and documented, with authority given in advance, so nobody has to approve it afresh each time. Creating an internal storage resource at a user’s request is the example AWS gives.
Normal change. The default route for anything unique or higher risk. It is reviewed and approved before it goes ahead. A firewall rule that opens a non-standard port for a new service is a typical case.
Emergency change. Needed quickly to restore operations or deal with a serious risk. Approval is faster, but a documented procedure still applies.

Who approves is a design choice. A change advisory board is one option. AWS’s change enablement guidance notes that research suggests peer review within a team can optimise risk as well as a board does, which lets organisations decentralise approval.

Change sits on both sides of incident vs problem management. An unreviewed change can cause incidents, and the permanent fix for a problem is itself a change, so it needs the same assessment.

One failure, four records

This invented scenario shows incident vs problem management, and change, working on the same failure. It is not based on any client or real event.

The incident. Several staff cannot open the leave and attendance system. The service desk logs one incident and sets its priority by business impact, because a whole department cannot record attendance. Meanwhile a new manager asks for access to a report. That goes into the service request queue, not the incident queue.
The workaround. An engineer finds the application server’s disk full of old log files, deletes them and restarts the service. Users are working again within the hour. The incident is resolved by a workaround, because nothing has addressed why the disk filled.
The problem. Five weeks later the same fault returns. The service desk links the new incident to the earlier one and a problem record is opened. Investigation shows log rotation was switched off during an upgrade. The team records a known error with the clean-up workaround. They also check other servers built the same way, which is the “potential cause” side of the practice.
The change. Switching log rotation back on and enlarging the disk modifies a live system, so it is raised as a normal change: risk assessed, rollback plan written, approval given and a time agreed outside working hours. Had the disk filled again in the middle of the working day with no workaround left, an emergency change might have been used instead.
The close-out. After an agreed period without a repeat, the problem is closed and the known error retired.

That is the practical case for incident vs problem management as two practices. Without the problem record, the clean-up would have been repeated indefinitely.

Service request vs incident

A service request is a user’s request for something already agreed as a normal part of the service, such as access, information or equipment. An incident is something that has stopped working or is working badly. A new starter’s laptop is a request. A laptop that will not start is an incident.

PeopleCert describes service request management as handling predefined, user-initiated requests, which is why requests usually have set forms and approval steps. Logging them as incidents inflates incident numbers, buries real failures and skews any incident vs problem management analysis built on them. Each type needs its own targets, which the IT service desk SLA template sets out field by field.

Four habits that blur the records

Teams that understand incident vs problem management on paper still slip in practice.

Closing incidents without a problem check. Set a rule, such as a problem review for any repeat incident, any incident that needed a workaround and any high-priority outage.
Opening a problem for every incident. Problem work takes engineer time. Keep it for incidents that repeat or do real damage.
Fixing production with no change record. A quick fix is still a change, and the next engineer has no way of knowing it happened.
Letting the tool’s defaults define the terms. Write the definitions in your own words, then configure categories to match.

Teams that want incident vs problem management definitions and approval routes written for their own environment can look at WASNA Digital Solutions’ ITIL-aligned ITSM and service desk design, which usually starts with incident and change management and adds problem management as ticket data builds up. The wider background is in what ITSM is and how it relates to ITIL.

A note on names and versions

ITIL 4 calls the practice change enablement. ISO/IEC 20000-1:2018 titles its clause on the same subject “Change management” (8.5.1), and groups incident management (8.6.1), service request management (8.6.2) and problem management (8.6.3) under “Resolution and fulfilment”. If a contract or audit checklist uses one of these names, check which definition it relies on. The incident vs problem management split itself appears in both frameworks, as separate practices in ITIL 4 and separate clauses in ISO/IEC 20000-1:2018.

This article uses ITIL 4 terms. PeopleCert has since released ITIL (Version 5), and its ITIL FAQ says the current plan is to sunset all ITIL 4 modules on 31 December 2027. If you are planning training, check which version the provider teaches.

Check how your team separates incident vs problem management and change

Tell us which tool you use, how incidents and changes are logged today and where the same faults keep returning. We will talk through where the definitions and approval routes need tightening.

Discuss your incident and change process