If the first twenty minutes of an incident go to arguing whether it is a Level 2 or a Level 3, your crisis severity levels have already failed. Severity levels exist to end that debate, not start it.
We see the symptoms in almost every program we assess. Confusing severity levels. Two crisis plans with different scales. A crisis team that activates for things a site manager should handle, and sits out the events that actually threaten the company.
One security leader asked us the question that sits underneath all of it: “Would the passing of a CEO or any executive actually constitute a crisis?” If your severity levels cannot answer that in a minute, they need to be rebuilt.
Why Crisis Severity Levels Break
- They are defined by event type, not impact. “Cyber incident = Level 3” ignores that a phishing email and a ransomware outage are both cyber incidents.
- There are too many levels. Five levels with fine distinctions are impossible to apply under pressure. People remember three.
- The levels do not trigger anything. If a level does not change who is notified, who leads, and which team activates, it is a label, not a tool.
- Every plan has its own scale. IT uses SEV1 to SEV4, emergency management uses another scale, and the crisis plan uses a third. Nobody knows how they connect.
- Nobody practices classifying. Teams rehearse the response but never rehearse the decision that starts it.
| Old View | New View |
| Severity is defined by the type of event | Severity is defined by the impact on people, operations, customers, and the company |
| More levels mean more precision | Three or four levels mean faster, more consistent decisions |
| The level describes the situation | The level triggers specific actions |
| Each function keeps its own scale | One enterprise scale, with IT and site scales mapped to it |
| Escalation is a judgment call | Escalation criteria are written down, and doubt means escalate |
How to Design Crisis Severity Levels That Work
1. Use three or four levels, no more
Three levels cover most organizations: an incident the business handles, a serious event the crisis team watches, and a crisis the crisis team runs. Add a fourth only if you have a real need, such as a distinct level for events that threaten the whole enterprise.
2. Define each level by impact, not event type
Write the criteria in terms of what is affected, so any event can be classified:
- People: injuries, threats to safety, large numbers of employees affected
- Operations: critical services down, and for how long
- Customers: how many, and how badly
- Reputation: media, social, or regulator attention, or the potential for it
- Financial and legal: material loss, regulatory notification, litigation exposure
3. Tie every level to actions
Each level should answer four questions: who is notified, who leads, which team activates, and how often the team updates leadership. Here is a simple model you can adapt:
| Level | What it looks like | Who leads | What happens |
| 1: Incident | Contained to one site or function; no material impact on customers or reputation | Site or business unit leader | Handled under local procedures; crisis program lead informed |
| 2: Serious | Could escalate: multiple sites, a critical service at risk, early media or regulator interest | Crisis program lead | Crisis team notified and on standby; executive sponsor briefed; situation reports on a set cadence |
| 3: Crisis | Material threat to people, operations, customers, reputation, or finances | Crisis team leader, with executives | Crisis team activated; executives engaged; communications and stakeholder plans in motion |
4. Map IT incident severity to crisis levels
This is the gap most organizations miss. IT and security teams run their own incident severity levels, usually SEV1 to SEV4, and they are good at it. But a SEV1 is not automatically a crisis, and some crises start as a SEV3.
Write the bridge down. For example: a SEV1 escalates to crisis Level 2 when a customer-facing service is down for more than a set number of hours, when regulated data may be involved, or when the outage becomes visible to customers or media. A ransomware event goes straight to Level 3. The point is that the security team should never have to guess when to call the crisis team.
5. Make “when in doubt, escalate” the rule
Escalating and then standing down costs an hour of a few people’s time. Escalating late costs far more. Write the rule into the plan, and make sure nobody is criticized for escalating an event that turns out to be small.
6. Use one scale across every plan
Emergency management, IT disaster recovery, crisis communications, and the crisis plan should all point to the same enterprise levels. If you have two crisis plans with different scales, consolidating the scales is often the fastest way to start consolidating the plans.
Practice the Decision, Not Just the Response
Here is a quick drill that exposes ambiguous severity levels in about thirty minutes. Write ten short scenarios: a regional power outage, an executive’s sudden death, a data exposure affecting a few hundred customers, a viral social media complaint, a SEV1 outage of your customer portal. Hand them to your crisis team members and have each person classify every scenario independently.
Then compare answers. Every scenario where the team disagrees is a gap in your criteria. Fix the wording, and run it again in six months. It is the cheapest exercise you will ever run, and one of the most revealing.
For a deeper test, build a severity decision into your next tabletop exercise. (If you are hiring outside help, here is how to choose a tabletop exercise facilitator.)
Common Failure Modes
- The levels live in an appendix. If the definitions are not on the first page of the plan, nobody will find them during an event.
- Only the crisis team knows the scale. The people who see events first, such as site leaders, the security operations center, and the IT service desk, need the escalation criteria most.
- The scale was never tested. A severity model that has not been used in an exercise is a draft.
- Severity becomes political. Leaders downgrade events to avoid looking alarmed. Clear, impact-based criteria take the politics out.
Where to Start
- Count your scales. List every severity or level system in every plan. If there is more than one, you have found your first fix.
- Rewrite the definitions around impact, in three levels, with actions tied to each.
- Run the classification drill with your crisis team and the people who see events first.
If you want a head start, our Crisis Management Plan Templates include an initial crisis assessment worksheet and team roles you can adapt, for $299.99. If the bigger problem is overlapping plans and teams, our Crisis Management services consolidate them into one framework, and Resilience as a Service runs that program day to day with severity levels people can actually use.
The right severity level is the one your team can agree on in a minute and act on in five.
Keep Going
A few ways to go deeper if this was useful.
- Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Crisis Management.
- Simplify your crisis program. Our Crisis Management services replace overlapping teams and competing plans with one framework your executives understand.
- Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap.
- Talk to us. Set up a call to think through your severity levels with us.
