Incident Severity Matrix Template (SEV1 to SEV4)

Incident Severity Matrix: [Organisation name]

Organisation-wide standard that defines incident severity levels SEV1 to SEV4, the criteria used to classify an incident (user impact, scope, data impact, security impact, contractual and regulatory exposure), the minimum response each level receives (paging, incident commander, communication cadence, status page, executive notification, postmortem), how security incidents differ from availability incidents, and the rules for upgrading and downgrading. Structure aligned with the severity and major-incident practice in the PagerDuty Incident Response documentation (Apache-2.0) and with the incident handling model of NIST SP 800-61 Rev. 3 (April 2025) for the security link. This standard is the single source of truth for severity in the library: the On-call Handbook (ops/on-call-handbook), Postmortem (dev/postmortem) and Incident Communication (dev/incident-communication) refer to it. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS commerce platform.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and principles
2. Roles and responsibilities
3. Severity scale
4. Classification criteria
5. Response requirements by severity
6. Security incidents and availability incidents
7. Upgrade and downgrade rules
8. Worked classification examples
9. Policy statements
10. Exceptions, compliance measurement and review
11. Glossary and references
12. Standard and licence note

1. Purpose, scope and principles

1.1 Purpose

This standard gives every team at [Organisation name] the same answer to one question during an incident: how serious is this, and therefore what response does it get. A shared scale lets an on-call engineer in any team mobilise the right people without negotiation, lets support and communications act on a predictable cadence, and lets leadership compare incidents across the organisation.

1.2 Scope

• In scope: any unplanned event that degrades, or threatens to degrade, a production service, the integrity or confidentiality of data, or the organisation's ability to operate. This includes customer-facing services, internal services on the critical path of customer work, third-party dependencies whose failure affects customers, and security events confirmed or suspected to be incidents.
• Out of scope: planned maintenance announced in line with the Maintenance Notice (ops/maintenance-notice), unless it overruns or causes impact beyond what was announced; individual support tickets that affect one user and have a known fix; and non-production environments, unless they block a production fix.

1.3 Principles

1. Classify by impact, not by cause. Severity reflects what users, customers and the organisation experience now or will experience soon without action. The cause is unknown at declaration and does not change the level.
2. The highest criterion wins. An incident takes the most severe level reached by any single criterion in section 4.
3. When in doubt, go higher. Declaring one level too high costs a few people some time. Declaring too low delays help. Downgrading is normal and is never treated as a mistake.
4. Severity drives response, not blame. The level sets minimum obligations. It is not a performance score for the owning team.
5. Anyone can declare. Any employee who sees customer impact may declare an incident and propose a level; the incident commander confirms or changes it.
6. Major incident means SEV1 or SEV2. Both levels get a dedicated incident commander and the full response described in the Incident Commander Handbook (ops/incident-commander-handbook).

2. Roles and responsibilities

3. Severity scale

3.1 Levels

3.2 Why SEV1 to SEV4 and not SEV0

This standard uses four levels numbered from 1. The choice is deliberate:

• Four levels map to four distinct responses (section 5). A fifth level is only useful if it triggers a response the others do not.
• The events some organisations call SEV0 (a company-threatening outage or breach) are handled here as a SEV1 with the crisis flag set (section 5.3). The flag adds crisis management and business continuity steps without inventing a new level.
• Numbering from 1 keeps the scale consistent with the other templates in this library and with common incident tooling defaults.

If your organisation already uses SEV0, keep it, define the extra response it triggers, and update every related document in the same change.

3.3 Severity is not priority

Ticket priority (P1 to P4) orders work in a backlog. Alert urgency (page or ticket, defined in the Alerting Policy, ops/alerting-policy) says whether a human must respond now. Incident severity says how serious an active incident is. A page does not automatically create an incident, and a SEV4 incident may create a P2 follow-up ticket.

4. Classification criteria

Evaluate each criterion against what is known now and what will happen within the next hour without action. Use the most severe result.

4.1 Customer and user impact

A fast-burn page on a core journey sets at least SEV2 even when the error ratio is under 5%: with a 99.9% SLO the fast-burn rule of the Alerting Policy (ops/alerting-policy) fires at an error ratio of 1.44%, which means the error budget is being spent at 14.4 times or more the sustainable rate. Under the highest-criterion-wins rule the page, not the raw ratio, decides.

Core journeys at Corvid Commerce (Example): storefront browse, checkout, payment authorisation, merchant login, and the public orders API. Non-core features (Example): product recommendations, CSV export, merchant analytics dashboards.

4.2 Scope and customer segment

Scope raises the level only when the impact is an outage: the journey, feature or tenant does not work at all for the customers concerned. Degradation (elevated errors below the SEV1 threshold of section 4.1, or slow responses) is classified with section 4.1 alone, even when it is visible in every region. This is why CLS-002 in section 8 (search latency four times the SLO threshold in all regions) is SEV2 and not SEV1. A core journey that is down in a single region is already SEV1 under section 4.1, so the scope table does not need to repeat it.

4.3 Data impact

4.4 Security impact

Security classification is made or confirmed by the security incident lead. Section 6 explains how the security track differs.

4.5 Financial, contractual and regulatory exposure

4.6 Decision flow

Use this flow when declaring. It applies the highest-criterion-wins rule from the top down, so the first level whose criterion is met is the answer.

5. Response requirements by severity

5.1 Mobilisation and command

The acknowledgement times above are the maximums by severity. Page acknowledgement targets by service tier in the Alerting Policy (ops/alerting-policy) apply first where they are shorter: a tier 1 page is acknowledged within 5 minutes (Example) even if the incident is later classified SEV2.

