Post-Incident Review: How to Learn from a Cyber Attack

Surviving a cyber attack is stressful. Once the threat is contained and your systems are back online, the temptation is to move on as quickly as possible and put the whole experience behind you.

That's understandable — but it's also a missed opportunity. The businesses that become genuinely more secure over time are the ones that take time to learn from every incident, large and small. That's what a post-incident review is for.

What Is a Post-Incident Review?

A post-incident review (sometimes called a post-mortem or after-action review) is a structured meeting held after a cyber incident where your team examines:

• What happened and how
• How your team responded
• What worked well and what didn't
• What changes you'll make to prevent or better handle a similar incident in the future

The goal is improvement, not blame. A good review focuses on systems, processes, and decisions — not on finding someone to fault. That distinction matters for creating a culture where people are honest about what went wrong.

When to Run the Review

The review should happen within two weeks of the incident being resolved — close enough that everyone's memory is fresh, but with enough distance that the immediate stress has settled. For significant incidents, some organisations do a brief initial review within 48 hours and a deeper review a week or two later.

Who Should Be Involved

Invite everyone who played a role in the incident or response:

• The staff member who first noticed the incident
• Anyone involved in the technical response
• The business owner or incident lead
• Your IT provider if they were involved
• The person who handled communications

If the review is going to be useful, people need to feel safe being honest. Set the tone before the meeting starts: this is about improving systems, not assigning blame.

The Review Process

Step 1: Build a Timeline

Start by reconstructing exactly what happened and when. Use logs, emails, and team recollections to piece together a chronological account: when the attack started, when it was detected, what actions were taken at each stage, when the incident was contained, and when systems were restored.

This timeline will often reveal things that weren't obvious during the response — for example, that the attack had been active for longer than you realised, or that a particular step in your response took far longer than it should have.

Step 2: Identify What Worked

Before diving into problems, acknowledge what your team did well. Did someone notice the incident quickly? Did your backup recovery go smoothly? Did your communications go out promptly? Recognising success reinforces good practices and builds team confidence.

Step 3: Identify What Didn't Work

Now look at the gaps. Common issues that emerge in post-incident reviews include:

• No one knew who was supposed to take charge
• Critical contact numbers weren't readily available
• Backups existed but hadn't been tested, or restoration took much longer than expected
• There was no clear communication process for notifying customers
• Security patches hadn't been applied to a vulnerable system
• A staff member clicked on a phishing link because they hadn't had recent security awareness training

Step 4: Identify the Root Cause

For each problem you identify, ask why it happened. Keep asking why until you reach the root cause rather than just the symptom. For example: "A staff member clicked a phishing link" is a symptom. The root cause might be "we haven't delivered phishing awareness training in two years" or "we don't have email filtering that flags suspicious messages."

Step 5: Define Action Items

For each root cause, define a specific action, assign it to a named person, and set a deadline. Vague commitments like "we need to improve our security" don't get done. Specific commitments like "Sarah will set up multi-factor authentication on all staff email accounts by Friday" do.

Documenting the Review

Write up a brief report that captures the timeline, key findings, and action items. This document serves several purposes: it holds people accountable for the agreed actions, it provides context if you face regulatory scrutiny, and it becomes part of your organisational memory so future team members can learn from what happened.

Keep the report factual and focused. It doesn't need to be lengthy — a structured document of one to two pages is usually sufficient for most small business incidents.

Following Up on Action Items

The review is only as valuable as the actions that come out of it. Set a follow-up meeting for four to six weeks after the review to check progress on action items. If items are consistently not getting done, that's a signal they may not be resourced properly — which is itself an important finding.

Key Takeaways

• Run a post-incident review within two weeks of every significant cyber incident — the goal is improvement, not blame
• Build a detailed timeline first, then identify what worked, what didn't, and the root causes of each problem
• Every action item should have a named owner and a specific deadline
• Write a brief summary report for accountability and organisational memory
• Follow up on action items four to six weeks later to make sure improvements are actually implemented

The best time to prepare for the next cyber incident is right after the last one. Use Flagged's free risk assessment to identify your current vulnerabilities and get a prioritised action plan before the next incident occurs.