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 V3 Service Operation - Incident Management

Checklist Category: Checklists ITIL V3 Service Operation

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

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), e.g.
       1. Up to 0.5 hrs
       2. Up to 2.0 hrs
       3. Up to 6.0 hrs
    2. Impact (damage caused or potential damage to the business), e.g.
       1. "High" (interruption to critical business processes)
       2. "Normal" (interruption to the work of individual employees)
       3. "Low" (hindrance to the work of individual employees, continuation of work possible by means of a circumventive solution)
    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. Product category, usually selected from a category-tree according to the following example:
    1. Client PC
       1. Standard configuration 1
       2. ...
    2. Printer
       1. Manufacturer 1
       2. ...
13. Incident category, usually selected from a category-tree according to the following example:
    1. Hardware error
       1. Server A
       2. Server B
       3. ...
    2. Software error
       1. System A
       2. System B
    3. ...
14. Links to related Incident Records (if a similar outstanding Incident exists, to which the new Incident is able to be attributed)
15. Links to related Problem Records (if any outstanding Problems exist, to which the new Incident is able to be attributed)
16. Activity log/ resolution history
    1. Date and time
    2. Person in charge
    3. Description of activities
    4. New Incident status (if the activity results in a change of status)
17. 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?)