Incident lifecycle

During the incident handling process, it is beneficial to know in which phase of the incident lifecycle you are. To be able to know this, you need to define all the phases. There may be many different proposals for doing so.

Please consider theITIL (IT Infrastructure Library)  incident lifecycle for your internal use. It is presented below.

The ITIL incident lifecycle consists of the followingphases:

  • occurrence – an unplanned disruption to an agreed service;
  • detection – a process which occurs sometime after the occurrence of an event;
  • diagnostics – identification of the characteristics of the incident;
  • repair – a process of reconfiguring attacked items;
  • recovery – a process of restoring the failed items to their last recoverable state;
  • restoration – a process of providing an expected service back to a user;
  • closure – the final step in the incident lifecycle, during which a user and an incident handler check that a service is fully available.

Are there any practical benefits related to the fact that you know these phases? The answer is ‘yes’ but only if you monitor them. The primary benefit is that, following these phases, you can be sure that you do not omit an important part of what you have to do.

Another purpose of observing the incident lifecycle is to improve the effectiveness of your service. To do this, first you should measure the duration of the particular phases and then:

If you identify the need for improvement and decide to undertake steps to improve your incident handling process then monitor the implementation of the improvements and check whether they bring the desired results. Decreasing the time of particular phases should not be an aim in itself.

How to measure incident lifecycle phases?

There is no easy way to do so. One method would be to observe the time-stamps of your e-mail correspondence for particular incident handling phases, eg, incident report mail, your notification e-mail, incident closing e-mail, etc. A helpful tool for doing this can be your ticketing system for incident handling. It can automatically change and record status.

As a result of your analysis you can, for example, easily observe that there are relatively big time gaps between your e-mails during an exchange of  correspondence – and you may want to address this.

next: incident handling process