Severity classification — the SEV level assigned to an incident at the moment it is recognised — is one of the earliest decisions in any incident and one of the most consequential. The classification drives who gets paged, which playbooks apply, which executive layers get notified, what communications get issued, and what regulatory clocks start. Getting the classification right matters because each downstream activity is calibrated to it. Getting it wrong produces predictable failure modes: under-classification produces under-resourced response and missed obligations, over-classification produces unnecessary disruption and erodes the credibility of high-severity calls.
Why Most Severity Schemes Underperform
A typical severity scheme has five levels with descriptions like "high business impact" or "moderate customer affected." The descriptions sound precise and are operationally ambiguous — the people classifying the incident interpret them differently, and the resulting classifications are inconsistent. Strong severity schemes anchor each level to specific, measurable criteria: number of customers affected, services impacted, regulatory implications triggered, data classes involved. Anchored criteria produce consistent classification; descriptive criteria produce variation that depends on who classifies.
Multi-Dimensional Severity
A single severity number tries to compress multiple dimensions into one. An incident affecting many customers with low impact is different from an incident affecting few customers with severe impact. A privacy incident has different urgency curves than an availability incident. Strong schemes either use multi-dimensional classification (impact severity, scope, urgency as separate axes) or define the single severity number explicitly against the highest dimension. The discipline matters because it produces classifications that route the right response to the actual incident shape.
Initial Classification vs Standing Classification
The classification at the moment the incident is recognised is rarely the final classification. Incidents develop — scope expands, impact becomes clearer, regulatory implications emerge. Strong schemes distinguish between initial classification (based on what is known at the time) and standing classification (updated as the picture clarifies). Initial under-classification is sometimes appropriate because the scope is genuinely unclear; failing to update classification as the picture clarifies is rarely appropriate. The discipline of revisiting classification deliberately at defined points in the response cycle prevents the "first call sticks" pattern that produces stale severities.
A pattern in post-incident reviews: the severity was set at SEV-2 in the first hour based on initial scope, the scope expanded to SEV-1 territory by hour three, but the SEV-2 classification carried through the rest of the incident because nobody explicitly re-classified. The response was sized for SEV-2; the actual impact justified SEV-1. The classification discipline gap is the explicit decision point that nobody made. Building "do we still believe this is SEV-X?" into the response cadence at defined intervals prevents this pattern.
Calibrating Definitions Through Actual Incidents
Severity definitions written in isolation rarely match how incidents actually unfold. The strongest severity schemes are calibrated against actual incident history — what would have been classified as SEV-1 versus SEV-2 in past incidents, were the classifications right in retrospect, what would the right thresholds have been. Periodic calibration sessions that walk through past incidents and re-classify them with the current scheme produce both better schemes and stronger team alignment on what the levels mean.
The Regulatory Dimension
Several regulatory regimes now have specific incident classification requirements that map to notification obligations — NIS2 has thresholds for what constitutes a "significant" incident requiring 24/72-hour reporting. DORA has thresholds for "major" ICT-related incidents. SEC disclosure rules require "material" cybersecurity incident reporting. Internal severity classification needs to map cleanly to these regulatory definitions, or the response runbook has to perform the translation in real time during an incident. The translation is more reliable if it is built into the classification scheme rather than left to runtime judgement.
Components of a Classification Scheme That Holds Up
- Anchored criteria — specific, measurable conditions per severity level
- Multi-dimensional or explicit highest-axis methodology
- Defined initial vs standing classification with explicit re-evaluation points
- Mapping to regulatory definitions where applicable, built into the scheme
- Calibration sessions against historical incidents to refine the scheme over time
- Training for the people who classify so application is consistent across the team
- After-action review of whether classification was right in retrospect
Why Classification Discipline Compounds
A team that classifies consistently produces incident response that is consistently appropriate to incidents. A team that classifies inconsistently produces variable response quality regardless of the underlying response capability. The investment in classification discipline — anchored criteria, calibration, training, post-incident review — is relatively small and produces durable improvement in response outcomes. It is one of the most under-rated investments in incident response programmes, and one of the highest-leverage ones available.