Incident Severity Classification Matrix Template: Rating and Escalating Incidents

When every incident is "high", nothing is, and the incidents that need an executive at 2am wait in the same queue as a single phished mailbox. NIST SP 800-61 Rev. 3 is explicit that incidents should not be handled first come, first served, and calls risk-based prioritisation one of the most critical decisions in incident management. This template gives you a ready-to-adopt policy and severity matrix: four severity levels, impact and urgency criteria, escalation and notification triggers, and response targets. It is for incident response leads, SOC managers and the executives who must agree the thresholds, and it slots into the Incident Response Plan Template.

How to use this template

• Replace text in square brackets, such as [Organisation], [CISO] and [X hours], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where exceptions may be justified.
• Agree the impact thresholds in section 4.3 with finance, legal and business owners before adoption: they are business decisions, not SOC decisions. Use your Business Impact Analysis Template output to set them.
• Keep severity (how bad) separate from priority (in what order) and from category (what kind). This template defines all three.
• Regulatory reporting deadlines in section 4.6 are summaries; confirm each one with legal counsel for your sector and jurisdictions.
• Test the matrix against your last 20 closed incidents before go-live, and adjust thresholds where the result surprises the people who handled them.

1. Purpose

This policy defines how [Organisation] classifies the severity of security incidents, so that response effort, escalation, management involvement and external notification are proportionate to actual and potential impact. It gives every responder, on any shift, the same answer to three questions: how serious is this, who must know, and how fast must we act.

2. Scope

This policy applies to:

• All suspected and confirmed security incidents affecting [Organisation] systems, data, identities (human and non-human), services, or third parties acting on [Organisation]'s behalf.
• Incidents detected internally, reported by staff or customers, or notified by suppliers, managed service providers, regulators or law enforcement.
• Incidents involving AI systems and AI agents, which are classified using the same matrix (see the AI Incident Reporting Guide for additional reporting duties).
• All employees, contractors and providers with incident response duties, including [MDR provider].

Alert severity produced by detection tools (for example syslog levels 0 Emergency to 7 Debug under RFC 5424, or a SIEM rule score) is an input to triage. It is not incident severity and must not be used as such.

3. Roles and responsibilities

• [Executive sponsor, e.g. COO]: approves this policy and the impact thresholds; is the escalation point for SEV1.
• [CISO]: owns this policy; confirms SEV1 and SEV2 classifications; decides on elevation to the crisis management team.
• Incident commander: assigns and updates severity during the incident, records the rationale, and triggers escalation and notification.
• SOC analysts / [MDR provider]: perform initial triage and provisional severity within the time targets in section 4.5.
• [Legal and Data Protection Officer]: decide whether regulatory or contractual notification thresholds are met.
• Business and system owners: confirm business impact for their services when asked.
• [Communications lead]: manages internal and external communication for SEV1 and SEV2.

4. Policy statements

4.1 Declaring and classifying an incident

1. An adverse event must be declared an incident when it meets the incident criteria in [IR plan reference].
2. Every declared incident must receive a category (4.2), a severity (4.3 and 4.4) and a priority (4.5).
3. A provisional severity must be assigned at triage, using known and reasonably assumed facts. Where facts are unknown, responders must classify on the most likely credible impact, not the best case.
4. Severity must be reassessed at every major update and at least every [4 hours] for SEV1 and SEV2. It may go up or down; every change and its reason must be recorded in the incident record.
5. Only the incident commander or [CISO] may downgrade a SEV1 or SEV2.

4.2 Incident categories

Categories describe the type of incident and select the playbook. They do not set severity.

4.3 Impact criteria

Assess each dimension and take the highest. A single dimension at a level is sufficient.

4.4 The severity matrix

Severity combines highest impact with confidence that the impact is real or imminent.

1. The following must be classified at least SEV2 regardless of the matrix: compromise of an identity provider, privileged access tooling or administrator of a cloud tenant; active ransomware on any production system; compromise of a provider holding delegated administrative access to [Organisation]; any incident a regulator, law enforcement or national authority notifies to [Organisation].
2. Repeated SEV3 incidents with a common cause within [30 days] must be reviewed for aggregation into a single higher-severity incident.

