Checklist Incident Record

<seo metakeywords="incident record, incident record checklist, incident record template" 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

ITIL Process: ITIL 2011 Service Operation - Incident Management

Checklist Category: Checklists ITIL Service Operation

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

 

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).

 

An Incident Record typically contains the following information:

 

1. Unique ID of the Incident (usually allocated automatically by the system)
2. Date and time of recording
3. Service Desk agent responsible for the registration
4. Method of notification
5. Caller/ user data
6. Callback method
7. Description of symptoms
8. Affected users/ business areas
9. Affected service(s)
10. Prioritization, a function of the following components:
    1. Urgency (available time until the resolution of the Incident)
    2. Impact (damage caused or potential damage to the business)
    3. Priority (for example in stages 1, 2 and 3): The result from the combination of urgency and impact
    4. Major Incident flag (to indicate that the Incident is treated as a Major Incident)
11. Relationships to CIs
12. Incident category, usually selected from a category-tree according to the following example (Incident categories should be harmonized with CI and Problem categories to support matching between Incidents, Problems and CIs):
    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. ...
13. Links to related Incident Records (if a similar outstanding Incident exists, to which the new Incident is able to be attributed)
14. Links to related Problem Records (if any outstanding Problems exist, to which the new Incident is able to be attributed)
15. Activity log/ resolution history
    1. Date and time
    2. Person in charge
    3. Description of activities undertaken and results
    4. New Incident status (if the activity results in a change of status)
16. 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?)