Incident Record - Template

 

Definition

Fig. 1: Incident record
(YaSM checklist / document template)

An incident record is a set of data with all details of a service incident, documenting the history of the incident from registration to closure. A service incident is defined as an unplanned interruption or reduction in quality of a service. Events that could potentially impair a service in the future are also treated as incidents (e.g. the failure of one hard-drive of a set of mirrored drives).

Related YaSM service management process: Resolve incidents and service requests

More checklists and document templates: Service management checklists

 

Typical contents

An incident record typically contains the following information:

 

Incident Record - Contents

Content	Description
Unique incident ID	A unique ID is usually allocated automatically by the application used to manage service incidents.
Incident status	Incident status values could be for example "Raised", "Open", "Resolved", "Closed", ...
Incident recording	Date and time of incident recording.
Incident occurrence	Date and time of incident occurrence.
Source and method of notification	E.g. telephone, e-mail, intranet portal, event monitoring system.
Contact information	Caller/ user contact information and callback method.
Authorization information	If applicable, details on how it has been established that the requester is authorized to raise the incident.
Incident owner	The incident owner retains overall responsibility for the resolution of the incident, even if it is assigned during its lifecycle to other support agents or groups to perform specific tasks.
Assignment	Agent or support group to which the incident is assigned. This assignment may change during the lifecycle of the incident.
Classification/ categorization	Incident classification is a way to add tags to incidents which are instrumental in assigning them to the appropriate support agent or group, as well as in the creation of statistics and the analysis of historical incidents. Classification schemes may vary between different organizations, but incidents are often classified by Service(s) affected Customer(s) affected Location(s) affected Infrastructure component(s) and sub-component(s) (i.e. configuration items) affected Type of symptom (e.g. "Hardware defect", "Software defect", "Slow performance", "Security issue", ...).
Symptoms	Description of symptoms.
Priority	Priority is often expressed in priority codes like "Critical", "High", "Medium", "Low", "Very low"). Priority is the result from the combination of urgency and impact where Urgency is a measure of the available time until the resolution of the incident Impact is a measure of the (potential) damage to the business. For an example for a prioritization scheme, refer to the checklist "Incident and Service Request Policy". For recurring incidents, rules for prioritizing the incidents are typically defined in or coded into the corresponding incident models.
Major incident flag	This flag indicates that an incident is treated as a major incident.
Target time for incident resolution	This is the target time as committed in the applicable service definitions and agreements. Target resolution times are typically determined based on the incident’s priority.
Incident model(s)	Applicable incident model(s).
Links to related records	Links to related incident records If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident". Links to related event records If the incident has been raised following an event detected by an event monitoring system. Links to related problem records If any problems exist which are related to the incident at hand in particular, a problem record can contain a suitable workaround. Links to related change records If any change requests were submitted during incident resolution. If the incident is linked to a (recently implemented) change.
Escalation	Functional escalation: Functional escalations (changes in the assignment of the incident to particular support agents or groups) must be recorded. Hierarchic escalation High-priority or delayed incidents usually trigger hierarchic escalations, for example to top management. Such escalations must be recorded.
Status changes	This section records incident status changes (for example from "open" to "resolved").
Activity log/ tasks assigned to the incident	Most applications for managing incidents 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.
Incident closure	Closure information.
Resolution type	Elimination of the underlying cause vs. application of a workaround. If the incident was resolved by applying a workaround: Indication of the applied workaround.
Problems raised	A problem record must be raised, for example If the incident is likely to recur and preventive action is necessary If the incident has not been completely understood If a new workaround has been devised during incident resolution.
Customer feedback	Confirmation from the customer or user that the incident has been resolved results from a satisfaction survey if one has been conducted.
Additional information	Notes and additional information.

 

Status values and lifecycle

(This information is included in the lifecycle diagram for the incident record contained in the YaSM® Process Map.)

Remark

• For particular types of recurring incidents, incident models describe how the incidents are to be resolved. In many cases, the handling of such incidents is supported by appropriately configured incident management tools (for example, there may be short-cuts to easily create certain types of incident records).
• The classification of incidents and problems should use the same scheme in order to support matching between incidents and problems - which is important, for example, for the identification of known errors and available workarounds during the resolution of an incident.

 

Notes

Is based on: YaSM "Incident record" template from the YaSM Process Map.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

 

Definition  › Contents  › Classification/ categorization  › Priority  › Escalation  › Remark