The Review Phase: The Step the Lifecycle Saves for Last
Prepare > Detect > Contain > Eradicate > Recover > Review
This should sound pretty familiar by now. This was the incident response lifecycle outlined in NIST SP 800-61 Rev. 2 until April 3rd, 2025. This flow has changed somewhat in Rev. 3 (published April 2025), but the basic tenets are still there. Rev. 3 puts more emphasis on the Review phase which is the topic of this article. The meeting titles come in many flavors: Lessons Learned meeting, Post-Mortem (my personal preference), post-incident recap, etc. But no matter what you call them at your organization, they are an important part of Incident Response and your overall security posture.
Why Post-Mortems Fail
Post-mortems are critical to the success of an IR program. The purpose of these meetings is to review a recent incident, discuss what went well, what didn’t, and identify any possible improvements. These improvements can range from required updates in runbooks or the Incident Response Plan, locking down some VLANs, or call for a review of an entire process. My colleagues probably have a drinking game set to trigger on me saying “continuous improvement”, but you can’t improve things you don’t identify. I take these meetings seriously and have seen the positive results that come out of them.
Some organizations skip these entirely. Some hold them, but then don’t take the time to identify any security gaps or don’t bother to remediate them. These are simply held for the sake of needing to do it to check a box, à la Security Theater. If you aren’t acting on the information identified in these meetings, you would be better off skipping them entirely and spending that time on making any other improvements to your organization’s security posture that you can. You probably won’t reduce the likelihood of a similar incident occurrence, but at least you’re working on something other than checking a box.
A post-mortem with no follow-through isn't a security practice, it’s Security Theater.
How I Run Mine
I can’t outline how to run post-mortems in a perfect way, because there is no perfect way to run them. I have made the post-mortem itself part of a post-mortem to even improve that portion of my IR program. Every organization runs differently and post-mortems should reflect that.
The first step is to determine why you want to have these meetings. If it’s to check a box, see above. Make the meeting an email and keep it moving. If you want to seriously improve your organization’s ability to respond to incidents and reduce the likelihood of recurrence, then take some time to consider how you want these meetings to run.
I like to invite anyone who worked on the incident, including employees outside of my team. I also invite their managers as optional attendees, and any directors that may be interested. Inviting different levels gives better input during the review and helps identify more issues. For example, the boots-on-the-ground tech may give a reason for a gap that the director didn’t know existed.
The Scenario: An AitM Account Compromise
I’ll be weaving in and out of explanation and example below. For this post-mortem, let’s say we just resolved an incident regarding a user account compromise via an Attacker-in-the-Middle (AitM) attack. The user interacted with a phishing email, was directed to a bogus login page that was proxying to a legitimate one, and the attacker intercepted the credentials and MFA.
Setting the Tone
I start every meeting with the same statement: “A post-mortem is a no-blame review of an incident and is solely focused on improving our security posture and the IR program. This meeting isn’t about finger-pointing, it’s about objectively identifying gaps so they can be patched up.” No one likes admitting fault, especially publicly. I use this statement to set the tone and will also throw in reminders during the meeting if I feel that the group is still wrestling with the concept.
Keep it High-Level at First
I’ve found success by giving a high-level overview of the incident. Some attendees may not have a technical background, so explain how the attack occurred without using technical jargon if possible. Using our example, I would start this post-mortem with a simple graphic showing the basic kill chain of an AitM attack. I’d cover how the attack works in general, then outline how our incident occurred.
The Timeline: Putting the Response on the Slab
I follow this up with a timeline of response efforts with dates and timestamps to level-set the response so an objective evaluation on the response can take place. I like to break this up by the NIST SP 800-61 Rev. 2 phases at the top of this article, but that isn’t always possible. Make sure you cover the major events and times. I also like to state Time-to-Containment and Time-to-Recovery during this portion.
Root Cause: Keep It Short, Keep It Honest
Next, I cover the root cause and contributing factors. I keep this short and objective, one to two sentences usually handles it. Example: User interacted with a phishing email which directed them to an AitM site. They entered their credentials and MFA code which allowed the attacker to intercept them, causing the compromise.
The Uncomfortable Part
This is the most uncomfortable part of the process, and it may take multiple post-mortems to get a handle on this. This is where you try to shine a light on the dark corners that no one really wants to see. I generally repeat my “no-blame” statement here before starting, and I always start with gaps in my IR program, or my response actions. I have found that this sets the tone for a more open collaboration. As always, BE OBJECTIVE. However, don’t pull back to spare feelings either. Truly analyze response and flag anything during the process that was a concern. Did Time-to-Containment meet your SLA? What about Time-to-Recovery? Were you waiting on a response for too long? Provide timestamps here as evidence of your findings.
Bringing It Home: Lessons Learned and Recommendations
This is where you bring it all home. Again, I start with anything I have identified that can improve my program or response. You don’t need to have a solution to every gap on the call, but you do need to clearly identify the problem. “The runbook for this incident felt cumbersome to follow, some of the steps felt out of order and it delayed response.” is perfectly fine. Create an action item to review it after the call and make changes.
Continue this process for your findings, then open it up to the group. If no one chimes in, pick a responder outside of the team and ask a leading question. “How was communication during this incident? Did you feel like you had the information you needed? Can we improve communication during an incident?” Open-ended questions can often get the conversation moving.
Like with any working call, be sure to assign action items as they come up!
Before You Close the Ticket
Before closing out the incident, take whatever steps your organization uses to identify risks that require follow up such as putting them in the risk register or creating control failures. Follow up on the identified gaps, or all of the time put into this process was wasted (see again about making this meeting an email).
What Starts to Change
After a handful of these meaningful post-mortems, you should notice a few changes. The meetings will morph into something more comfortable for your team and organization as a whole. Your invitation list will change as some departments will be more interested than others. You may start to send meeting notes to executive leadership so they are aware of the incident and that security is taking steps to shore up the defenses, and maybe set a tone for larger budgets (cough cough. What started as an uncomfortable review of a bad week becomes one of the most valuable hours on your security calendar.
Be open, be objective, and be collaborative. You’ll find that not only does your IR program improve, but your overall security program will get more buy-in from the organization.