The incident is contained, the systems are back, and everyone wants to move on. That's exactly when the most valuable security work of the year is available to you. A breach or near-miss is a stress test you didn't have to simulate: it shows you which controls actually worked, which were theater, and where your assumptions were wrong. Skipping the review wastes that information.
This checklist is for the review that happens after containment — the one about improving the program, not the forensic report about what happened. It applies to real incidents and to near-misses, which deserve the same honesty and are much cheaper teachers.
Why review after an incident?
Because the incident already told you the truth about your defenses. Whatever your policies said would happen, something different actually happened, and the gap between those two is your roadmap. Organizations that review incidents properly rarely get hit the same way twice. Organizations that don't, do.
There's a second reason: insurers, regulators and customers increasingly ask what you learned and changed after an incident, not just whether you survived it. "We had an incident, reviewed it, and here's what we fixed" is a far stronger answer than silence.
When to hold the review
Within one to two weeks of containment. Earlier and people are exhausted and defensive; later and memories fade, logs rotate, and the organization has already rewritten history in its head. Schedule it before the incident closes, so it can't quietly never happen.
Keep the review separate from forensics and from any legal work. The forensic report establishes facts; the review decides what to change. If notification duties, regulators or litigation are involved, involve counsel on how the review is documented — be factual, don't speculate in writing.
And keep it blameless. A review that assigns blame produces silence at the next one, and silence means the same gap stays open.
The post-incident review checklist
Work through all seven items, even the ones that feel obvious. Near-misses count as incidents for this purpose.
1. Timeline and root cause
Rebuild the timeline from evidence, not memory: initial access, what happened next, when anyone noticed, when containment started. Then keep asking why until you reach something fixable. "An employee clicked a link" is not a root cause; "we had no way to catch a stolen session token" is closer.
2. Which controls failed
Name them specifically. Did email filtering miss it? Did MFA not cover that system? Did EDR alert but nobody saw it? Each failed control gets one of three verdicts: misconfigured, missing, or bypassed despite working as designed. The verdict decides the fix.
3. Which controls worked
Write these down too. Containment that went fast, the backup that restored, the alert that fired — these justify their budget and tell you what to extend. A review that only lists failures teaches the wrong lesson.
4. Detection and response speed
Three numbers: how long until someone noticed, how long until containment, and how much of that was luck. If discovery came from a customer call or a ransom note rather than your own monitoring, that's a finding about visibility, not about this one incident.
5. Vendor and third-party exposure
Did a vendor cause it, contribute to it, or learn about it from you? Check which vendors touch the affected systems or data, whether your contracts were followed, and whether their incident obligations worked as written.
6. Obligations and communications
Were notifications made on time — insurer, regulator, customers, contracts? Who decided, and how hard was it to reach them? If the notification clocks were confusing or the contact list was stale, fix that in the incident response plan now, not during the next incident.
7. Follow-through on past findings
The uncomfortable one: was this incident caused by something a previous review, audit or risk assessment already flagged? If yes, the problem isn't the control — it's the process that lets findings sit. That goes to leadership, not to IT.
Questions that surface real lessons
Ask these in the room, in a blameless tone:
- What did we assume was true that wasn't?
- Where did we get lucky, and what would have happened without the luck?
- What did the attacker see that we can't see ourselves?
- Which step of our response plan did we actually follow, and which did we improvise?
- What would have caught this earlier, and what would that have cost compared to the incident?
- If this same attack happened next quarter, would the outcome be any different?
- Who knew about this weakness before the incident and didn't have a way to raise it?
Making changes stick
Most post-incident improvements die in the same place: a long list of actions, no owners, and a business that has moved on. Three habits prevent that:
- Few, owned, dated. Cap the action list at the ten most important changes. Each gets a named owner and a date, with the urgent ones inside 30 days.
- Verify, don't assume. "MFA is now enforced" needs a check, not a belief. Where the fix is testable, test it — a tabletop exercise a month later is a good way to confirm the response changes work with real people under mild pressure.
- Report upward. Leadership approved the budget for this incident's response; show them what it bought. A one-page summary of what failed, what worked and what's being changed belongs in front of whoever owns the risk. Our guide to reporting security posture to the board has a format that works.
Finally, fold the lessons into your regular cycle. The findings from this review become agenda items for your next annual cybersecurity review, and the open actions get tracked there until they're done.
Frequently asked questions
How soon after an incident should we do the review?
Within one to two weeks of containment, while memory and logs are fresh. Separate it from forensics and legal work: the review is about improving the program, not establishing the record of what happened.
Who should run the review?
Someone who isn't defending their own decisions during the incident. For small teams that's often an outside facilitator. Keep it blameless — reviews that assign blame produce silence, and silence means the same gap stays open.
Does the review create legal exposure?
It can if the incident involved notification duties, regulators or litigation. Involve counsel when that's the case, keep the review factual, and don't speculate in writing. Improving your program after an incident is normal and expected; hiding findings is what creates exposure.
Key takeaways
- An incident is a free stress test of your defenses — the post-incident review is how you collect the results.
- Hold it within two weeks of containment, blameless, and separate from forensics and legal work.
- Check seven areas: timeline, failed controls, working controls, detection speed, vendor exposure, obligations and past findings that recurred.
- Cap the action list, assign owners and dates, and verify fixes by testing them.
- Near-misses deserve the same review. They're the cheapest lessons you'll ever get.