Topic 19 ยท Deep Dive

19.5 Post-Incident Review and Lessons Learned

The Phase Everyone Skips

NIST SP 800-61 calls the final phase post-incident activity, and it is the cheapest security improvement money can buy — which is why teams quietly cancel it once the servers are back. Run the review within days, while memories are fresh and log retention windows have not rotated the evidence away. Run it blamelessly: the question is what the process missed, not who to punish. Blame produces concealment, and concealment produces the next breach.

Rebuild the Timeline First

The central artifact is a single merged timeline: initial access, privilege escalation, lateral movement, objective actions, detection, containment, recovery — stitched from EDR, authentication, proxy, VPN, and firewall logs, cross-checked against the chain-of-custody record. Three numbers fall out of it: dwell time between compromise and detection (MTTD), time from detection to containment, and total outage duration (feeding MTTR). These metrics are the incident's scoreboard and the only honest baseline for claiming the program improved.

Findings Become Runbook Edits

A retro that ends in prose changes nothing; a retro that ends in edits does. Every gap gets an owner and a date: a new detection rule for the technique that was missed, a containment decision the team improvised because the runbook was silent about it, an out-of-date contact tree, a backup restore that took nine hours in practice instead of the documented two. Mapping findings back to lifecycle phases shows where the weakness concentrates — slow detection points to monitoring coverage, slow containment to unclear authority and missing playbooks.

Prove It in the Next Exercise

Improvements are claims until retested. Tabletop exercises feed this loop from the other side: replay the same scenario shape, apply the updated runbook, and see whether the fixes hold under time pressure. Then close formally — archive evidence per retention policy, file final reports to insurers and regulators where required, and update metrics so leadership sees a trend line, not a horror story.

Architecture Diagram

Post-incident improvement loop Close incident archive + report Timeline review MTTD / containment Gap list owner + date Update runbook detection + playbooks Retrain tabletop retest fixes verified
Lessons learned is a cycle, not a meeting — gap-list edits only count once the next exercise retests them.

Key Takeaways

« Back to Topic 19« 19.4 / 19.6 »