ITIL/ISO 20000 Knowledge base

Neven Zitek

ITIL Incident Management

Author: Neven Zitek

Any unplanned interruption or service degradation is, according to ITIL, considered to be an incident. So once incident happens, and they will, the primary goal of ITIL Incident Management is to restore service as quickly as possible in order to minimize the business impact. Any event that disrupts or could disrupt a service itself is within the scope of incident management. For example, a single failed disk drive within a mirrored array is not causing any interruptions, but there is a service degradation in that risk of data loss has increased, and that’s why such an event is also considered to be an incident.

ITIL Incident Management, as a part of IT Service Management, is responsible for incident identification, logging and categorization. Reports about incidents may come from the Service Desk (by call, e-mail, web), event management or directly from technical staff, but all of them have to be recorded, time stamped and contain sufficient data in order to be properly managed.

In order to effectively manage incidents, we need to have means to prioritize them, because they rarely appear only one at a time. And we prioritize incidents using the Impact vs. Urgency matrix. Impact is the effect an incident has on a business, and Urgency basically defines the amount of time a business (or customer) is willing to wait for resolution. For example, we may have a high-impact incident (high level – 1) affecting the whole finance department, but low urgency (low level – 3) because they use that service only on the end of the fiscal year, which is 6 months away. In such a scenario, this incident is categorized as moderate priority – 3. Details about time frames in which each level of priority is expected to be resolved is part of the Service Level Agreement (SLA). Read this blog post for more information: All About Incident Classification.


Incidents are generally results of errors or malfunctions within IT equipment. In such cases, root cause is apparent, and resolution is as simple as repairing a faulty part, or applying a workaround. But in a case where the seriousness of the incident is great, or an avalanche of similar incidents has been recorded, the Problem Management process steps in and takes over the search for the root cause. Once root cause has been identified, the problem is referred to as known error, and is registered in the Known Error Database (KeDB). The Service Desk, as a function of Incident Management, relies on the Known Error Database and workarounds provided. If you need a tool that will help you manage incidents, here is the list of Free tools for ITSM that you may try, and use for free.

To summarize, ITIL Incident Management is effectively managing an incident’s lifecycle from the moment the incident is reported until its resolution and closure. During that time, in search for resolution, internal experts from another department or third parties may have been involved (vendors or providers), but ownership of the incident is always within Incident Management. ITIL Incident Management is strongly dependent on an effective Service Desk, clearly defined targets within SLAs, and adequate, technically trained, and customer-oriented staff.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 20000 and ITIL standards.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.