4.5 Priority, response and escalation targets

1. Within a severity, priority must reflect scope, time-critical factors (for example active exfiltration or spreading encryption) and resource availability, following NIST SP 800-61 Rev. 3 guidance on RS.MA-03.
2. Escalation (involving more expertise) and elevation (involving higher management) must happen at the times above, or earlier when a responder judges it necessary. A responder must never be criticised for escalating in good faith.

4.6 Regulatory and contractual notification triggers

Severity does not decide notification; legal assessment does. Any SEV1 or SEV2, and any incident involving personal data, must be referred to [Legal and DPO] within [2 hours] of classification. Reference deadlines:

Where a national scheme applies, [Organisation] should also record the authority's own rating; in the UK, the NCSC categorises incidents from Category 1 (national cyber emergency) to Category 6 (localised incident).

5. Exceptions

1. The incident commander may assign a severity higher than the matrix produces at any time. Assigning a lower severity than the matrix produces is an exception and must be approved by [CISO] and recorded with its rationale.
2. Permanent changes to thresholds, categories or targets are not exceptions; they require a policy update under section 7.
3. Third parties, including [MDR provider], must not apply their own severity scheme in place of this one; contracts must map their levels to SEV1 to SEV4.

6. Compliance and monitoring

[Security operations manager] must report monthly to [CISO] on:

• Number of incidents by severity and category.
• Percentage of incidents acknowledged and escalated within target, by severity.
• Number of severity changes after initial classification, upgrades and downgrades separately.
• Number of incidents reclassified at post-incident review.
• Median time from declaration to legal referral for SEV1 and SEV2.

Internal audit may sample incident records to check that severity rationale is recorded. Every SEV1 and SEV2 must have a post-incident review that confirms whether the severity was right, using the Post-Incident Review and Root Cause Analysis Template.

7. Review and approval

This policy is owned by [CISO] and approved by [Executive sponsor]. It must be reviewed at least annually, after every SEV1, after any change to applicable regulation, and when the business impact analysis changes. Thresholds must be exercised in at least one tabletop exercise per year.

Version: [1.0] · Approved by: [Name, role] · Date: [Date] · Next review: [Date]

Implementation guidance

Rollout

1. Calibrate: set the financial, data volume and outage thresholds with business owners, using BIA outputs, so that SEV1 means the same thing to finance as to the SOC.
2. Back-test: classify the last 20 closed incidents with the matrix. If more than a handful land at SEV1, thresholds are too low; if a known serious incident lands at SEV3, they are too high.
3. Configure tooling: add category, severity, confidence and rationale fields to the case management or SOAR tool, make severity changes audit-logged, and map SIEM alert scores to triage priority, not incident severity.
4. Pilot: run the matrix on one shift or one region for a month alongside the old scheme, and compare escalation outcomes.
5. Exercise: run a tabletop where severity changes mid-incident, for example a single compromised account that turns out to be a cloud administrator. See the Tabletop Exercise Guide.
6. Roll back: if the new scheme causes missed escalations, revert the affected thresholds to the previous values while the cause is reviewed, rather than abandoning the matrix.

Common failure patterns

• Severity theatre: everything rated high to get attention, so SEV1 loses meaning. Monitor the distribution.
• Tool severity as incident severity: a "critical" EDR alert on a test host treated as a SEV1 while a quiet sign-in by a stolen service account key sits at low.
• Underrating identity incidents: "one account compromised" rated SEV4 without checking what the account could reach. The BeyondTrust breach began with a single stolen API key and was reported by the US Treasury as a major incident.
• Never re-rating: severity set at triage and not revisited as scope grows.
• Severity driving notification: waiting for SEV1 before involving legal, and missing a 24-hour or 72-hour clock on a SEV3 personal data breach.

Framework mapping

References

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Categorising UK cyber incidents
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1772
• US SEC: Cybersecurity risk management and incident disclosure rules
• IETF: RFC 5424, The Syslog Protocol

This template is provided for guidance and must be adapted to your organisation. It summarises regulatory deadlines and is not legal advice. Related NHI Mgmt Group resources: Incident Response Guide · Incident Response Plan Template · Incident Communication Plan Template · Identity Incident Response Playbook · Third-Party Access Guide