Incident Priority in ITIL Explained with Examples

Tagging incidents with the right priority has been a questionable topic across organizations that are practicing ITIL. No matter what the basic principles are in terms of mapping priority to incidents, there are always lingering questions whether the chosen priority is indeed the right one.

In this piece, I will provide basic tips that you can leverage on to come up with incident priorities which could be standardized across all service lines and customers.

Incident priority is mainly based on two elements – impact and urgency. Impact is the loss that the business is facing due to the incident. It could be in terms of number of users, financial losses or loss of reputation. Urgency is how quickly the business expects a resolution. So, when you map these two together across a matrix as indicated below, you will be able to determine the priority of an incident.

In the sample incident priority matrix, there are three levels of impact and three levels of urgency considered. So, according to the agreement with the customer, if we determine that the impact and urgency is high, we would plug in priority 1 for the incident and incident priority deduction is similar for the remaining elements in the matrix. You can have any number of levels of impact and urgency as you would like. A word of caution – don’t complicate matters by having too many than can be handled. Remember that the incident prioritization is done by the service desk who are junior staff.

It is critical that the various levels of impact and urgency are documented in an agreement with the customer and charged accordingly. The agreement could look something like this.

a. High impact if more than 100 users are affected, or 50% of a project team are affected

b. Medium impact if the users affected are more than 10 and not more than 100

c. Low impact if the number of users impacted is less than 10

Likewise for agreeing on urgency, the agreement could take the following shape.

a. High urgency if services ABC, ABD and XYZ are affected, or if location PQY 5^th floor is affected

b. Medium urgency if services DSD and TRS are affected, or if corporate offices are affected

c. Low urgency for the rest of the services and locations

So, when you have an agreement in black and white such as this, when an incident is received by the service desk, they can efficiently map the impact and urgency to come up with the priority of an incident.

Apart from the matrix itself, businesses have a list of special people or VIP personnel. These VIPs do not get measured on the matrix. The agreement could read that if a VIP is affected, then the priority could automatically bump up to a priority 1. There are various reasons why VIPs are given the priority override, it is not the concern of the IT service provider to question the tactics but to make sure that the VIP incident priority agreement is in place and client charged accordingly.

All the agreements aside, there may be instances when the incident needs to be bumped up to a higher priority owing to special activities for the business such as month end closing or salary disbursement cycles. So, the IT service provider’s incident management process must be flexible enough to accommodate ad-hoc priority changes as special cases. If the IT service provider experiences that these special cases are becoming a routine, get the clause added for additional work into the agreement so that the client could be charged more.