Incident Management Lifecycle – Incident Logging

Incident logging is a somewhat straightforward activity. However, it is important to note that no matter how simple it may sound, organizations tend to go wrong in its implementation.

In the third set of the incident management lifecycle series, I will talk briefly about the incident logging activity.

To fully touch base upon the incident management process, I am leveraging on the incident management process workflow from the ITIL Service Operations publication.

Story So Far

In the first article in the series, I talked in detail about the various incident triggers such as event management tools and users.

The second iteration was about the basic difference between an incident and a service request.

Logging an Incident

Before we get into the activity of logging an incident, I want to stress the need for an incident management policy document which sets the groundwork and framework for incident management process to operate.

Policy Around Logging an Incident

The policy around incident logging goes something like this – every single incident must be logged.

Let’s say that a user calls to get an answer to a query – such as where is the My Documents folder. This is not an incident in the basic sense because nothing is broken. Yet, an incident must be logged to keep track of all the inputs and triggers.

This example does not restrict it to users, but also extends to other sources such as event management tools as well. Even if the tool identifies defined anomaly, it must log an incident before anything else can be done to diagnose and troubleshoot.

Incident Source

The incident form must have provision to capture the source of the incident.

This is an important factor to identify the ownership of the incident in terms of clarifications and confirmations, and it is also analyzed to find relevant information that can potentially act as an input for Continual Service Improvement.


Even if I don’t state that timestamps must be captured, most modern tools do it by default.

Timestamping is an important record that can define a lot of things in service management such as SLA measurements, incident management effectiveness and the service uptimes.

Recommended Fields for an Incident

The sky is the limit. You can have anything you want in an incident form. However, you need to define the data source for each of the fields, and also ensure that you capture something that is absolutely needed. Don’t just have a field because you thought about it. Analyze the need, and determine where it can be used

The ITIL Service Operations publication recommends the following fields for an incident:

■■ Unique reference number

■■ Incident categorization (often broken down into between two and four sub-categories)

■■ Incident urgency

■■ Incident impact

■■ Incident prioritization

■■ Date/time recorded

■■ Name/ID of the person and/or group recording the incident

■■ Method of notification (telephone, automatic, email, in person etc.)

■■ Name/department/phone/location of user

■■ Call-back method (telephone, mail etc.)

■■ Description of symptoms

■■ Incident status (active, waiting, closed etc.)

■■ Related CI

■■ Support group/person to which the incident is allocated

■■ Related problem/known error

■■ Activities undertaken to resolve the incident and when these took place

■■ Resolution date and time

■■ Closure category

■■ Closure date and time

Incident Form in ServiceNow
Incident Form in ServiceNow

Incident Updates

The next policy to be defined is around incident updates.

All incidents must be updated on a regular basis. Based on the priority of an incident, the policy defines the maximum permitted time between consecutive. Even if there is no progress, resolver groups must keep the ticket updated.

This comes in handy in tracking incidents by incident managers. If a team is not working on an incident, then there must be a good reason to it, right? Maybe the user is not around or maybe the team is waiting for a certain time when the incident normally recurs.

In these cases, the ticket must probably be placed On Hold. If the ticket is not updated, then the management tracking incidents will have no basis to keep a tab on the open incidents.

Next Up

In the next article in the incident management lifecycle series, I will talk about incident categorization.

Related posts

ITIL : Cost vs Quality

Abhinav Kaiser

[VIDEO] ITIL Costs Explained

Abhinav Kaiser

ITIL 2011 : Strategy Management for IT Services

Abhinav Kaiser

Become ITIL Foundation Certified in 7 Days Enters Production

Abhinav Kaiser

ITIL : Internal IT View vs External Business View

Abhinav Kaiser

Few KPIs for Configuration Management for Process Interfaces

Abhinav Kaiser

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.