5.2 Communication and follow-up

The cadences below are the minimum set by this standard. The Incident Communication plan (dev/incident-communication) holds the message templates and audiences.

5.3 Crisis flag

The IC or any executive may set the crisis flag on a SEV1 when the event threatens the organisation as a whole: an extended multi-region outage, a large personal data breach, extortion, or an event likely to attract press or regulator attention. The crisis flag adds:

• activation of the crisis management team named in the [business continuity plan];
• an executive incident owner who makes business decisions and speaks for the company;
• assessment of the Disaster Recovery Plan (ops/disaster-recovery-plan) invocation criteria;
• legal review of every external statement.

6. Security incidents and availability incidents

The same SEV1 to SEV4 scale applies to both kinds of incident so that mobilisation and executive attention are comparable. What changes is who leads, who may know, and which obligations start.

Rules for mixed events:

1. An availability incident becomes a security incident as soon as the IC or any responder has a credible reason to suspect malicious activity. Move to a private channel and add the security incident lead; the severity does not drop.
2. A security incident with customer-visible impact keeps a single IC and a single severity. The security lead owns containment decisions; the IC owns overall coordination and communication.
3. Ransomware, confirmed data exfiltration and compromised production credentials with privileged access start at SEV1 until scoping shows otherwise.

7. Upgrade and downgrade rules

7.1 Upgrade

• Upgrade immediately when any criterion of a higher level is met. The IC announces the new level in the incident channel and the response for that level starts at once.
• Customer support, the communications lead or any responder may request an upgrade; the IC decides within [10] minutes and records the decision.
• An incident that has stayed at SEV3 for more than [4] hours with no mitigation is reviewed for upgrade to SEV2.
• A SEV4 that recurs [3] times in [7] days is reviewed for upgrade to SEV3 and a problem record.

7.2 Downgrade

• Downgrade only when impact has been mitigated and has stayed within the lower level's criteria for at least [30] minutes (Example).
• The IC records the reason, the evidence (graph, query or customer confirmation) and the time in the decision log.
• A security incident can be downgraded only with the agreement of the security incident lead.
• Downgrading never removes obligations already triggered. A postmortem required at the peak level is still required.

7.3 Peak severity

Reports, postmortems and metrics use the peak severity: the highest level reached during the incident. Record both the initial and the peak level in the postmortem so calibration reviews can see how often the first call was wrong. A level may be skipped on the way down when the impact already meets the lower criteria (for example, SEV1 straight to SEV3 once only a minor residue remains); the 30-minute stability rule still applies.

8. Worked classification examples

All rows are Example data for Corvid Commerce.

9. Policy statements

10. Exceptions, compliance measurement and review

10.1 Exceptions

A team that cannot meet a requirement in section 5 (for example, a service without a 24-hour rotation) requests an exception from the standard owner. Each exception records the requirement, the reason, the compensating control (such as escalation to a central rotation out of hours), the risk owner who accepts it, and an expiry date no later than [12] months.

10.2 Compliance measurement

Example for one quarter at Corvid Commerce: 4 SEV1, 11 SEV2, 37 SEV3 and 60 SEV4 incidents, 112 in total. 19 had a severity change, a rate of 19 / 112 = 17.0%. Three incidents jumped two levels, an under-classification rate of 3 / 112 = 2.7%. All 15 SEV1 and SEV2 incidents had a dedicated IC (100%).

10.3 Calibration and review

• Hold a quarterly calibration review: sample at least [10] incidents, reclassify them blind, and compare with the recorded levels.
• Review this standard at least annually and after every SEV1. Changes to levels or criteria update the On-call Handbook (ops/on-call-handbook), Incident Communication (dev/incident-communication), Alerting Policy (ops/alerting-policy) and Incident Response Plan (compliance/incident-response-plan) in the same change.
• Exercise the scale in a Tabletop Exercise (security/tabletop-exercise) or a Game Day (ops/game-day-plan) at least once a year.

11. Glossary and references

11.1 Glossary

11.2 Related templates

• Incident Commander Handbook (ops/incident-commander-handbook): roles, command, cadence.
• Alerting Policy (ops/alerting-policy): what pages and how pages map to incidents.
• On-call Handbook (ops/on-call-handbook): rotation and service-specific examples.
• Incident Communication (dev/incident-communication): message templates and audiences.
• Postmortem (dev/postmortem): review after SEV1 and SEV2.
• Incident Response Plan (compliance/incident-response-plan): security incidents and regulatory notification.
• SOC Playbook (security/soc-playbook): per-scenario security response.
• Error Budget Policy (ops/error-budget-policy) and SLO Document (dev/slo-doc): thresholds behind the customer impact criteria.
• Disaster Recovery Plan (ops/disaster-recovery-plan): invoked under the crisis flag.

11.3 References

Standard and licence note

Structure aligned with the severity levels and major-incident practice described in the PagerDuty Incident Response documentation (response.pagerduty.com, Apache-2.0, copyright PagerDuty, Inc.), adapted here to a four-level scale with original definitions and criteria. Based on NIST SP 800-61 Rev. 3 (April 2025, US Government work, public domain) for the security incident link. Google's Site Reliability Engineering books are cited as further reading only and no text from them is reproduced. PagerDuty is a trademark of its owner; this template is not affiliated with or endorsed by it. Corvid Commerce is fictional. This template is original text written for this collection. Check the current official versions of the sources before use. Template licence: MIT.