A cyber security incident is never over when containment ends. The post-mortem is where the real work starts. Yet most Australian IT and security teams treat it as a box-ticking exercise: a short meeting, a half-drafted document, and a list of action items nobody follows up. The predictable result is that the same gaps surface in the next incident.
Post-mortems are not about blame. They're about building an honest account of what happened, why controls failed, and what would have changed the outcome. Done properly, a single post-mortem can surface systemic weaknesses that months of audits missed. Done poorly, it wastes everyone's time and creates a false sense of closure.
Why most post-mortems fail before they start
The most common failure is timing. Teams wait too long. Three weeks after an incident, the people involved have moved on mentally, memory fades, and Slack threads get archived. The ACSC recommends debriefing within five business days of containment for significant incidents, and that's a reasonable ceiling. For serious breaches, 48 hours is better.
A second failure is scope. Teams focus on the technical sequence of events and ignore the organisational ones. When did the alert fire? When did a human actually read it? How long between detection and escalation? These gaps are often where the real damage happened, and they rarely appear in a timeline built from firewall logs alone. If your logging gaps mean you can't answer these questions accurately, that fact belongs in the post-mortem itself.
A third failure: the wrong people in the room. Post-mortems need the incident responders, yes, but also whoever owns the affected system, whoever approved the change that introduced the vulnerability, and whoever maintains the detection tooling. A post-mortem with only the security team present produces security team findings. Most incidents involve failures that cross organisational boundaries.
What a useful post-mortem document actually covers
The document isn't the debrief. The debrief is a conversation. The document is the record that persists and informs future decisions. These are different things, and conflating them produces reports nobody reads.
A useful post-mortem document covers five areas:
- Timeline. A minute-by-minute sequence from first attacker action (or earliest indicator visible in retrospect) to full remediation. Not a summary. A timeline.
- Detection gap. The difference between when the attack began and when it was detected. This number is the most honest measure of your detection capability, and most teams avoid writing it down.
- Contributing factors. Not "root cause." Almost every incident has multiple contributing factors, and privileging one as "the" cause produces single-point fixes that leave the other factors intact.
- What worked. Controls that limited damage, team behaviours that sped up response, runbooks that held up under pressure. These deserve as much attention as what failed.
- Specific, owned actions. Every action item needs a named owner and a due date. Unowned action items are future post-mortem entries.
The detection gap: the number teams hide
Of the five areas above, the detection gap is the one most teams avoid. It's uncomfortable. A team that detected and contained an intrusion in six hours looks far better on paper than one where attackers had twelve days of dwell time before a routine log review caught them.
But hiding the number doesn't change it. It just means you can't improve it. Dwell time in Australian incidents reported under the Notifiable Data Breaches scheme is frequently measured in weeks, not hours. The organisations that improve year on year are the ones that track detection gap explicitly and treat it as a primary metric, not an embarrassment.
If your SIEM is generating alerts that nobody is acting on quickly, that's a detection gap caused by process, not technology. Write it down.
Blameless post-mortems: the concept most teams misapply
The "blameless post-mortem" concept comes from site reliability engineering, and it's genuinely valuable. The idea is that people operate within systems, and when someone makes an error, the focus should be on the system conditions that made the error likely, not on punishing the individual. This produces more honest accounts and better systemic fixes.
Most teams hear "blameless" and interpret it as "accountability-free." That's wrong. Blameless doesn't mean you avoid naming what happened or who was involved. It means you treat the human action as a data point that reveals a system weakness, not as a moral failing. An analyst who missed an alert at 3 AM after a 12-hour shift isn't the problem. The on-call schedule and alert volume are the problem.
The practical implication: run post-mortems with psychological safety explicit from the start. State at the beginning of the debrief that the goal is systemic improvement, that individual errors are in scope as evidence, and that nothing said in the room will be used in performance reviews. Then actually hold to that.
Following up: where the value actually lives
A post-mortem that produces action items nobody implements is worse than no post-mortem. It creates the perception of improvement without the reality, and it makes the next team that tries to run a genuine post-mortem face scepticism from people who've seen the exercise go nowhere before.
Action item follow-up needs to be tracked outside the post-mortem document itself. Most Australian security teams use their existing ticketing system for this. That's fine, but only if the post-mortem actions are tagged distinctly and reviewed at a regular cadence. Monthly is the minimum. Weekly is better in the three months following a significant incident.
There's also a second-order benefit worth capturing. Patterns across multiple post-mortems reveal systemic issues that no single incident surfaces clearly. If your last four post-mortems each produced an action item about alert fatigue, that's not four separate problems. That's one problem that four incidents have now confirmed. A quarterly review of post-mortem action items, grouped by theme, is one of the highest-value activities a security team can run. It pairs well with the kind of structured review that good tabletop exercises also surface: both methods expose process gaps that day-to-day operations conceal.
A practical starting point for teams that haven't built this habit
If your team hasn't run a real post-mortem before, start with the last incident that required escalation. It doesn't have to be a catastrophic breach. A significant phishing campaign, a ransomware attempt that was caught early, a misconfiguration that was discovered before exploitation: all of these are valid subjects.
Set aside two hours. Get the right people in the room. Build the timeline first, before anything else, using actual artefacts: logs, tickets, Slack messages, email threads. Don't rely on memory alone. Then work through contributing factors as a group, treating every factor as a system observation rather than a verdict on a person.
Write it up the same day. Assign owners to every action item before the meeting ends. Review progress in 30 days.
That's it. The process doesn't need to be complex to be useful. It needs to be honest, timely, and followed through. Most Australian security teams can do all three. Most don't, yet.