---
name: incident-postmortem
description: Reconstructs a technical incident from timelines, tickets, chats, monitoring evidence, and impact data, then produces a blameless postmortem with causes, gaps, and owned corrective actions. Use for service outages, security incidents, production failures, incident reviews, and lessons-learned reports.
license: Apache-2.0
metadata:
  adlass.categories: "it-security/incidents-postmortems, projects-pmo/retrospectives"
  adlass.industries: ""
  adlass.tags: "incident, postmortem, root-cause, outage, remediation, lessons-learned"
  adlass.adaptation: "reference-doc"
  adlass.source: "original"
  adlass.version: "1"
---

# Incident postmortem

## Purpose

Turn fragmented incident evidence into a precise account of what happened, what customers or internal users experienced, why safeguards failed, and which actions reduce recurrence. Keep facts, inferences, and unresolved questions distinct.

## Scope

One incident from first signal through recovery and follow-up evidence, including technical and operational contributors. **Excluded:** assigning blame, changing systems, contacting customers, or declaring legal or regulatory conclusions.

## Data basis

- Incident timeline, tickets, chat or bridge transcript, and monitoring extracts.
- Impact measurements such as duration, affected users, transactions, or revenue.
- Postmortem template, severity policy, and prior related incidents.

## Result

A postmortem document, an action-item sheet with owners and evidence, and a factual external-summary draft when the source scope supports one.

## Quality criteria

- Every timeline event cites its source and timestamp.
- Impact numbers reconcile to the supplied measurements.
- Root cause is separated from trigger and contributing conditions.
- Every action has an owner, target date, and completion evidence.

## Instructions

Use neutral descriptions of decisions and conditions. Mark any inferred cause as a hypothesis and list the evidence supporting it. Do not turn silence in the record into proof that a control worked. Preserve uncertainty and conflicting timestamps. Use the severity vocabulary in the incident policy; otherwise state that no policy mapping was available.

The review should make the population, calculation basis, and exception treatment understandable to a second operator. Preserve source identifiers in every working table, and state the effect of missing evidence on the decision. A reviewer must be able to reproduce each material result from the cited rows, clauses, dates, or policy rules. Where two sources disagree, show both values and explain which source was treated as authoritative.

## Adapt before use

- Add the company postmortem template and incident-severity policy.
- Define the required impact measures and time zone for timestamps.
- Specify action-owner naming, target-date, and closure-evidence conventions.
- Decide whether an external summary is allowed and which details must be excluded.