Severity vs Priority in IT Incidents: How the Impact and Urgency Matrix Works

The short version: Severity describes how serious an incident is. Priority decides the order in which incidents are worked and how fast they must be answered. Severity is usually a fact about the damage; priority is a decision that combines impact, urgency and business context. Most service desks calculate priority from an impact and urgency matrix, then let a named person override it when the situation needs it.

Two words cause a surprising amount of friction on IT service desks. A customer says a problem is "critical", the engineer says it is "low severity", and the ticket sits in a queue while both are, in their own terms, right. The confusion comes from treating severity and priority as the same dial. They are two different questions, and a support process works much better when it asks both and records both.

This guide explains the difference in plain terms, shows how the impact and urgency matrix turns two simple judgements into a priority, and walks through a published example. The example is the matrix on Brocent's own SLA page, which we checked on 28 October 2026. It also includes worked scenarios, a list of the places where a matrix goes wrong, and a short rollout plan you can adapt for an in-house team or for a managed IT provider.

What is the difference between severity and priority?

Severity answers "how bad is it?" Priority answers "what do we do first, and how quickly?"

Severity describes the size of the problem itself. It looks at what is broken, how many people or systems are affected, and whether data, security or revenue is at risk. Severity is normally set when the incident is first understood and changes only if the facts change, for example when an engineer discovers that a fault is wider than it first looked.

Priority describes the order of work. It starts from the same facts but adds time and context: is there a deadline, is the workaround acceptable, is it month-end, is the person affected a single user or the whole finance team? Priority can move up or down during the life of an incident without the severity changing at all.

A simple way to hold the two apart:

• Severity is the diagnosis. A doctor can say an injury is serious without yet knowing the queue in the waiting room.
• Priority is the triage order. The queue depends on the diagnosis, but also on who is waiting, what resources are available and how urgent each case is.

Both terms are used across the industry, and not everyone uses them in exactly the same way. Atlassian's incident management guide to severity levels, which we read on 28 October 2026, uses "SEV" levels for the seriousness of an incident (SEV 1 is a critical incident with very high impact, SEV 3 a minor incident with low impact) and says the vital thing is to understand your own business and choose severity and priority definitions that work for you. ITIL-style service desks tend to use "priority" as the headline field and derive it from impact and urgency. Neither usage is wrong. What matters is that your team writes down which word means what, and uses it the same way every time.

Why keep severity and priority separate?

If the two were always identical there would be no reason to keep both. They diverge often enough in practice that merging them causes real mistakes.

1. A severe problem can be low priority. A fault that would be serious if it spread, but which is currently contained, has a working workaround and affects a system nobody needs until next week, can wait for a planned change window.
2. A minor problem can be high priority. A broken login for one person is a small fault. If that person is about to present to a customer in an hour, the deadline changes the order of work even though the fault itself has not got worse.
3. Different people own each field. The engineer who understands the fault usually judges severity. The service owner or the person who understands the business deadline judges urgency. A single field forces one person to guess the other's half.
4. Reports need both. If you track only priority, you cannot tell whether a spike in P1 tickets means the infrastructure is failing or that people have learned to shout. Tracking severity alongside priority separates those cases.

What are impact and urgency?

The impact and urgency matrix is built from two inputs. Both are judgements about the business, not about the technology.

Impact is the extent of the effect. It asks how many people, systems, sites or business processes are affected, and how badly. Typical wording runs from "whole company" down to "single user, workaround available".

Urgency is the time pressure. It asks how quickly the effect will get worse, or how soon the business needs the service back. A broken system with an obvious workaround has lower urgency than the same system on the day a payroll run is due.

The ITIL framework, the best known set of IT service management practices, is widely taught as describing priority as the combination of these two. We did not re-read the paid ITIL publications for this article, so we present this as common practice rather than a quotation. If your organisation is building a formal process around ITIL, check the wording in the official ITIL guidance.

How do you define impact levels?

Four levels are enough for most small and mid-size organisations. Use wording your service desk can apply in under a minute.

1. Critical impact: a business-wide or customer-facing service is down, or a security or data-loss event is in progress.
2. Serious impact: a department, a site or an important system is unavailable or badly degraded.
3. Medium impact: a group of users or one non-critical system is affected, and work can continue in a reduced way.
4. Minor impact: one user or a cosmetic or low-value feature is affected.

