# Editable incident postmortem worksheet

Use this worksheet after the service is stable. Keep links to restricted evidence rather than pasting secrets or personal data into the document. Replace every bracketed field. If a fact is not known, write `UNKNOWN`; do not smooth it into a confident narrative.

## 1. Document control

| Field | Entry |
|---|---|
| Postmortem ID | [stable ID] |
| Incident title | [service + observable symptom] |
| Severity and policy used | [level + link to policy] |
| Incident window | [start and end, timezone] |
| Evidence cutoff | [ISO 8601 timestamp] |
| Document owner | [role/name] |
| Facilitator | [role/name] |
| Approver | [role/name] |
| Review meeting | [date/time/timezone] |
| Publication state | DRAFT / IN_REVIEW / APPROVED / RESTRICTED |
| Sensitivity | [internal/confidential/security/legal classification] |

## 2. Scope and quick answer

**One-sentence impact:** [what failed, for which measured population, over which exact period]

**Current explanation:** [trigger, direct mechanism and material contributing conditions, each with a state]

**Recovery:** [what was changed, what evidence indicates stabilization, and what remains uncertain]

**This postmortem covers:** [systems, environments, clocks, business process]

**It does not establish:** [customers/users/revenue/security conclusions not supported by the evidence]

## 3. Roles and review authority

| Role | Person or team | Responsibility in this review | May approve |
|---|---|---|---|
| Incident commander | [ ] | response chronology | [ ] |
| Service lead | [ ] | mechanism analysis | [ ] |
| Data lead | [ ] | impact query and denominator | [ ] |
| Observability lead | [ ] | detection evidence | [ ] |
| Security/privacy/legal reviewer | [ ] | disclosure and redaction boundary | [ ] |
| Postmortem approver | [ ] | final state and commitments | [ ] |
| Action owner(s) | [ ] | implementation and verification evidence | [ ] |

## 4. Evidence register

Do not put conclusions in the artifact column. Record what the artifact shows and what it cannot show.

| Evidence ID | Timestamp/time range | Artifact and stable link | Collector | Supports | Limitation | Access class |
|---|---|---|---|---|---|---|
| E01 | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| E02 | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| E03 | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |

**Cutoff rule:** Evidence received after [cutoff] goes into an addendum and requires re-review of any affected claim.

## 5. Impact reconciliation

Define one eligible population and make the outcome rows mutually exclusive. Do not mix attempts, people, accounts and revenue in one rate.

| Outcome category | Query rule | Count | Evidence ID |
|---|---|---:|---|
| [impacted category 1] | [ ] | [ ] | [ ] |
| [impacted category 2] | [ ] | [ ] | [ ] |
| [expected outcome] | [ ] | [ ] | [ ] |
| Eligible total | [ ] | [ ] | [ ] |

Reconciliation: `[category 1] + [category 2] + [expected] = [eligible total]`

Impacted count: `[impacted category 1] + [impacted category 2] = [impacted]`

Impact rate: `[impacted] / [eligible total] × 100 = [unrounded]%`, displayed as `[rounded]%`.

Excluded records and reason: [ ]

## 6. Evidence-backed timeline

Choose one timezone, preferably UTC. Distinguish event time, observation time, report time and decision time.

| Time | Event or observation | Type | Evidence ID | Confidence | Why it mattered |
|---|---|---|---|---|---|
| [ ] | [ ] | event / observation / report / decision | [ ] | confirmed / inferred / unknown | [ ] |

Clock definitions:

- First confirmed impact → detection: [start/end/calculation]
- Declaration → mitigation action: [start/end/calculation]
- First confirmed impact → recovery evidence: [start/end/calculation]
- Why these clocks are not automatically MTTA/MTTR: [organization definition or missing policy]

## 7. Causal analysis with claim states

Use `CONFIRMED`, `PLAUSIBLE`, `DISPROVED` or `UNKNOWN`. A deployment before an incident is a trigger candidate, not automatically the root cause.

| Claim ID | Type | Claim | State | Supporting evidence | Contradicting evidence | Reviewer/next test |
|---|---|---|---|---|---|---|
| C01 | trigger | [ ] | [ ] | [ ] | [ ] | [ ] |
| C02 | direct mechanism | [ ] | [ ] | [ ] | [ ] | [ ] |
| C03 | contributing condition | [ ] | [ ] | [ ] | [ ] | [ ] |
| C04 | alternative explanation | [ ] | [ ] | [ ] | [ ] | [ ] |

System conditions that shaped reasonable decisions at the time: [interfaces, safeguards, workload, documentation and signals—not personal blame]

## 8. Response review

### What reduced impact

[Specific decision or control + evidence]

### What delayed detection, diagnosis or recovery

[Specific system/process condition + evidence]

### Where the team got lucky

[A missing safeguard whose absence did not worsen this incident, plus a follow-up if material]

### Communication and escalation

[Audience, time, message owner, missing/late/accurate information, and required policy review]

## 9. Corrective actions and effectiveness

Use `OPEN`, `IN_PROGRESS`, `IMPLEMENTED`, `EFFECTIVENESS_VERIFIED` or `ACCEPTED_RISK`. Do not equate a merged change with a verified result.

| Action ID | Risk or failure mode addressed | Change | Owner | Due | Priority | Current state | Verification contract | Evidence link |
|---|---|---|---|---|---|---|---|---|
| A01 | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [observable test + threshold + reviewer] | [ ] |

Review cadence: [weekly/date]

Escalation when overdue or failed: [role/process]

Closure authority: [role]

## 10. Approval, redaction and follow-up

- [ ] Impact denominator and arithmetic peer-reviewed.
- [ ] Timeline links resolve for authorized reviewers.
- [ ] Causal claims carry a state and evidence.
- [ ] Security, privacy, legal and customer-communication reviews completed where required.
- [ ] Secrets, personal data and unnecessary customer identifiers removed.
- [ ] Every accepted action has an owner, due date and verification contract.
- [ ] Unknowns and rejected alternatives remain visible.
- [ ] Approver recorded the publication state.
- [ ] A follow-up date exists for action effectiveness.

Approval record: [approver / timestamp / decision / conditions]

Addenda: [late evidence, changed conclusion, re-approval]

---

This worksheet is an editorial aid, not legal, security, compliance or incident-response advice. Adapt it to your incident policy and obtain qualified review for high-severity or regulated events.