Prioritization Frameworks: SEV Levels and the Impact/Urgency Matrix

Incident Response & Ticketing Workflows

Chapter 3 · Prioritization Frameworks: SEV Levels and the Impact/Urgency Matrix

Chapter 2 established severity and priority as two separate questions. This chapter gives each one a real, concrete tool: a SEV-level ladder for severity, and an Impact/Urgency matrix for priority — used together, not as substitutes for each other.

A Concrete SEV-Level Ladder

Level	Definition
SEV1	Complete outage or critical data-loss risk, affecting most or all users — drop other work, all hands
SEV2	A major feature or function broken for a significant subset of users, without a full outage — urgent, but not an all-hands event
SEV3	A minor issue with a workaround available, limited impact
SEV4	Cosmetic or trivial, no meaningful functional impact

The exact thresholds genuinely vary by organization — a payment processor's own definition of SEV1 is stricter than a marketing blog's. The framework's real value isn't the specific numbers; it's having agreed-upon, written criteria that different people apply consistently, rather than each person's own individual gut feeling about how bad something seems.

Concrete Criteria, Not Vibes

A usable SEV definition needs checkable criteria — "affects more than 50% of users," "no workaround exists," "active data loss is occurring" — not vague language like "very bad" or "urgent." Vague criteria don't resolve ambiguity, they just relocate it: two people will still disagree about whether something counts as "very bad," exactly as they would have without a framework at all.

The Impact/Urgency Matrix: A Tool for Priority

Where SEV levels primarily encode severity, this matrix is explicitly a priority tool — crossing impact (how many people, or how much business value, is affected) against urgency (how quickly this needs resolving before it gets worse, or before a window closes). Using both frameworks together is what actually captures both of Chapter 2's own axes properly, rather than collapsing everything back into a single number.

	High urgency	Low urgency
High impact	Act now	Schedule deliberately — don't let it drift indefinitely
Low impact	Quick fix — don't let it block bigger work	Backlog

Applying Both Frameworks Together

Revisiting Chapter 2's own two tickets with both tools:

Ticket	SEV level	Impact/Urgency cell
Password reset emails failing (~5%)	SEV3	Low impact, low urgency — no reason it can't wait its turn
Footer typo before a press announcement	SEV4	Low impact, high urgency — a quick fix, not a reason to reprioritize anything else

Both tools agree on the trivial one being genuinely trivial in impact — but the matrix is what actually captures why it still needs handling within the hour, something the SEV level alone was never designed to express.

A framework is a default, not an unbreakable rule

A genuine edge case can legitimately warrant deviating from what a framework's strict criteria would suggest — but only when that deviation, and the specific reason for it, is written down explicitly, the same "documented consciously" discipline Chapter 2 required for severity/priority divergence. Two failure modes to avoid: rigidly following a framework into an obviously wrong outcome, or abandoning frameworks entirely and reverting to pure gut feeling.

A Legitimate Deviation, Documented

A bug affecting only screen-reader accessibility, with a functional visual workaround for sighted users, would classify as SEV3 by the numbers alone — a small percentage of the user base, a workaround exists. A team can legitimately choose to treat it with higher priority anyway, given a real accessibility/compliance obligation that the raw percentage-affected metric was never designed to capture — as long as that choice is written into the ticket explicitly ("prioritized above its raw SEV3 classification due to our accessibility commitment"), so anyone reading it later understands it as a deliberate decision, not confusion about how the framework works.

Hands-On Exercises

Exercise 1

Explain why this chapter says the specific numeric thresholds in a SEV-level ladder matter less than having concrete, checkable criteria at all.

📄 View solution

Exercise 2

Explain why this chapter says SEV levels and the Impact/Urgency matrix need to be used together, rather than either one alone being sufficient.

📄 View solution

Exercise 3

Explain why prioritizing the accessibility bug above its raw SEV3 classification is a legitimate framework deviation rather than a framework failure, and what condition this chapter says makes it legitimate.

📄 View solution

Chapter 3 Quick Reference

SEV1-SEV4: complete outage → major-but-partial → minor with workaround → cosmetic — exact thresholds vary by org, but must be concrete and checkable
Vague criteria ("very bad") don't resolve ambiguity — they relocate it
The Impact/Urgency matrix is explicitly a priority tool, complementing SEV levels' own severity focus
Use both together — neither alone captures both of Chapter 2's own axes
A framework is a default, not a rule — documented deviation is legitimate; silent, undocumented deviation isn't
Next chapter: The Anatomy of a Good Ticket