---
name: major-incident-declaration
description: Decide whether an active incident meets the "major incident" bar, with an escalation trigger table, named decision-makers, communications template, stakeholder map, and regulator-notification clock.
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: IT Managers, Incident Commanders, Service Delivery Managers, DPOs, Directors-on-call
output_format: Formatted Markdown decision pack with severity determination, declaration template, stakeholder map, first-hour comms, regulator-clock tracker, and criteria for downgrade.
license: MIT
last-reviewed: 2026-04
---

# Major Incident Declaration

A Claude Code skill to answer the hardest question of any incident: **"is this a major incident?"** — before you make the call, not an hour later when everyone's already on it.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/major-incident-declaration`. Describe what's happening in plain English. Answer the rapid-fire questions. Receive the declaration pack.

## When to use this

- An incident is unfolding and you need to decide in the next 5 minutes whether to call it a major (vs. normal P1).
- You're on the bridge and someone asked "should we be calling this a major?" — this produces the defensible answer.
- You want a living template for "what counts as major here" so the on-call handbook is no longer one sentence.
- Post-incident review found you under-escalated last time and you want criteria that prevent it next time.
- You're under a regulatory regime (FCA op-resilience, DORA, NIS2, UK GDPR breach) and need the regulator-notification clock on one page.

## What you'll get

A single Markdown document containing:

- A **severity determination** matrix (user impact × business service × duration × data-sensitivity)
- A **declaration template** (for Slack/Teams/email, timestamped)
- A **named decision-makers** list (who can call it a major / downgrade it / authorise external comms)
- A **stakeholder map** for the first hour (who to wake, in what order, via what channel)
- **Communications templates** for internal, customer, regulator, status page
- A **regulator-notification clock** (which regulators, under what condition, with what deadline)
- **Downgrade criteria** (how and when it stops being a major)
- A **checklist of things that must be happening** in the first 15 / 30 / 60 minutes

## Clarifying questions I will ask you

1. **What's happening right now?** (one sentence)
2. **Who's affected?** (internal users, customers, a specific client, regulators, public)
3. **Which business service(s) are down or degraded?**
4. **How long has it been running?**
5. **Does personal data / privileged data appear to be at risk or exposed?**
6. **Is there any active attack indicator?** (ransomware, suspicious sign-ins, data exfil)
7. **Can the business continue working?** (yes/degraded/no)
8. **Is a client or regulator likely to see it within the next hour?**
9. **Who's currently on the bridge?**
10. **What's your sector / regulator?** (SRA, FCA, ICAEW, ICO, public sector, general SMB)
11. **Is there a contractual SLA that's about to breach?**
12. **Have you already informed anyone externally?**

## Output template

