What Is Incident Management in ITIL?

ITIL, the IT service management framework now maintained in its fourth edition, describes incident management as one of its core practices. An incident is an unplanned interruption to a service or a reduction in its quality.

The typical flow.

• Identification and logging. The incident is recorded, whether reported by a user, raised by monitoring, or noticed by staff. Every incident gets a record.
• Categorisation. Classifying the incident so it routes correctly and so reporting is meaningful later.
• Prioritisation. Usually a combination of impact, how much of the business is affected, and urgency, how quickly it needs resolution. A matrix turns those into a priority level with associated targets.
• Diagnosis and escalation. First-line attempts resolution using known procedures. If it cannot be resolved, it escalates functionally to specialists, or hierarchically to management for authority and communication.
• Resolution and recovery. Service is restored, which may involve a workaround rather than a permanent fix.
• Closure. Confirming with the user, recording the resolution and cause, and capturing anything reusable such as a known error or a knowledge article.

Major incidents follow a separate path: a defined declaration threshold, a coordinator, a communication channel, regular stakeholder updates, and a review afterward.

Incident, problem, request, and change

It helps by making responsibility explicit, giving every interruption a record, separating restoration from investigation, providing shared vocabulary across teams and suppliers, and producing data that shows where failures concentrate.

It hurts when applied literally in environments it was not designed for. Common failure modes:

Process weight over speed. Categorisation schemes with hundreds of options, mandatory fields nobody reads, and approvals that delay restoration. If filling in the ticket slows the fix, the process is working against its own objective.

Queues instead of ownership. Handing incidents between tiers can add delay when the specialist could have been engaged immediately. Modern practice often routes straight to the team that owns the service.

Metrics that reward the wrong thing. Measuring closure counts or average handling time encourages closing tickets rather than resolving problems. Repeat incident rate and time to restore are better signals.

Problem management as a formality. If problems are logged and never worked, incidents simply recur with the same cause, and the separation becomes paperwork.

Tooling that dictates practice. Heavy ITSM platforms can make simple changes to a workflow expensive, which is how organisations end up with processes shaped by their tool rather than by their work.

Keep categorisation small enough to be accurate. A short list people apply correctly produces better data than a taxonomy they guess at.

Define priority with examples. Abstract impact and urgency matrices are interpreted inconsistently. Concrete examples for each level align judgements.

Route to owners quickly. Escalation paths should be short and known in advance, especially outside working hours.

Require a cause on closure. A structured cause code, not free text, so patterns are visible across hundreds of tickets.

Connect incidents to changes. Recording whether a change was involved is the cheapest way to learn what actually destabilises your environment.

Run real problem management. Group recurring incidents, investigate, and track permanent fixes as work with owners and dates.

Measure restoration and recurrence. Time to restore by priority, repeat incidents by cause, and the proportion of incidents detected by monitoring rather than reported by users. That last figure says a great deal about your monitoring.

Adapt the framework. ITIL 4 is explicitly guidance rather than a rulebook. Take the separation of concerns and the discipline of recording, and leave the ceremony that does not suit your team.

Where the service desk fits