Incident Record - Template

From YaSM Service Management Wiki

auf Deutsch


Incident record template. YaSM service management document templates and checklists (example).
Fig. 1: Incident record
(YaSM checklist / document template)

Definition: 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


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.
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", ...).
Description of symptoms.
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.
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.)


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



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

By:  Stefan Kempter Author: Stefan Kempter, IT Process Maps GbR  and  Andrea Kempter Contributor: Andrea Kempter, IT Process Maps GbR, IT Process Maps.


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