# Incident Report

| | |
|---|---|
| **Incident ID** | |
| **Date** | |
| **Severity** | Critical / High / Medium / Low |
| **Duration** | ___ from detection to resolution |
| **Customers affected** | |
| **Data affected** | |
| **Incident lead** | |
| **Status** | Open / Resolved / Closed |

> Blameless. The goal is a system that fails less, not a person to blame.
> People act reasonably given the information they had; if the outcome was bad,
> the system let them.

---

## 1. Summary

> Three sentences a non-technical executive can follow. What broke, who was
> affected, whether it is fixed.

## 2. Customer impact

**What customers experienced:**

**How many:**

**For how long:**

**Was data lost, exposed or corrupted?**

**Was anyone notified? When, by whom?**

## 3. Timeline

> Facts with timestamps. Include when you *thought* something was true and later
> found it was not — that gap is usually where the real lesson is.

| Time | Event | Source |
|---|---|---|
| | Change deployed / condition began | |
| | First symptom occurred | |
| | **Detected** — how? | |
| | Escalated to | |
| | First mitigation attempted | |
| | Root cause identified | |
| | **Resolved** | |
| | Monitoring confirmed stable | |

**Time to detect:** ___   **Time to mitigate:** ___   **Time to resolve:** ___

> If time-to-detect is long, that is a finding in itself.

## 4. What happened

> The technical narrative. Enough that a colleague could follow it without
> having been there.

## 5. Contributing factors

> Not "the root cause". Incidents in real systems have several. Listing one
> encourages a single narrow fix that leaves the others in place.

| # | Factor | Category |
|---|---|---|
| 1 | | Code / Config / Process / Monitoring / Dependency / Documentation |
| 2 | | |
| 3 | | |

**Why did our defences not catch it?**
- Testing:
- Review:
- Monitoring:
- Alerting:

## 6. What went well

> Genuinely worth recording — it tells you which controls to keep investing in.

## 7. What made it worse

> Slow detection, missing runbook, unclear ownership, a rollback that did not
> work, an alert nobody saw.

## 8. Actions

> Every action has one named owner and a date. "The team" is not an owner.
> An action without a date does not happen.

| # | Action | Prevents recurrence / Reduces impact / Improves detection | Owner | Due | Status |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |

## 9. Follow-up

| | |
|---|---|
| Review meeting held | |
| Attendees | |
| Report circulated to | |
| Actions verified complete on | |

---

## Severity guide

| Severity | Definition |
|---|---|
| **Critical** | Core business function unavailable, or data lost/exposed. All hands. |
| **High** | Major function degraded, or a workaround exists but is painful. |
| **Medium** | Limited impact, acceptable workaround. |
| **Low** | Minimal impact, no urgency. |