Incident Management Process

Incident severity classifier

Five questions, one illustrative priority, and every rule shown. Use it as a quick second opinion during triage or as a starting point for writing your own severity policy.

Privacy: Your answers stay in this page. Nothing is sent or stored, and the result is gone when you restart or leave.

0 of 5 answered

1. What is the service impact right now?

Describe what users experience, not what you suspect the cause is.

2. How broad is the affected audience?

Count the people or customers affected, internal or external.

3. Is a safe workaround available?

A workaround counts only if affected users can actually use it today without new risk.

4. Is a security, privacy, physical safety or regulated-data exposure suspected?

Answer yes or unsure on any reasonable suspicion. This triggers human review, not an automatic verdict.

5. How time-sensitive is this incident?

Consider deadlines and whether harm grows or becomes irreversible while you wait.

Result

Answer all five questions to see an illustrative priority. 5 remaining.

How classification works

Illustrative policy version 1.0.0, dated 2026-10-18. It is deterministic: the same answers always give the same result. The rules apply in this order:

Step 1: base priority by impact and breadth
Impact \ BreadthMost or allSubstantial segmentLimited or internalIsolated
Complete outageP1P1P2P3
Severe degradationP2P2P3P3
Limited degradationP3P3P4P4
No current impactP4P4P4P4
  1. Workaround can lower priority. Any workaround moves P1 to P2, because P1 here means no safe workaround. An effective workaround lowers P2 or P3 by one level, but a complete outage or severe degradation is never placed below P3.
  2. Urgency can raise priority. A business-critical deadline or irreversible risk raises an outage or severe degradation to P1, and anything else to at least P2. An urgent production disruption is at least P3. Urgency is applied after the workaround, so conflicting signals resolve toward escalation.
  3. Security, privacy, safety or regulated-data suspicion. A yes or unsure answer shows an escalation banner and marks the priority as preliminary. It does not, by itself, change the operations priority or assert that a breach happened. That judgment belongs to people.

Every one of the 576 possible answer combinations is covered by automated tests, including checks that making any single answer worse never lowers the priority.

Adapting it for your organization

Most organizations change the base table and the floors. Write your version down, include examples for each level, and agree it with whoever acts as incident commander and with your security team. The template packs include an editable severity assessment worksheet.

Frequently asked questions

Is P1 the same as SEV1?

In this illustrative policy they map one to one. Many organizations use only one scale, or define them differently. Use whichever your team already understands.

Is this an ITIL or NIST severity scale?

No. Neither publishes a universal mapping like this. It is an example policy written for this site. NIST SP 800-61 Rev. 3 is about cybersecurity incident response, not IT operations priority.

Why does a security suspicion not raise the priority automatically?

Because suspicion is not a finding. The policy escalates to specialists immediately and marks the result as preliminary, so humans decide severity with the full picture.

Should we re-run the classifier as the incident evolves?

Yes. Impact, breadth and workarounds change. Reassess at each update and say when priority changes and why.

Sources

  1. NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (accessed 2026-10-18)

Links point to the original publishers. Citing a source does not mean that publisher reviewed or endorses this site.