Two people log the same outage. One calls it "critical," the other calls it "medium." Both are guessing, because nobody defined what those words mean. Inconsistent classification is the quiet failure that makes incident data useless: you cannot prioritise, route or trend events you cannot reliably label. This tutorial walks through how to classify an incident properly, by severity, by priority, and by type, with criteria concrete enough that two reasonable people reach the same answer.
What You'll Learn
You will learn the difference between severity, priority and type; how to build a severity scale and a priority matrix with concrete criteria; how to classify at intake versus after investigation; and how to keep classification consistent across a whole team.
The Three Dimensions of Classification
People often collapse "classification" into a single label, but it really has three distinct dimensions, and confusing them is the root of most inconsistency:
- Type answers "what kind of incident is this?" It covers IT, security, privacy, safety, fraud, and operational, and it determines who handles the incident.
- Severity answers "how bad is the impact?" It is measured against objective criteria like data exposed, customers affected, or money lost, and it is a property of the event.
- Priority answers "how urgently must we act?" It is a function of severity and urgency together, and it determines response order.
You need all three because they drive different decisions. Type routes the incident to the right experts; severity tells you how serious it is for reporting and trending; priority tells your responders what to work on first.
Building a Type Taxonomy
A type taxonomy is your list of incident categories. You are aiming for mutual exclusivity, so an incident falls cleanly into one bucket, and coverage, so every realistic incident has a home. Keep it short, roughly 8 to 12 top-level types, with optional sub-types underneath.
| Type | Example sub-types | Typical owner |
|---|---|---|
| IT / availability | Outage, degraded performance, failed deployment | Platform / SRE |
| Security | Malware, unauthorised access, phishing | Security team |
| Data / privacy | Data breach, accidental disclosure, loss of device | Privacy / DPO |
| Safety | Injury, near-miss, hazardous condition | Health & safety |
| Fraud / financial | Internal fraud, payment fraud, reconciliation error | Finance / forensics |
| Operational | Process failure, supplier failure, human error | Business unit |
| Compliance | Breach of obligation, missed filing, control failure | Compliance |
Pro Tip
If responders constantly argue about which of two types applies, your taxonomy overlaps. Either merge the two types or write a one-line rule that decides ties (for example, "any incident involving personal data is classified Data/privacy first, regardless of root cause").
Want the full framework with worked examples?
Defining a Severity Scale
Severity measures impact, and it has to be anchored to objective criteria, or it collapses into gut feel. A four- or five-level scale is standard. The art is in the descriptors: write them so the label is almost automatic once you know the facts.
| Level | Label | Impact criteria (any one applies) |
|---|---|---|
| Sev 1 | Critical | Core service down for all users; confirmed breach of sensitive data; serious injury; major regulatory or financial exposure |
| Sev 2 | High | Major function impaired; significant subset of customers affected; suspected data exposure; meaningful financial loss |
| Sev 3 | Medium | Limited impact with a workaround; small number of users affected; contained, no data loss |
| Sev 4 | Low | Minimal impact; cosmetic or single-user issue; near-miss with no harm |
Notice the "any one applies" rule: an incident is rated at the highest severity for which a single criterion is met. This prevents the common trick of talking an incident down because "only" one dimension was serious.
From Severity to Priority
Severity alone does not tell responders what to do first, because a high-severity issue that is already contained may be less urgent than a medium one that is actively spreading. Priority combines severity (how bad) with urgency (how fast it is escalating, or how time-sensitive the fix is). A simple matrix does the job:
| Severity \ Urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| Sev 1 (Critical) | P1 | P1 | P2 |
| Sev 2 (High) | P1 | P2 | P3 |
| Sev 3 (Medium) | P2 | P3 | P4 |
| Sev 4 (Low) | P3 | P4 | P4 |
Priority then drives concrete commitments: a P1 might require immediate response and triggers escalation, while a P4 can wait for the next working day. Tie each priority to a target response time so the label means something operationally.
Writing Good Impact Criteria
Severity is only as reliable as the criteria behind it. Vague criteria ("significant impact") just move the argument from the label to the definition. Make criteria measurable across the dimensions that matter to your organization:
- Customers / users affected: none, a few, a significant subset, all.
- Data: none, internal only, confidential, sensitive or regulated personal data.
- Financial: bands aligned to your risk impact scale so incidents and risks speak the same language.
- Duration / availability: minutes, hours, or days of disruption.
- Safety / harm: near-miss, first aid, serious injury.
- Regulatory: none, internally reportable, or externally reportable to a regulator.
Important
Align your incident impact bands with your risk register's impact scale. If a "Major" risk impact is a loss between R1m and R10m, a "High" severity incident should sit in the same band. Otherwise your two systems describe the same money with different words and cannot be reconciled.
Classifying at Intake vs After Investigation
Classification happens twice, and conflating the two stages causes a lot of confusion.
At intake (provisional)
When an incident is first logged you rarely know the full picture, but you have to act anyway. Assign a provisional type, severity and priority based on what is known and observable. Err on the side of higher severity at intake; it is cheaper to stand down an over-classified incident than to discover too late that a "minor" event was a major breach.
After investigation (confirmed)
Once root-cause analysis is done and the true impact is known, reclassify with confidence. The confirmed severity is what feeds your trends and reporting; the intake severity is useful only for measuring how good your early triage is.
Reclassification in action
Intake: A help-desk ticket reports "a few users can't access the reporting dashboard." Provisional: Type = IT/availability, Severity = Sev 3 (Medium), Priority = P3.
Investigation: The team discovers the dashboard was exposing another tenant's data due to a broken access check. The real issue is unauthorised data access, not availability.
Confirmed: Type = Data/privacy, Severity = Sev 1 (Critical), Priority = P1, regulatory-reportable flag set. The provisional and confirmed records are both kept, showing that early triage under-rated this incident, which is useful feedback for improving intake.
Keeping Classification Consistent
Even with good criteria, consistency takes deliberate effort:
- Calibrate with examples. Maintain a short library of past incidents with their agreed classifications. New responders learn faster from worked cases than from definitions.
- Use decision aids. A simple flowchart or set of yes/no questions at intake removes guesswork.
- Review a sample. Periodically have a second person re-classify a handful of recent incidents. Disagreements reveal where your criteria are ambiguous.
- Lock the vocabulary. Use drop-downs, not free text, so people pick from the agreed set.
Common Mistakes to Avoid
1. Confusing severity with priority
Severity is how bad; priority is how urgently to act. A contained critical incident can be lower priority than a spreading medium one. Keep them as separate fields.
2. Vague impact criteria
"Significant impact" is not a criterion. Make criteria measurable across users, data, money, duration and harm, so the label is almost mechanical.
3. Never reclassifying
The intake guess is not the final answer. Confirm classification after investigation, or your trends are built on first impressions.
4. Too many types
Thirty overlapping categories guarantee inconsistency. Keep top-level types under a dozen with clear tie-break rules.
5. Misaligned with the risk scale
If incident impact bands do not match your risk scoring scale, you cannot connect incidents to risks meaningfully.
Summary
- Classification has three dimensions: type (what kind), severity (how bad), and priority (how urgent).
- Build a short, mutually exclusive type taxonomy with clear tie-break rules.
- Anchor severity to objective, measurable criteria and rate at the highest level any single criterion meets.
- Derive priority from severity plus urgency using a simple matrix, and tie each priority to a response-time target.
- Classify provisionally at intake (erring high), then confirm after investigation, and keep the vocabulary controlled for consistency.
Frequently Asked Questions
What is the difference between severity and priority?
Severity measures how bad the impact is and is a property of the event. Priority measures how urgently you must respond and combines severity with urgency. Two incidents can share a severity but have different priorities depending on how fast each is escalating.
How many severity levels should I use?
Four or five levels work well for most organizations. Fewer than four loses useful distinction; more than five makes the boundaries hard to apply consistently. The number matters less than having clear, measurable criteria for each level.
Should I classify before or after investigating?
Both. Assign a provisional classification at intake so the incident can be actioned, then confirm it after root-cause analysis reveals the true impact. The confirmed classification is what feeds reporting and trends.
What if an incident fits more than one type?
Define tie-break rules in advance. For example, any incident involving personal data is classified as Data/privacy first. Pick the primary type for routing and reporting, and use tags or sub-types to capture the secondary aspects.
Should incident severity match my risk impact scale?
Yes. Aligning incident impact bands with your risk likelihood and impact scoring lets you connect real incidents to the risks they relate to, so materialised events can refine your risk estimates instead of living in a separate silo.
How do I stop different people classifying inconsistently?
Use measurable criteria, controlled drop-downs, a library of calibrated example incidents, and a simple intake decision aid. Periodically have a second reviewer re-classify a sample of incidents; disagreements pinpoint where your criteria need sharpening.
Save this guide for later
Download the PDF version to read offline or share with your team.
