# 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.

<!--
Guidance: How to use this template
- Write this standard once per organisation, not per team. Teams add
  service-specific examples in their own On-call Handbook
  (`ops/on-call-handbook`) but never redefine the levels.
- Fill the classification criteria (section 4) before the response
  table (section 5). People argue about criteria, not about cadences.
- Keep thresholds measurable where you can (share of requests, share
  of customers, minutes) and give a plain-language fallback for the
  cases a number cannot capture.
- Incident roles are owned by the Incident Commander Handbook
  (`ops/incident-commander-handbook`); alert routing and page
  urgency are owned by the Alerting Policy (`ops/alerting-policy`).
  Do not duplicate them here.
- The main pitfall is a scale that rewards under-classification:
  if a SEV2 creates paperwork that a SEV3 does not, people will call
  everything SEV3. Make the higher level cheap to declare.
-->

## Document control

<!-- Guidance: This is an organisation standard. The owner is usually the head of SRE or reliability engineering; approval includes security, support and communications because they carry obligations per level. -->

| Field | Value |
|---|---|
| Document ID | [SEV-STD-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-reliability] |
| Approvers/reviewers | [@cto], [@ciso], [@vp-customer-support], [@head-of-communications], [@legal-counsel] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Applies to | [All production services, customer-facing and internal, in every region] |
| Severity scale | SEV1 (most severe) to SEV4 (least severe) |
| Effective date | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least annually, and after any SEV1) |
| Related documents | [Incident commander handbook], [Alerting policy], [Incident response plan], [Incident communication plan], [Postmortem template] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief technology officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of customer support | [@name] | [Decision] | YYYY-MM-DD |
| Head of communications | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; replaces team-level severity tables |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added data-integrity criterion after INC-2041 calibration review |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and principles](#1-purpose-scope-and-principles)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Severity scale](#3-severity-scale)
4. [Classification criteria](#4-classification-criteria)
5. [Response requirements by severity](#5-response-requirements-by-severity)
6. [Security incidents and availability incidents](#6-security-incidents-and-availability-incidents)
7. [Upgrade and downgrade rules](#7-upgrade-and-downgrade-rules)
8. [Worked classification examples](#8-worked-classification-examples)
9. [Policy statements](#9-policy-statements)
10. [Exceptions, compliance measurement and review](#10-exceptions-compliance-measurement-and-review)
11. [Glossary and references](#11-glossary-and-references)
12. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and principles

<!-- Guidance: State why a common scale matters for this organisation. Questions to answer: which services and which kinds of events are in scope, and who may declare. Pitfall: excluding internal tools that are on the critical path of customer work, such as the deployment pipeline during an outage. -->

### 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

<!-- Guidance: List only the responsibilities that relate to severity. The full role definitions live in the incident commander handbook. Pitfall: leaving no one accountable for calibration, so levels drift apart between teams. -->

| Role | Severity responsibilities |
|---|---|
| Standard owner ([@head-of-reliability]) | Maintains this standard, runs the quarterly calibration review, approves exceptions |
| Incident commander (IC) | Sets and changes severity during the incident, records each change and its reason in the decision log |
| Primary on-call engineer | Proposes the initial level when declaring, acts as IC for SEV3 and SEV4 |
| Security incident lead | Classifies security impact (section 4.4), owns the security track (section 6), approves downgrades of security incidents |
| Communications lead | Applies the communication obligations of the level in section 5 |
| Customer support lead | Reports customer-reported impact that may justify an upgrade |
| Postmortem owner | Records the peak severity and checks that the classification was correct |
| Team leads | Add service-specific examples to their on-call handbook, consistent with this standard |

## 3. Severity scale

<!-- Guidance: Keep the one-line definitions short enough to remember at 03:00. Questions: do people know which level is "wake people up" and which is "next business day"? Pitfall: adding a level above SEV1 for marketing reasons, which empties SEV1 of meaning. -->

### 3.1 Levels

| Level | Name | One-line definition | Major incident | Wake people up |
|---|---|---|---|---|
| SEV1 | Critical | A core customer journey is unavailable or unsafe for many customers, or data is lost, corrupted or exposed | Yes | Yes, any hour |
| SEV2 | Major | A core journey is significantly degraded, or a key feature or a large customer segment is unavailable | Yes | Yes, any hour |
| SEV3 | Minor | Limited impact on a non-core feature or a small group of customers, usually with a workaround | No | Business hours, unless the owning team's handbook says otherwise |
| SEV4 | Low | No current customer impact, but a risk that needs action (lost redundancy, near miss) | No | No |

### 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

<!-- Guidance: Each criterion is evaluated independently and the most severe result wins. Replace the example thresholds with values derived from your SLOs and customer contracts. Pitfall: thresholds that require data nobody can see during the incident. -->

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

| Level | Criterion |
|---|---|
| SEV1 | A core journey ([checkout, payment, login, public API]) fails for at least [25%] of requests or customers in any region for [5] minutes or more; or the whole product is unreachable |
| SEV2 | A core journey fails for [5% to 25%] of requests, or its latency exceeds [3 times] the SLO threshold for most users; or a non-core but key feature is unavailable for everyone; or an SLO fast-burn page fires on a core journey |
| SEV3 | A non-core feature is degraded or unavailable for some users, or a core journey fails for under [5%] of requests with a workaround available |
| SEV4 | No customer-visible impact; internal tooling degraded without blocking customer work |

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

| Level | Criterion |
|---|---|
| SEV1 | An outage of a core journey in more than one region, or an outage of a shared platform component ([identity, API gateway, primary data store]) for all customers |
| SEV2 | An outage of a key non-core feature in one full region; the loss of one availability zone without automatic failover; or one or more customers in the [strategic / enterprise] tier fully down |
| SEV3 | A single tenant or a small set of tenants outside the strategic tier fully down |
| SEV4 | No tenant affected |

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

| Level | Criterion |
|---|---|
| SEV1 | Confirmed loss or corruption of customer data greater than the RPO allows (data written over a period longer than the RPO cannot be recovered); or writes are being silently dropped |
| SEV2 | Data integrity at risk (replication broken, backups failing for a core data store for more than [24 hours]); or loss or corruption that can be recovered from backups or replicas with data loss no greater than the RPO |
| SEV3 | Delayed data (pipelines or exports late beyond their target) with no loss |
| SEV4 | A single failed backup or replication lag inside its threshold |

### 4.4 Security impact

| Level | Criterion |
|---|---|
| SEV1 | Confirmed unauthorised access to or exfiltration of confidential or personal data; active attacker with privileged access; ransomware execution in production |
| SEV2 | Credible indication of compromise under investigation (leaked production secret, suspicious privileged session); actively exploited vulnerability on an internet-facing production system |
| SEV3 | Security event contained with no evidence of data access (blocked intrusion attempt with a policy gap, malware on one non-privileged endpoint) |
| SEV4 | Security weakness with no sign of exploitation that needs tracked remediation |

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

| Level | Criterion |
|---|---|
| SEV1 | Likely breach of a regulatory obligation; financial transactions processed incorrectly at scale; contractual SLA breach for most customers |
| SEV2 | Contractual SLA at risk for enterprise customers; revenue loss above [USD amount] per hour |
| SEV3 | Minor financial impact or a single SLA credit likely |
| SEV4 | None |

### 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.

```mermaid
flowchart TD
  A["Event observed or page received"] --> B{"Customer, data or security impact now or within 1 hour?"}
  B -- "No" --> C{"Risk that needs action?"}
  C -- "Yes" --> S4["SEV4: track and fix"]
  C -- "No" --> N["Not an incident: ticket or ignore"]
  B -- "Yes" --> D{"Any SEV1 criterion met?"}
  D -- "Yes" --> S1["SEV1: page IC, full response"]
  D -- "No" --> E{"Any SEV2 criterion met?"}
  E -- "Yes" --> S2["SEV2: page IC, full response"]
  E -- "No" --> S3["SEV3: on-call handles"]
  S1 --> F{"Company-threatening?"}
  F -- "Yes" --> CR["Set crisis flag"]
```

## 5. Response requirements by severity

<!-- Guidance: These are minimums. The IC may always do more. Align the communication columns with your incident communication plan and the acknowledgement times with what the on-call rotations can actually achieve. Pitfall: promising a status page update cadence the communications rota cannot staff overnight. -->

### 5.1 Mobilisation and command

| Requirement | SEV1 | SEV2 | SEV3 | SEV4 |
|---|---|---|---|---|
| Page owning team on-call | Yes, high urgency | Yes, high urgency | Business hours (high urgency only if the team's handbook says so) | No, ticket |
| Acknowledge within *(Example)* | 5 min | 15 min | 1 h (business hours) | Next business day |
| Dedicated incident commander | Required, from the IC rotation | Required, from the IC rotation | Primary on-call acts as IC | Not required |
| Scribe | Required | Required | Optional | No |
| Communications lead (separate from IC) | Required | Required | No | No |
| Incident channel and bridge | Channel and voice bridge | Channel and voice bridge | Channel | Ticket |
| Mitigation target *(Example)* | 1 h | 4 h | 2 business days | Planned work |
| Change freeze on affected services | Automatic | Automatic | At IC discretion | No |

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.

| Requirement | SEV1 | SEV2 | SEV3 | SEV4 |
|---|---|---|---|---|
| Public status page *(Example)* | Within 15 min of declaration | Within 30 min | Only if customer-visible | No |
| Customer update cadence | Every 30 min | Every 60 min | On material change | None |
| Internal stakeholder update | Every 15 min | Every 30 min | Every 2 h while active | In ticket |
| Executive notification | Within 30 min, then hourly | Within 2 h | Not required | Not required |
| Security, legal and privacy notified | If any data or security criterion is met | If any data or security criterion is met | If a security criterion is met | No |
| Postmortem | Required, review within [5] business days | Required, review within [10] business days | Required if repeated within [30] days or at IC request | Optional |
| Public incident summary | Required for customer-visible SEV1 | If customer-visible | No | No |
| Follow-up actions tracked with owners | Required | Required | Required | Recommended |

### 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

<!-- Guidance: Most organisations run one incident process with a security track, not two processes. Questions: who leads, which channel, what is restricted, and when does the security incident response plan take over? Pitfall: posting details of a suspected breach in an open incident channel. -->

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.

| Aspect | Availability incident | Security incident (security track) |
|---|---|---|
| Typical trigger | SLO alert, synthetic check, customer reports | Detection rule, SOC triage, external report, threat intelligence |
| Lead | IC from the IC rotation | IC from the IC rotation with the security incident lead as operations lead, or the security incident lead as IC for SEV3 and SEV4 |
| Channel | Open incident channel | Private channel, need-to-know membership, named in the decision log |
| Status page wording | Factual impact and progress | Approved by legal and the security lead; no detail that helps an attacker |
| Evidence | Logs and metrics for the postmortem | Evidence preservation and chain of custody before remediation where feasible |
| Governing procedure | This standard plus the Incident Commander Handbook | The Incident Response Plan (`compliance/incident-response-plan`), aligned with NIST SP 800-61 Rev. 3, and the relevant SOC Playbook (`security/soc-playbook`) |
| Regulatory clocks | Contractual SLA notices | Legal and privacy assess notification duties defined in the incident response plan from the moment a data or security criterion is met |

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

<!-- Guidance: Changing severity is normal. What matters is that each change is visible and recorded. Pitfall: downgrading just before the postmortem threshold to avoid the review. -->

### 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.

```mermaid
stateDiagram-v2
  [*] --> SEV3: Declared
  SEV3 --> SEV2: Criterion of SEV2 met
  SEV2 --> SEV1: Criterion of SEV1 met
  SEV1 --> SEV2: Mitigated, stable 30 min
  SEV2 --> SEV3: Mitigated, stable 30 min
  SEV1 --> SEV3: Mitigated, within SEV3 criteria 30 min
  SEV3 --> Resolved: Impact ended
  SEV2 --> Resolved: Impact ended
  SEV1 --> Resolved: Impact ended
  Resolved --> [*]
```

## 8. Worked classification examples

<!-- Guidance: Calibrate the scale with real incidents from your history. For each example, show which criterion decided the level. Pitfall: examples that only describe the cause; describe the impact. -->

All rows are *Example* data for Corvid Commerce.

| ID | Situation | Deciding criterion | Level | Notes |
|---|---|---|---|---|
| CLS-001 *(Example)* | Checkout returns HTTP 500 for 40% of requests in eu-west for 8 minutes after a deployment | 4.1 customer impact above 25% on a core journey | SEV1 | Rollback mitigates in 12 min; peak stays SEV1 |
| CLS-002 *(Example)* | Catalogue search p95 latency 4 times its SLO threshold in all regions; checkout unaffected | 4.1 core journey (browse) severely slow; 4.2 does not apply because nothing is down | SEV2 | Fast-burn alert from the alerting policy paged on-call |
| CLS-003 *(Example)* | CSV export for merchants fails for everyone; manual download from the dashboard works | 4.1 non-core feature with workaround | SEV3 | Would be SEV2 at month-end if contracts require export |
| CLS-004 *(Example)* | One of three database replicas down, no customer impact | 3.1 SEV4 definition: lost redundancy, no customer impact | SEV4 | Upgrade to SEV2 if a second replica fails |
| CLS-005 *(Example)* | A production cloud access key is found in a public code repository | 4.4 credible indication of compromise | SEV2, security track | Upgrade to SEV1 if access logs show use by an unknown party |
| CLS-006 *(Example)* | Webhook delivery to merchants delayed by 3 hours, no events lost | 4.3 delayed data | SEV3 | SEV2 if the delay breaches enterprise SLAs |
| CLS-007 *(Example)* | Order write path silently drops 1% of orders for 20 minutes | 4.3 silent data loss | SEV1 | Low percentage, but lost orders cannot be reconstructed |
| CLS-008 *(Example)* | Payment provider outage; Corvid fails over to the secondary provider in 3 minutes, 2% of payments fail during failover | 4.1 under 5% on a core journey, ended | SEV3 | Postmortem still useful to review failover time |
| CLS-009 *(Example)* | Ransomware note found on a build server with access to production signing keys | 4.4 ransomware with privileged access | SEV1, security track, crisis flag considered | Isolate first, preserve evidence |
| CLS-010 *(Example)* | Single enterprise merchant cannot log in because of a misconfigured SSO certificate on their tenant | 4.2 one strategic customer fully down | SEV2 | Customer liaison engaged |

## 9. Policy statements

<!-- Guidance: Use MUST for obligations and SHOULD for strong recommendations. Number each statement so audits and exceptions can reference it. -->

| ID | Statement |
|---|---|
| SEV-POL-001 | Every production incident MUST be assigned a severity from SEV1 to SEV4 at declaration. |
| SEV-POL-002 | Teams MUST use the levels and criteria in this standard and MUST NOT define their own levels. Teams SHOULD add service-specific examples in their on-call handbook. |
| SEV-POL-003 | The IC MUST record every severity change, with time, reason and evidence, in the incident decision log. |
| SEV-POL-004 | SEV1 and SEV2 incidents MUST have a dedicated IC and a communications lead who is not the IC. |
| SEV-POL-005 | The minimum responses in section 5 MUST be met; deviations MUST be recorded in the postmortem with the reason. |
| SEV-POL-006 | Any incident meeting a data or security criterion MUST be reported to the security incident lead within [15] minutes of that criterion being met. |
| SEV-POL-007 | Postmortems MUST record the initial and peak severity. |
| SEV-POL-008 | Severity MUST NOT be downgraded to avoid an obligation; obligations triggered at the peak level remain. |
| SEV-POL-009 | Incident tooling SHOULD enforce the levels as a fixed list and record changes automatically. |
| SEV-POL-010 | New employees joining an on-call or IC rotation MUST complete severity classification training before their first shift. |

## 10. Exceptions, compliance measurement and review

<!-- Guidance: Measure whether the scale is used consistently, not only how many incidents occur. Pitfall: treating a rise in SEV2 declarations as a reliability failure when it reflects better reporting. -->

### 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.

| ID | Requirement | Team or service | Compensating control | Risk owner | Expiry |
|---|---|---|---|---|---|
| SEV-EXC-001 *(Example)* | SEV3 business-hours page | merchant-analytics | Central SRE rotation covers out of hours | [@vp-engineering] | YYYY-MM-DD |

### 10.2 Compliance measurement

| Metric | Formula | Target *(Example)* |
|---|---|---|
| Declaration latency | median of (declared time minus impact start time) per level | SEV1 under 10 min |
| Severity change rate | incidents with any severity change / all incidents | Tracked, no target; investigate if above 40% |
| Under-classification rate | incidents whose peak was at least 2 levels above the initial level / all incidents | Under 5% |
| IC coverage | SEV1 and SEV2 with a dedicated IC / all SEV1 and SEV2 | 100% |
| Status page timeliness | SEV1 status posts within 15 min / all customer-visible SEV1 | At least 95% |
| Postmortem completion | required postmortems reviewed on time / required postmortems | At least 90% |

*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

<!-- Guidance: Define terms the way this standard uses them. List the sources you relied on with the version checked. -->

### 11.1 Glossary

| Term | Meaning in this standard |
|---|---|
| Incident | An unplanned event that degrades or threatens a production service, data or operations and needs a coordinated response |
| Major incident | A SEV1 or SEV2 incident |
| Core journey | A user flow whose failure stops customers from getting the main value of the product |
| Peak severity | The highest level reached during an incident, used for reporting |
| Crisis flag | Marker on a SEV1 that activates crisis management and business continuity steps |
| Security track | The variant of the response for suspected or confirmed security incidents |
| RPO | Recovery point objective: the maximum acceptable data loss measured in time |
| SLO | Service level objective: target level of reliability for a service |
| IC | Incident commander |

### 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

| Reference | Version or date checked | Use |
|---|---|---|
| PagerDuty Incident Response documentation, response.pagerduty.com (source repository PagerDuty/incident-response-docs, Apache-2.0) | Repository updated 2026-07-02, checked 2026-10-24 | Severity and major-incident concepts, adapted in original words |
| NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile | Final, April 2025 | Link between severity and the security incident response lifecycle |
| Google, Site Reliability Engineering (O'Reilly), chapter "Managing Incidents", sre.google | 1st edition 2016 (online); 2nd edition announced October 2026 | Background reading only; no text reproduced |
| [Internal business continuity plan] | [Version] | Crisis management team |

## 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.