Checklist Incident Record

<seo metakeywords="incident record, incident record checklist, incident record template, incident record itil" metadescription="An Incident Record typically contains the following information: Unique ID of the Incident (usually allocated automatically by the system) ..." />

DE - ES - Checklist Incident Record - Template Incident Record

Overview

ITIL Process: ITIL 2011 Service Operation - Incident Management

Checklist Category: Templates ITIL 2011 - Service Operation - Most popular ITIL Templates

Source: Checklist "Incident Record" from the ITIL Process Map

 

Fig. 1: ITIL Incident Record - Definition and information flow.

An Incident Record is a set of data with all details of an Incident, documenting the history of the Incident from registration to resolution.

An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives).

 

Incident Record - Contents

An Incident Record typically contains the following information:

 

Unique ID

(Unique ID of the Incident - usually allocated automatically by the system)

Method of notification

(e.g. telephone, e-mail, intranet portal, event monitoring system)

Service Desk agent

(If applicable, Service Desk agent registering the Incident)

Caller/ user data

(If applicable, caller/ user contact information)

Incident priority

Incident Priority, a function of the following components (for further information, refer to the checklist Incident Prioritization Guideline):

1. Urgency (available time until the resolution of the Incident)
2. Impact (damage caused or potential damage to the business or the IT infrastructure)
3. Priority (for example expressed in priority codes like "Critical", "High", "Medium", "Low", "Very Low"): The result from the combination of urgency and impact
4. Major Incident flag (to indicate that the Incident is treated as a Major Incident)

Relationships to CIs

(Links to primary Configuration Items (CIs) affected by the Incident)

Incident category

Incident category, usually selected from a category-tree according to the following example (Incident categories should be harmonized with Problem categories to support matching between Incidents and Problems):

1. Hardware error
   1. Server A
      1. Component x
         1. Symptom a
         2. Symptom b
         3. ...
      2. Component y
      3. ...
   2. Server B
   3. ...
2. Software error
   1. System A
   2. System B
   3. ...
3. Network error
4. ...

Links to related Incident Records

(if a similar outstanding Incident exists, to which the new Incident is able to be attributed)

Links to related Problem Records

(Links to related Problem Records - if any outstanding Problems exist, to which the new Incident is able to be attributed)

Incident status change history

1. Date and time
2. Person in charge
3. Reason for status change
4. New Incident status

Activity log/ resolution history

Most service desk systems allow maintaining a simple log of steps carried out to resolve the Incident. Some systems, however, also provide the means to assign “Tasks” to Incidents. Akin to the Incidents they are assigned to, Tasks are typically characterized by properties like name, description, owner, priority, etc. and contain a status history and activity log of their own.

Closure data

1. Closure categories (if required, revised product and Incident categorizations)
2. Problems raised (if the Incident is likely to recur and preventive action is necessary)
3. Resolution type (elimination of the root cause vs. application of a Workaround; if the Incident was resolved by applying a Workaround: indication of applied Workaround)
4. Customer feedback (is the Incident resolved from the customer’s/ user’s point of view?)