```markdown
# Major Incident Declaration Pack — <incident ref>

**Reported:** <time> · **Declared:** <time or "TBD"> · **Severity:** SEV-<N>
**Incident Commander:** <role> · **Declaration authority:** <role>

## 1. Severity Determination
| Dimension | Observation | Score |
|---|---|---|
| User impact | <many / some / one client / internal only> | |
| Business service impact | <critical service down / degraded / non-critical> | |
| Duration so far / expected | <N min, ongoing> | |
| Data at risk | <none / PII / privileged / special-category> | |
| Revenue impact | <estimate> | |
| Reputational risk | <none / niche / public> | |
| Regulator interest | <none / likely / certain> | |
| Active attack indicator | <yes / no> | |

**Verdict:** MAJOR / P1 / P2 / P3
**Reasoning (one paragraph):**
<paragraph>

## 2. Declaration Message
(Post this in the incident channel, verbatim.)

> 🚨 **MAJOR INCIDENT DECLARED** — <incident ref>
>
> **At <time>** we are declaring a major incident.
>
> **Impact:** <one sentence>
> **Affected:** <who>
> **Current status:** <one line>
> **Incident Commander:** <name>
> **Next update:** <time — 15 / 30 minute cadence>
>
> Join bridge: <link>
> All non-essential work pauses. Comms go through the Incident Commander.

## 3. Decision Authority
| Decision | Authority |
|---|---|
| Declare major | Incident Commander + <named role> (or either, in hours / out of hours) |
| Downgrade to P1 | Incident Commander + Service Manager |
| Authorise customer comms | <role> |
| Authorise regulator notification | <role> |
| Authorise statement to press | Managing Director only |
| Escalate to Board | <role> |

## 4. Stakeholder Map — First Hour
| Minute | Who | How | Purpose |
|---|---|---|---|
| 0 | On-call tech lead | Phone | Already on bridge |
| 5 | IT Manager / Service Manager | Phone | Executive oversight |
| 10 | Comms Lead | Phone | Start drafting external comms |
| 15 | Business Sponsor | Phone | Business-side awareness |
| 20 | DPO (if personal data) | Phone | Start data-breach timer |
| 30 | Managing Partner / MD | Phone | Senior sponsor |
| 45 | Key client account manager(s) | Email first, then call | If client-facing |
| 60 | Board / Regulator authority | Formal | If criteria met |

## 5. Communications Templates

### Internal — incident declared
> "A major incident has been declared for <service>. We're mobilising the response team now. Expect updates every 15-30 minutes in <channel>. Non-essential work paused until stand-down."

### Customer — service degradation (public-safe)
> "We're currently investigating issues affecting <service>. We apologise for the disruption. Our technical team is engaged, and we'll post updates every 30 minutes on this page."

### Customer — data-breach adjacent (only if confirmed, reviewed by legal)
> DRAFT ONLY — requires <role> sign-off before send.
> "We're writing to let you know that on <date> we identified an incident that may have affected <data type>. [next steps, regulator notification status, what the customer should do, contact details]."

### Regulator — UK GDPR Article 33 (72-hour clock, if personal-data breach)
> DRAFT — triggered only on confirmation, sent by DPO.
> "On <date> at <time> we became aware of a personal-data breach affecting <N> data subjects. [nature of breach, categories of data, likely consequences, measures taken, contact details]."

### Press / social (only after MD sign-off)
> "We can confirm that <company> experienced a <brief description> on <date>. The matter is resolved / under investigation. We take our obligations to <customers/regulators> seriously and have [action taken]. No further comment at this time."

## 6. Regulator-Notification Clock
| Regime | Trigger | Deadline | Owner |
|---|---|---|---|
| UK GDPR Art. 33 (ICO) | Personal-data breach likely to risk individuals | 72 hours from awareness | DPO |
| UK GDPR Art. 34 (data subjects) | Breach likely to result in high risk to individuals | Without undue delay | DPO |
| FCA / PRA operational resilience | Important business service impact tolerance exceeded | Promptly — same business day where possible | Compliance |
| NIS2 (if designated) | Significant incident | 24h early warning / 72h notification / 1 month final | Security Lead |
| SRA (legal) | Any material incident affecting client files | Prompt — as soon as practicable | Managing Partner / COLP |
| Cyber insurer | Per policy — often 24-72h from awareness | Per policy | Finance / Risk |
| Key client contracts | Per contract — often 24h | Per contract | Account Owner |

## 7. First 15 / 30 / 60 Minute Checklist

### First 15 minutes
- [ ] Bridge open with named roles
- [ ] Declaration posted
- [ ] Initial impact assessment logged
- [ ] Incident Commander confirmed
- [ ] First external comm drafted (may not yet be sent)

### First 30 minutes
- [ ] DPO engaged if personal-data involvement suspected
- [ ] Regulator clocks started (see §6)
- [ ] Customer-facing status page updated (if public)
- [ ] Business Sponsor briefed
- [ ] Initial mitigation attempted / scoped

### First 60 minutes
- [ ] Senior sponsor (MD / Partner) briefed in person
- [ ] External comms sent or held with a reasoned decision
- [ ] Scribe appointed (timeline capture)
- [ ] Next-update cadence communicated
- [ ] Rollback / containment options evaluated

## 8. Downgrade Criteria
An incident is downgraded from major to P1 when ALL of the following are true:
- [ ] Immediate customer-facing impact is mitigated
- [ ] No active attack indicator
- [ ] Regulator-notification obligations are met or cleared
- [ ] Business Sponsor agrees
- [ ] Forward-fix plan is agreed and owned

Downgrade is announced in the incident channel with a reason and a new next-update time. The major label doesn't disappear silently.

## 9. Post-Incident
- Formal post-incident review within <N> working days (see `/post-mortem-facilitator`).
- Retain timeline, chat logs, and decisions for <N> years.
- If personal-data breach was notified, final report due to regulator per regime.
```

## Example invocation

**User:** "At 09:40 we noticed users can't access SharePoint. All 110 staff affected. An external law firm client is on-site today for a document review. We think it's tenant-wide Microsoft. No clear data-exposure yet."

**What the skill will do:**
1. Ask the 12 rapid-fire questions, pressing on: is the external client seeing the same issue (they will — it's tenant-wide), is privileged material potentially affected (yes — document-review files), regulator interest (SRA client file access is material).
2. Produce the declaration pack scoring this as **MAJOR** on: user impact (all 110), client-facing (yes + on-site), business-service impact (document-review workflow halted), regulator angle (SRA — LPP-sensitive material inaccessible).
3. Draft the Declaration Message naming the Incident Commander, starting the bridge, pausing non-essential work, and scheduling the 15-minute cadence.
4. Start the SRA-notification consideration clock: "prompt" reporting if material impact extends beyond <N> hours.
5. Produce a customer-facing comms draft aimed specifically at the on-site external client, not a generic status-page post.

## Notes for the requester

- **Call it early. Downgrade later.** The cost of declaring a major that didn't need to be one is a room full of people who are now focused. The cost of not declaring a major that did is a regulator query and a client exit.
- **The decision-authority table must name roles (or named people) — not committees.** In the first hour, "the senior management team" is not a decision-maker. One person is.
- **Regulator clocks start from AWARENESS, not from CONFIRMATION.** The 72-hour UK GDPR clock starts when you have reasonable grounds to suspect a breach, not when forensics finishes.
- **Update cadence is non-negotiable.** Even if you have nothing new to say, post "no new information — next update in 30 minutes." Silence creates panic.
- **Good looks like:** four hours in, your scribe's timeline matches the minute-by-minute audit trail, your DPO has a signed decision to notify or not, and no stakeholder found out from social media first.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*