# Incident Response Runbook

**Framework:** Detect → Contain → Eradicate → Recover → Post-mortem  
**Use for:** Running a security incident on a process you decided in advance, not one you invent at 2 AM  
**Time required:** 30–60 minutes to prepare in advance, then minutes to follow when it counts

---

## How to use this template

1. Fill this in before an incident, not during one. The whole point is to move the decisions that can be made calmly out of the moment when they can't. An incident where everyone is figuring out the process for the first time takes far longer and creates more damage.
2. Name the people and the thresholds now. Who declares an incident, who can take a system offline, when legal gets called, when the CEO does — those answers should already be on the page when the alert fires.
3. Pre-authorize the containment actions you would otherwise hesitate over. "Isolate the affected host" is a fast call when it was approved in advance and a slow one when it needs a meeting.
4. Run it twice a year as a tabletop. Pick a scenario ("ransomware hit the billing database at 11 PM on a Friday"), talk through the response without touching production, and fix the gaps the walk-through surfaces. Two per year is enough to build the muscle memory that lowers MTTR.
5. Keep the notification clock visible. Regulatory windows start at discovery, not at resolution. Missing one adds legal liability on top of the incident itself.

---

## Roles — fill in before an incident

| Role | Who | Responsibility |
|------|-----|----------------|
| Incident commander | [Name / on-call] | Runs the response, owns the decisions, the single point of coordination |
| Who can declare an incident | [Name / role] | Turns "an alert" into "an incident" and starts this runbook |
| Who can take systems offline | [Name / role] | Pre-authorized to contain: isolate hosts, revoke access, pull a service |
| Communications lead | [Name] | Owns internal updates and any external or customer messaging |
| Legal / privacy | [Name] | Owns breach-notification obligations and the clock |
| Executive escalation | [Name — at what threshold] | When leadership or the CEO gets paged |

> Incident response is not only a security-team function. A real incident pulls in legal (notification duties), communications (customer messaging), engineering (containment), and often finance and leadership. Build those relationships before you need them, not in the first two hours of a live event.

---

## Severity — set the level first; it sets everyone's response

| Sev | Meaning | Example | Response |
|-----|---------|---------|----------|
| **SEV1** | Critical. Active breach, data exfiltration, or core service down. | Customer data being exfiltrated; ransomware spreading | All-hands, incident commander, exec and legal paged now |
| **SEV2** | High. Serious but contained, or a credible threat. | Single compromised account, no spread confirmed | IC plus security on point, leadership informed |
| **SEV3** | Low. Limited scope, no sensitive data, no spread. | Phishing click with no credentials entered | Handle in-hours, log it, no escalation |

**This incident's severity:** [SEV1 / SEV2 / SEV3], set by [name] at [time]

---

## The five phases

### 1. Detect
- [ ] Alert source and time recorded: [what fired, when]
- [ ] Incident declared by [name] at [time] — **the MTTD clock (Mean Time to Detect) is the gap from first compromise to this moment.** Shrinking it is where most of the leverage is; many breaches sit undetected for weeks.
- [ ] Severity set (above)
- [ ] Incident channel opened, incident commander assigned

### 2. Contain
- [ ] Stop the spread before chasing root cause. Isolate affected systems, revoke compromised credentials, block the indicator.
- [ ] Preserve evidence before you wipe anything: snapshots, logs, memory. You will need it for the post-mortem and possibly for legal.
- [ ] Containment actions taken: [list with times]

### 3. Eradicate
- [ ] Find and remove the root cause, not just the symptom: the malware, the backdoor, the misconfiguration, the exposed key.
- [ ] Confirm the attacker no longer has access. Rotate every credential that was, or could have been, exposed.

### 4. Recover
- [ ] Restore services from clean backups, and verify integrity before going live.
- [ ] Monitor closely for recurrence. The same actor often tries again.
- [ ] Service restored at [time] — **this closes the MTTR clock (Mean Time to Recover): declaration to restoration.**

### 5. Post-mortem
- [ ] Schedule within [X] business days, while memory is fresh.
- [ ] Run it blameless (see below).

---

## Communication — runs across all five phases

Communication during an incident is as operationally important as the technical response. Decide who says what, internally and externally, before you need to.

**Internal:** [name] posts status updates every [cadence] to [channel]. Leadership informed at [threshold].

**External and regulatory — the clock starts at discovery, not at resolution:**

| Trigger | Window | Owner |
|---------|--------|-------|
| Personal-data breach, EU residents (GDPR) | 72 hours to the supervisory authority, plus affected individuals "without undue delay" if high risk | [Legal] |
| Personal-data breach, US consumers | Most states 30–60 days to affected consumers (varies by state) | [Legal] |
| Material cybersecurity incident, US public company (SEC) | 4 business days, Form 8-K | [Legal / IR] |

> Do not send external notifications without legal sign-off. Getting the facts wrong in a regulatory filing is its own problem.

---

## Blameless post-mortem

Not a hunt for who made the mistake. A systematic inquiry into what systemic conditions let it happen and let it persist.

**Answer these:**
1. What failed, and when?
2. Why did it fail? (Keep asking "why" past the first answer.)
3. Why did our detection, alerting, and response not catch it faster? (MTTD and MTTR are the numbers to interrogate.)

**Output owned action items, not a fault narrative:**

| Action item | Owner | Due | Status |
|-------------|-------|-----|--------|
| [Specific, systemic fix] | [Name] | [Date] | [ ] |
| | | | [ ] |
| | | | [ ] |

An incident that produces three completed action items made the organization more resilient. One that produces a personnel change without a systemic fix will recur.

---

## Incident record

| Field | Detail |
|-------|--------|
| Incident ID / date | [ID — date] |
| Severity | [SEV1 / SEV2 / SEV3] |
| MTTD (compromise → detection) | [duration] |
| MTTR (declaration → restoration) | [duration] |
| Data / systems affected | [scope] |
| Notifications required and sent | [who, when] |
| Post-mortem link | [location] |

---

*The decisions you make in advance are the ones you will not have to make under pressure. Run the tabletop before you run the real thing. More on incident response, MTTD, MTTR, and breach notification in the Security & Compliance Guide at biztechprimer.com.*