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.
Step 4: turn factors into few, owned actions
Write five to eight actions in the actions spreadsheet (<incident-id>-actions.csv), not twenty. Sort each into prevent, detect sooner, respond faster or reduce impact. Each action has an owner role, a due date agreed with that owner, the record it produces, and how you will check it worked. Then propose linked updates for each record's owner to make:
- Risk register: an incident that happened means the likelihood was underestimated, or the risk had been accepted; re-score or record the acceptance decision again.
- Controls: any control that failed or was missing, with the evidence.
- Playbooks and contact tree: what the responders had to improvise.
- Supplier records: if a supplier caused, slowed or helped the response.
- Training: only when knowledge was the gap, never as the only action.
If a regulator or customer expects a final report, reuse the timeline and factors; do not write a second version of events.
Step 5: close the loop
Propose a follow-up date after the latest due date to verify each action, and draft tracker-ready rows for the action owners to enter. Draft a short summary for the incident lead to share beyond the responders; for SEV1 and SEV2, the incident lead takes the summary and any overdue actions to the next management review. Compare factors with earlier reviews: a factor that appears twice means the previous action did not work.
What good looks like
- The timeline is sourced line by line, and the times to detect, contain and recover are stated as numbers.
- A strong practitioner looks for the gap between "first signal" and "detection" first; it is usually the biggest and the cheapest to shrink.
- The common mistake is a review that ends in "staff to be more careful" and "retrain users". That is a conclusion about people, not about the conditions, and the incident repeats.
- The tell that it went wrong: actions without owners or dates, the risk register unchanged after a SEV1, and the same factor appearing in two reviews.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-post-incident-review
Rules
- MUST cite the record behind every timeline entry, in UTC.
- MUST give every action an owner role, an agreed due date and a way to check it worked.
- MUST write outputs only inside
./post-incident-review/ and ask before overwriting.
- NEVER name an individual as the cause of the incident; write about roles and conditions.
- NEVER update the risk register, close tickets or change controls directly; propose the changes to their owners.
- NEVER copy personal data, credentials or customer records from logs into the review.