Checklist Incident Priority: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
< | <itpmch><title>Checklist Incident Priority | IT Process Wiki</title> | ||
<meta name="keywords" content="incident priorities, incident priority, incident priorizitation, major incident, incident priority matrix, major incident identification" /> | |||
<meta name="description" content="Incident Prioritization Guideline: Assigning priorities to Incidents. Incident Priority Matrix. Definition of Major Incidents." /> | |||
</itpmch> | |||
<imagemap> | <imagemap> | ||
Image:ITIL-Wiki-deutsch.jpg|right|Checklist Incident Priority - Template Incident Priority | Image:ITIL-Wiki-deutsch.jpg|right|Checklist Incident Priority - Template Incident Priority | ||
Line 7: | Line 10: | ||
<br style="clear:both;"/> | <br style="clear:both;"/> | ||
<p> </p> | |||
'''ITIL Process''': [[ITIL | '''ITIL Process''': [[ITIL Service Operation|ITIL 2011 Service Operation]] - [[Incident Management]] | ||
'''Checklist Category:''' [[ITIL-Checklists# | '''Checklist Category:''' [[ITIL-Checklists#ITIL 2011 Templates|Templates ITIL 2011]] - Service Operation | ||
'''Source''': Checklist "Incident Prioritization Guideline" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map] | '''Source''': Checklist "Incident Prioritization Guideline" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map] | ||
<p> </p> | <p> </p> | ||
===<span id="Incident Priority">Overview</span>=== | |||
The ''Incident Prioritization Guideline'' describes the rules for assigning ''priorities to Incidents'', including the definition of what constitutes a ''Major Incident''. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering appropriate ''Incident escalations''. | The ''Incident Prioritization Guideline'' describes the rules for assigning ''priorities to Incidents'', including the definition of what constitutes a ''Major Incident''. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering appropriate ''Incident escalations''. | ||
Line 27: | Line 32: | ||
<p> </p> | <p> </p> | ||
== Incident Urgency (Categories of Urgency) == | __TOC__ | ||
==Incident Urgency (Categories of Urgency)== | |||
This section establishes ''categories of urgency''. The definitions must suit the type of organization, so the following table is only an example: | This section establishes ''categories of urgency''. The definitions must suit the type of organization, so the following table is only an example: | ||
Line 35: | Line 42: | ||
<p> </p> | <p> </p> | ||
{| border="1" cellpadding="5" cellspacing="0 | {| border="1" cellpadding="5" cellspacing="0" | ||
|- | |- | ||
! width="25%" style="background:#ffcc66;" | Category | ! width="25%" style="background:#ffcc66;" | Category | ||
Line 60: | Line 67: | ||
<p> </p> | <p> </p> | ||
== Incident Impact (Categories of Impact) == | ==Incident Impact (Categories of Impact)== | ||
This section establishes ''categories of impact''. The definitions must suit the type of organization, so the following table is only an example: | This section establishes ''categories of impact''. The definitions must suit the type of organization, so the following table is only an example: | ||
Line 68: | Line 75: | ||
<p> </p> | <p> </p> | ||
{| border="1" cellpadding="5" cellspacing="0 | {| border="1" cellpadding="5" cellspacing="0" | ||
|- | |- | ||
! width="25%" style="background:#ffcc66;" | Category | ! width="25%" style="background:#ffcc66;" | Category | ||
Line 98: | Line 105: | ||
<p> </p> | <p> </p> | ||
== Incident Priority Classes == | ==Incident Priority Classes== | ||
''Incident Priority'' is derived from [[#Incident Urgency (Categories of Urgency)|urgency]] and [[#Incident Impact (Categories of Impact)|impact]]. | ''Incident Priority'' is derived from [[#Incident Urgency (Categories of Urgency)|urgency]] and [[#Incident Impact (Categories of Impact)|impact]]. | ||
Line 171: | Line 178: | ||
<p> </p> | <p> </p> | ||
== <span id="Major Incident Handling">Circumstances that warrant the Incident to be treated as a Major Incident</span> == | ==<span id="Major Incident Handling">Circumstances that warrant the Incident to be treated as a Major Incident</span>== | ||
''Major Incidents'' call for the establishment of a Major Incident Team and are managed through the [[Incident Management#Handling of Major Incidents|Handling of Major Incidents]] process. | ''Major Incidents'' call for the establishment of a Major Incident Team and are managed through the [[Incident Management#Handling-of-Major-Incidents|Handling of Major Incidents]] process. | ||
==== Indicators ==== | ====Indicators==== | ||
The above prioritization scheme notwithstanding, it is often appropriate to define additional, readily understandable indicators for identifying Major Incidents (see also the comments below on identifying Major Incidents). Examples for such indicators are: | The above prioritization scheme notwithstanding, it is often appropriate to define additional, readily understandable indicators for identifying Major Incidents (see also the comments below on identifying Major Incidents). Examples for such indicators are: | ||
Line 184: | Line 191: | ||
<p> </p> | <p> </p> | ||
==== Identifying Major Incidents ==== | ====Identifying Major Incidents==== | ||
It is not easy to give clear guidelines on how to identify major incidents although the [[Roles | It is not easy to give clear guidelines on how to identify major incidents although the [[ITIL Roles#1st Level Support|1st Level Support]] often develops a "sixth sense" for these. It is also probably better to err on the side of caution in this respect. | ||
A ''Major incidents'' tend to be characterized by its impact, especially on customers. Consider some examples: | A ''Major incidents'' tend to be characterized by its impact, especially on customers. Consider some examples: | ||
Line 200: | Line 207: | ||
<p> </p> | <p> </p> | ||
==== Major Incidents - Key Characteristics ==== | ====Major Incidents - Key Characteristics==== | ||
Some of the key characteristics that make these Major Incidents are: | Some of the key characteristics that make these Major Incidents are: | ||
Line 215: | Line 222: | ||
<p> </p> | <p> </p> | ||
<html><a rel="author" href="https://plus.google.com/111925560448291102517"><img style="margin:0px 0px 0px 0px;" src="/skins/Vector/images/itpm/bookmarking/gplus.png" width="16" height="16" title="By: Stefan Kempter | Profile on Google+" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a></html> | |||
<!-- This page is assigned to the following categories: --> | <!-- This page is assigned to the following categories: --> |
Revision as of 16:30, 3 August 2013
ITIL Process: ITIL 2011 Service Operation - Incident Management
Checklist Category: Templates ITIL 2011 - Service Operation
Source: Checklist "Incident Prioritization Guideline" from the ITIL Process Map
Overview
The Incident Prioritization Guideline describes the rules for assigning priorities to Incidents, including the definition of what constitutes a Major Incident. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering appropriate Incident escalations.
An Incident’s priority is usually determined by assessing its impact and urgency, where
- Urgency is a measure how quickly a resolution of the Incident is required
- Impact is measure of the extent of the Incident and of the potential damage caused by the Incident before it can be resolved.
Incident Urgency (Categories of Urgency)
This section establishes categories of urgency. The definitions must suit the type of organization, so the following table is only an example:
To determine the Incident’s urgency, choose the highest relevant category:
Category | Description |
---|---|
High (H) |
|
Medium (M) |
|
Low (L) |
|
Incident Impact (Categories of Impact)
This section establishes categories of impact. The definitions must suit the type of organization, so the following table is only an example:
To determine the Incident’s impact, choose the highest relevant category:
Category | Description |
---|---|
High (H) |
|
Medium (M) |
|
Low (L) |
|
Incident Priority Classes
Incident Priority is derived from urgency and impact.
Incident Priority Matrix
If classes are defined to rate urgency and impact (see above), an Urgency-Impact Matrix (also referred to as Incident Priority Matrix) can be used to define priority classes, identified in this example by colors and priority codes:
Impact | ||||
---|---|---|---|---|
H | M | N | ||
Urgency | H | 1 | 2 | 3 |
M | 2 | 3 | 4 | |
L | 3 | 4 | 5 |
Priority Code | Description | Target Response Time | Target Resolution Time |
---|---|---|---|
1 | Critical | Immediate | 1 Hour |
2 | High | 10 Minutes | 4 Hours |
3 | Medium | 1 Hour | 8 Hours |
4 | Low | 4 Hours | 24 Hours |
5 | Very low | 1 Day | 1 Week |
Circumstances that warrant the Incident to be treated as a Major Incident
Major Incidents call for the establishment of a Major Incident Team and are managed through the Handling of Major Incidents process.
Indicators
The above prioritization scheme notwithstanding, it is often appropriate to define additional, readily understandable indicators for identifying Major Incidents (see also the comments below on identifying Major Incidents). Examples for such indicators are:
- Certain (groups of) business-critical services, applications or infrastructure components are unavailable and the estimated time for recovery is unknown or exceedingly long (specify services, applications or infrastructure components)
- Certain (groups of) Vital Business Functions (business-critical processes) are affected and the estimated time for restoring these processes to full operating status is unknown or exceedingly long (specify business-critical processes)
Identifying Major Incidents
It is not easy to give clear guidelines on how to identify major incidents although the 1st Level Support often develops a "sixth sense" for these. It is also probably better to err on the side of caution in this respect.
A Major incidents tend to be characterized by its impact, especially on customers. Consider some examples:
- A high speed network communications link fails and part of or all data communication to and from outside the organization is cut off.
- A website grinds to a halt because of unexpected heavy demand prior to a deadline (for example to reserve tickets or make a legal submission) resulting in large numbers of customers failing to meet that deadline.
- A key business database is found to be corrupted.
- More than one business server is infected by a worm.
- The private and confidential information of a significant number of individuals is accidentally disclosed in a public forum.
Note also that all disasters (covered by the IT Service Continuity Strategy and underpinning ITSCM Plans) are Major Incidents and that smaller incidents that are compounded by errors or inaction can become major incidents.
Major Incidents - Key Characteristics
Some of the key characteristics that make these Major Incidents are:
- The ability of significant numbers of customers and/or key customers to use services or systems is or will be affected.
- The cost to customers and/or the service provider is or will be substantial, both in terms of direct and indirect costs (including consequential loss).
- The reputation of the Service Provider is likely to be damaged.
AND
- The amount of effort and/or time required to manage and resolve the incident is likely to be large and it is very likely that agreed service levels (target resolution times) will be breached.
A Major Incident is also likely to be categorized as a critical or high priority incident.