Use this after every SEV1 and SEV2, for a sample of SEV3s (one per recurring theme per quarter, with the reason it was picked recorded in the review), and for any near miss that would have been a SEV1. You get two files per incident in a new folder, ./post-incident-review/: the written review with the timeline, what contributed and what went well (<incident-id>-review.md), and a spreadsheet you can open in Excel listing the follow-up actions with owner, due date and how to check each worked (<incident-id>-actions.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. Hold the review within about five working days, while memory is fresh and before the next incident pushes it out.

Inputs to gather

Read the triage record, the incident ticket, chat channel exports, alert history, relevant logs, notification records, the incident response plan and playbook used, the risk register entries for the affected assets, and earlier reviews on the same systems. Ask the reader, in one message: who took part in the response, who owns the affected systems, whether any regulator or customer expects a final report, and whether the team has had a review end in blame before (it changes how you run the meeting).

Step 1: build the timeline before the meeting

Reconstruct from records, not memory: first signal, detection, awareness, escalation, containment, recovery, notifications, closure, all in UTC with the source of each entry. Compute time to detect, time to contain and time to recover. Mark gaps where nothing happened for more than an hour during a SEV1, and points where a decision waited for someone. The incident lead shares the draft timeline with participants before the meeting so they correct facts, not argue them live. Chat exports and logs often expire before the next audit: note where each cited source is retained and until when, and propose that the incident lead archives a redacted copy in the incident record.

Check notification against the timeline: which regulatory or contractual clocks applied (for example GDPR Article 33 for a personal data breach, NIS 2 Article 23 for a significant incident, customer notice windows), when each started and whether it was met. Record "none applied" with the reason when that is the answer. A missed notice found now can still be remedied.

Step 2: run the discussion blameless

Propose a 60 to 90 minute session for the incident lead to book with the responders, the system owners and a facilitator who did not respond. In a small team where everyone responded, take the facilitator from another function or from outside, and say so in the review. Ground rule, said at the start: people acted reasonably on what they knew at the time; the review looks for the conditions that made the mistake possible. Ask "what did you know at that moment", "what made that look like the right action", "what would have told you sooner". Never ask "why did you". A review that names a culprit teaches everyone to hide the next near miss.

Step 3: find contributing factors

Incidents rarely have one root cause. List the factors across detection (why it was not seen sooner), decision (what slowed the call), tooling, communication, knowledge held by one person, supplier behaviour, and the plan itself. Compare the response with the plan: where the team departed from it, was the plan wrong, unknown or impractical? Record what went well too; it tells you what not to break.