How do you define urgency levels?

Urgency is the harder one to write down, because it depends on timing. Four levels again work well.

1. Critical urgency: work has stopped now, or will stop within the hour, and there is no workaround.
2. High urgency: the effect will get worse within the working day, or a deadline falls today.
3. Medium urgency: the effect can wait a few days, or a workaround is available.
4. Low urgency: no deadline applies and the effect is not getting worse.

How does the impact urgency matrix produce a priority?

The matrix is a lookup. You choose the impact level, choose the urgency level, and read off the priority. Training material usually draws this lookup as a grid, which leads people to think the matrix needs a table. It does not. It is a set of simple rules, and you can write the whole thing as headings and numbered lists, which is how we show it here.

The method has three steps:

1. Decide the impact level, using the definitions above.
2. Decide the urgency level, using the definitions above.
3. Look up the intersection and set the priority field. If a named person judges that the result is wrong, they may override it and must record the reason.

Many teams add a rule that the person who raises the ticket never sets the priority directly. They describe the effect and the deadline, and the service desk applies the matrix. This avoids the situation where every ticket arrives marked urgent.

What does a published incident priority matrix look like?

Brocent publishes its matrix on the SLA page, so you can see a real one rather than an invented example. The page, which we checked on 28 October 2026, describes the priority as being determined by combining business impact and urgency, and says the service desk applies the matrix when triaging each incoming ticket. The business impact levels are Critical, Serious, Medium and Minor, and the urgency levels are Critical, High, Medium and Low.

Here is how the published matrix reads, one impact level at a time.

When business impact is Critical

1. Urgency Critical gives priority P1.
2. Urgency High gives priority P1.
3. Urgency Medium gives priority P2.
4. Urgency Low gives priority P4.

When business impact is Serious

1. Urgency Critical gives priority P1.
2. Urgency High gives priority P2.
3. Urgency Medium gives priority P3.
4. Urgency Low gives priority P4.

When business impact is Medium

1. Urgency Critical gives priority P2.
2. Urgency High gives priority P2.
3. Urgency Medium gives priority P3.
4. Urgency Low gives priority P4.

When business impact is Minor

1. Urgency Critical gives priority P2.
2. Urgency High gives priority P3.
3. Urgency Medium gives priority P3.
4. Urgency Low gives priority P4.

Two details are worth noticing. First, urgency can raise priority even when impact is small: a minor-impact issue with critical urgency becomes P2, not P4. Second, low urgency caps everything at P4 in this matrix, because without time pressure the work can be scheduled.

The same SLA page also lists a fifth level, P5, for routine requests that are not incidents at all, such as a new installation, an offboarding task or a password reset. Those are service requests rather than faults, so they sit outside the impact and urgency matrix.

What response times go with each priority?

A priority is only useful if it carries a commitment. On the same SLA page, Brocent publishes first-response, remote-support and on-site or resolution targets for each level. For P1 and P2 the first response is 15 minutes, and for P3 it is 30 minutes. P4 and P5 have 60 minutes. These are first-response times, not fix times, and they depend on the service window: a standard 8x5 window covers nine business hours a day from Monday to Friday, while a premium 24x7 window applies around the clock. The page notes that response times are subject to the contract terms.

Our P1 response time is public, so you can check it on the SLA page and on the managed IT support plans and per-user pricing before you speak to anyone. For a plain-language walkthrough of the four levels and what each one promises, read our companion article on P1 to P4 priority levels in an IT support SLA.

Worked examples: severity and priority side by side

The scenarios below are illustrative, not real client cases. They show how the same matrix handles different situations, and how severity and priority differ in each.

1. Email is down for the whole company on a Monday morning. Impact is Critical, urgency is Critical. The matrix gives P1. Severity is also at the top of whatever scale you use. Everyone works on this first.
2. The finance system is very slow for the finance team two days before month-end. Impact is Serious, urgency is High. The matrix gives P2. Severity might be rated medium by the engineer because the system still works, but the month-end deadline lifts the priority.
3. One user cannot print before a meeting tomorrow. Impact is Minor, urgency is High. The matrix gives P3. Severity is low and the priority is middle of the range.
4. A software licence needs renewing next quarter. Impact is Minor, urgency is Low. The matrix gives P4, and the ticket is scheduled.
5. A contained fault on a spare server with a working failover. Severity might be rated serious in the engineer's notes, because the fault could spread if the failover were also lost. Impact today is Minor and urgency is Low, so the matrix gives P4. A change window is booked and the severity stays recorded.

