The post-incident decision review
The incident is closed. Now the harder question: what did it mean, what was luck, and what has to change. Here is how to make AI run that review without flattering the response.
After an incident, a security leader needs a review that names the systemic gap rather than the convenient one, and that does not mistake a lucky outcome for a good response. Commodity AI does the opposite: it writes a clean, generic lessons-learned and reasons backward from the result. The Havruta Methodology (formerly the Think Partner Methodology) makes the machine argue the counter-case and request the real timeline, what was actually known at each point, and where the outcome turned on luck, before it concludes. This is not an incident-response tool. It is how the leader reasons with AI on the review that decides what changes.
The situation
The incident is closed and the relief is real. The harder work starts now. The review is due while the detail is fresh, it has to name a gap that is systemic rather than convenient, and it has to do that without turning into a blame exercise that teaches the next responder to hide what they saw. Everyone in the room is quietly inclined to call the response good, because it worked.
What commodity AI does with it
Ask for a "lessons-learned report" and you get a tidy retrospective that praises the response, lists three improvements, and quietly turns a lucky outcome into a story of competence. It reasons from the known result, which is the trap. It cannot tell the difference between a response that was good and one that merely worked, because it never asked what anyone actually knew in the moment.
The Flip: argue it was luck
The move is to make the machine take the position no one in the room wants to voice: that the response succeeded by luck, not design, and that the comfortable root cause is hiding the real one. To do that honestly it has to reason in foresight, starting the timeline before anyone knew the outcome, which is how you fight the hindsight bias that makes every review too kind.
What the machine must ask before it concludes
Before it writes a line, it requests what the tidy template skips:
-
What was the real timeline, and what was actually known at each point, not what you know now?
-
What did the on-call see on the dashboard in the moment, and what did they reasonably assume?
-
Which containment trade-offs were made under pressure, and what was given up to make them?
-
Where did the outcome depend on something outside your control going your way?
-
For a material incident, what informs the materiality judgement, and who owns it with you?
That request is Ground Truth: the machine reasons from what actually happened, not from a plausible incident.
The comfortable conclusion
The review everyone expects: the response was good, because it worked. The seam in the story goes unexamined.
The Flip argues it was luck
The machine takes the position no one will voice and presses on the seam, reasoning forward from before anyone knew the outcome.
The real systemic gap
Not the convenient root cause: the place where the outcome held by assumption, where something outside your control went your way.
A corrective action with an owner
The gap closed as an owned action with a date, on a timeline kept blameless so candour survives the next incident.
Write the lessons-learned for the incident we closed yesterday.
First, was the outcome good or lucky? Walk me through what the on-call actually knew when they made the first containment call.
They isolated the segment fast. Honestly, they assumed it was contained there, and it happened to be.
So containment held partly by assumption. If the lateral path had been open, would your detection have caught it, or would you have found out late?
We would have found out late. That is uncomfortable.
Then the systemic gap is detection on lateral movement, not the response speed everyone is praising. I will write it so it names that, keeps the timeline blameless, and gives you a corrective action with an owner.
What you walk away with
A review that names the systemic gap rather than the convenient one, keeps the timeline blameless so candour survives the next incident, and ends in corrective actions with owners and dates an auditor can see were closed. For a material incident, a documented reasoning trail that holds up to later scrutiny.
The 4-Lines you can run yourself
-
Act as a sceptical reviewer arguing that our incident response succeeded by luck, not skill, and that the obvious root cause is hiding the real one.
-
Goal: a blameless post-incident review that names the systemic gap and ends in owned corrective actions, not a generic lessons-learned.
-
Ask me detailed questions and for supporting data before concluding: the real timeline, what was known when, the containment trade-offs, where the outcome depended on luck. Reason forward from before we knew the result.
-
Ask one question at a time, step by step.
Frequently asked questions
How do I run a post-incident review with AI without it being generic?
By making the machine argue the counter-case rather than summarise. Have it take the position that the response was lucky, not good, and require it to request the real timeline, what was known at each moment, and where luck carried the outcome, before it concludes. The result names a systemic gap instead of flattering the team.
Is this an incident-response or forensics tool?
No. It does not detect, contain, or investigate. It changes how the leader reasons with AI on the review after the incident, the part that decides what actually changes.
How does it avoid hindsight bias and blame?
By reasoning in foresight, starting the timeline before the outcome was known, and by holding the review blameless so responders keep telling you what they actually saw. Both are deliberate moves the methodology installs, not defaults the assistant has.
What about the materiality and disclosure decision?
For a material incident, the disclosure call is a legal and financial judgement you inform but share with your General Counsel and CFO. The methodology helps you assemble and document the reasoning behind it; it does not replace that judgement or your legal advice.
Where do we start?
A single high-stakes review fits Advisory Havruta, a structured session on one strategic question. A Strategic Briefing maps the right entry point.