# Post-mortem template exists

- **Pattern:** `ab-001994` (`operational-resilience-email.incident-response.post-mortem-template`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001994
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001994)

## Why it matters

Without a post-mortem template, email incidents end when sends resume — the root cause, contributing factors, and action items are never formally captured. The same misconfiguration repeats. NIST SP 800-53 IR-5 (Incident Monitoring) and ISO 25010 reliability.recoverability both require that incidents are tracked and that learnings feed back into system improvements. A template is not bureaucracy — it is the mechanism that converts a painful incident into a concrete backlog item that prevents recurrence.

## Severity rationale

Low because missing post-mortems cause recurring incidents rather than immediate failures — the impact accumulates over months as the same root causes repeat without structural fixes.

## Remediation

Create `docs/templates/post-mortem.md` with at least five sections:

```markdown
# Incident Post-Mortem

**Date:** YYYY-MM-DD
**Severity:** P1 / P2 / P3
**Duration:** HH:MM (detection to resolution)
**Affected:** [N emails affected] [N contacts impacted]

## Timeline
- HH:MM — [event]

## Root Cause
[One paragraph]

## Contributing Factors
- [Factor]

## What Worked
- [Item]

## What Didn't Work
- [Item]

## Action Items
| Action | Owner | Due |
|--------|-------|-----|
| | | |
```

Reference this template from the deliverability incident runbook (`docs/runbooks/deliverability-incident.md`) so it is findable after every incident. A template with fewer than 5 sections does not satisfy this check.

## Detection

- **ID:** `post-mortem-template`
- **Severity:** `low`
- **What to look for:** Look for a post-mortem or incident retrospective template in the repository — a markdown file, Notion template link in the README, or documentation structure that guides post-incident analysis. A good template covers: incident timeline, root cause, impact (emails affected, contacts impacted), contributing factors, what worked, what didn't, and action items with owners and due dates.
- **Pass criteria:** A post-mortem template exists with at least 5 sections (timeline, root cause, contributing factors, what worked/didn't, action items) and is referenced from the incident response runbook or engineering documentation. Enumerate the sections present in the template.
- **Fail criteria:** No post-mortem template exists. Incidents pass without structured retrospective. Or the template has fewer than 5 sections.
- **Skip (N/A) when:** The project is a personal side project with a single operator who maintains informal notes — confirmed by a solo contributor history.
- **Detail on fail:** `"No post-mortem template found — email incidents are not followed up with structured retrospectives"` or `"Runbook mentions 'do a post-mortem' but no template or guidance exists"`
- **Remediation:** Create `docs/templates/post-mortem.md`:

  ```markdown
  # Incident Post-Mortem

  **Date:** YYYY-MM-DD
  **Severity:** P1 / P2 / P3
  **Duration:** HH:MM (detection to resolution)
  **Affected:** [N emails affected] [N contacts impacted]

  ## Timeline
  - HH:MM — [event]

  ## Root Cause
  [One paragraph]

  ## Contributing Factors
  - [Factor]

  ## What Worked
  - [Item]

  ## What Didn't Work
  - [Item]

  ## Action Items
  | Action | Owner | Due |
  |--------|-------|-----|
  | | | |
  ```

---

## External references

- iso-25010 reliability.recoverability
- nist IR-5

Taxons: operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-001994