Scenario 5 is the one that shows why both fields earn their place. If the team had only a priority field, the record would say "low" and the risk would be forgotten.

When should a person override the matrix?

No matrix covers every case. A good process lets a named role override the calculated priority, and requires them to write down why. Reasonable grounds for an override include:

1. A security signal. An account that is behaving like a compromised account can deserve a higher priority than its apparent impact suggests.
2. A fixed external deadline. If the business must file or deliver by a set time, raise urgency.
3. A repeating fault. Five P4 tickets about the same cause are one bigger problem, and should be handled as a problem record, not as five small ones.
4. A failed workaround. If the workaround stops working, urgency has changed even though nothing else has.
5. A sensitive role. Some roles, such as those handling payments on a fixed schedule, tolerate less disruption than the headcount alone suggests.

Keep overrides rare. If more than a small share of tickets are being overridden, the definitions are wrong and should be rewritten, not patched case by case.

How should you roll out a priority matrix?

You can set this up in an afternoon, and refine it over the first month. This plan suits an internal IT team of any size, and it is also what you should ask a managed provider to show you.

1. Write the four impact definitions and four urgency definitions in your own words, with one example each.
2. Write the matrix as lists, one heading per impact level, and keep it on one page that every agent can see.
3. Attach a response target to each priority, and state whether it is measured in business hours or clock hours.
4. Decide who may override and require a reason in the ticket.
5. Add a separate severity field if you want to report on the seriousness of incidents, and define its scale (for example three or four levels).
6. Review after a month. Look at the tickets that were overridden or reopened and adjust the definitions.
7. Teach requesters to describe, not to rate. Give them a short form that asks what is affected and what deadline applies.

What should you ask an IT provider about severity and priority?

If you buy managed IT, the contract will contain priority levels, and the quality of the definitions tells you a lot about how the service runs. Useful questions:

1. Which words does the contract use, and are severity and priority separate?
2. Who sets the priority, the requester or the service desk?
3. Is the matrix published, and can you see it before you sign?
4. What are the first-response and resolution targets for each level, and in which hours do they apply?
5. Who can override a priority, and is the reason recorded?
6. How are priorities reported back to you each month?

For help setting these out in a contract, see our overview of 24x7 help desk IT support, or talk to us about your own service levels.

Frequently asked questions

What is the difference between severity and priority in one sentence?

Severity measures how serious an incident is; priority sets the order and speed of the response, based on impact, urgency and context.

Is P1 the same as SEV 1?

Not necessarily. Both usually mark the top of their scale, but SEV levels normally describe seriousness while P levels normally describe the order of work. Some teams use one scale for both. If you do, define it clearly and apply it consistently.

What is an impact and urgency matrix?

It is a lookup rule that combines two judgements, the extent of the business effect and the time pressure, to produce a priority. It can be written as a table or, as in this article, as headings and numbered lists.

Who should decide the priority of a ticket?

The service desk, using the agreed matrix. The requester describes the effect and any deadline. A named role can override the result, and the reason should be written in the ticket.

How many priority levels do I need?

Four incident levels, plus a separate level for routine requests, cover most organisations. More levels make agents hesitate and produce inconsistent choices.

Can a priority change during an incident?

Yes. If the effect spreads, a workaround fails or a deadline appears, the priority should be raised and the change recorded. If a workaround is found, it can be lowered.

Does ITIL require the impact and urgency matrix?

ITIL guidance commonly describes priority as a function of impact and urgency, but it is a framework of practices, not a rulebook you must copy exactly. Adapt the levels to your own business.

Where to go next

To see how severity and priority fit into the wider support process, read our guides to L1, L2 and L3 support levels and to the IT escalation matrix template. For the contract side, see what an SLA means in IT support.

*Sources checked 28 October 2026: Brocent SLA page (brocent.com/sla); Atlassian incident management guide, severity levels page (atlassian.com/incident-management/kpis/severity-levels).*

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.