Agree the Severity Scale Before You Need It

Ask five people in an incident whether it is serious and you will get five answers, each anchored to what the incident means for their team. Engineering sees a contained technical issue. Sales sees a customer promise at risk. The CEO sees the news cycle. Everyone is right, which is the problem.

A severity scale settles the argument before it starts. It converts the facts of the incident into a level, and the level into a predefined set of actions: who leads, who is informed, what gets paused, and how much discretion the response team has.

The scale is short, agreed in advance, and written in business language. Its job is not to be precise. Its job is to make the first hour boring.

Key takeaways

• Severity levels exist to trigger pre-agreed actions, not to describe technical detail.

• Three or four levels are enough; more levels mean more arguing at the boundary.

• Define each level by business impact: customers, data, operations, legal exposure, reputation.

• Name who can declare each level and who can stand the response down.

• Revisit the scale after every incident and every tabletop.

Step 1: Write levels in business language

Each level should describe impact a non-technical leader can recognize: how many customers, which data, what operations, for how long. If a level requires understanding the attack technique to apply, it will not survive contact with a real incident.

This fictional example shows a four-level scale for a mid-market company. It is an illustration, not a prescription.

Level	Business meaning	Example
S4	Routine, no customer or data impact	Blocked phishing campaign, single infected laptop rebuilt
S3	Limited internal disruption or unconfirmed exposure	Malware contained to one site, vendor reports possible issue
S2	Customer impact or confirmed data access	Service degraded for a region, confirmed access to a customer data set
S1	Business-threatening	Ransomware across production, regulator-notifiable breach

Step 2: Attach actions to each level

A level without attached actions is a label, not a tool. For each level, pre-agree who leads the response, who is informed and how fast, what authority the team has, and what gets paused.

The pattern to copy is the pairing: S2 might mean the response lead has spending authority up to a set amount, executives are briefed within two hours, and the communications plan opens at the customer section. S1 means the full escalation, including the board chair on the timeline the company already agreed.

The escalation trigger list discussion covers the board-facing half of this pairing.

Step 3: Name the declarer and the stand-down

Deciding the level is itself a decision, and it needs an owner. Typically the response lead declares S3 and S4, and an executive declares S2 and S1. Write down who can raise the level and who can lower it, because the pressure to downgrade a bad situation is real.

Stand-down matters as much as declaration. Ending the formal response releases the pause on normal work and starts the review clock. Make it explicit, and make it the same person who declared the level or their peer.

Step 4: Test the scale in every tabletop

The first time the scale is used should not be in a real incident. In every tabletop exercise, force the room to declare a level in the first ten minutes and defend it. The arguments that surface are exactly the ambiguities to fix in the document.

Expect the scale to drift as the business changes. New products, new data, and new regulations all move the boundaries. A scale reviewed once a year stays usable; one written once becomes shelf-ware.

The thinking behind service impact tolerances pairs naturally with severity levels: one says how much disruption the business absorbs, the other says what to call it when it happens.

The related discussion of service impact tolerances is worth your time alongside this one. The related discussion of escalation trigger list is worth your time alongside this one.

Frequently asked questions

How many severity levels should we have?

Three or four. Two is too coarse to drive different actions; six guarantees boundary arguments. The test is whether each level triggers a meaningfully different response.

Who writes the severity scale?

The security or response lead drafts it, but the business signs it. The scale encodes judgments about customer impact and downtime that only the business can make.

What if an incident sits between two levels?

Declare the higher one. Over-declaring costs some hours of extra attention; under-declaring costs the hours you cannot get back. The stand-down mechanism exists precisely to correct an over-call cheaply.

A Defensible Next Step

Pull up your incident plan and look for the severity definitions. If they are missing, or written in technical jargon, schedule one working session to write four levels in business language. Book a Decision-Clarity Call if you want a facilitator for it.