Post-Incident Review

Once an insider case concludes, the pressure to move on is considerable. The review gets deferred and then abandoned, which means the same gap produces the next incident.

What to examine

How was it detected? By a rule, by a colleague, by accident, by an external party? If it was not your detection, that is the most important finding in the review.

How long was it running? Time from first activity to detection. This is the number that matters most and the one people avoid calculating.

What did we not see? Which of the person's actions left no trace. Every case reveals blind spots, and this is the only reliable way to find them.

Did the process work? Authorisation, preservation, escalation, timelines. Where did it stall, and why.

Was the data actually sensitive? Sometimes the answer is no, and that is a classification finding.

What enabled it? Access that should not have existed, an export function that should have been restricted, a workflow that made the shortcut necessary.

Blameless, with a specific meaning

Blameless does not mean nobody is accountable — in an insider case, someone may well be dismissed.

It means the review of the organisation's response does not look for who to blame internally. If the analyst missed an alert, the question is why the queue was unreviewable. If the manager did not report a concern, the question is whether they knew how.

Where reviews assign blame internally, people stop volunteering the information that makes reviews useful.

Write it before the meeting

Circulate a document with the timeline and the findings. The meeting then addresses disagreement and actions rather than reconstructing events live, which wastes the time and produces worse recall.

The timeline is the core artefact. Build it from evidence, not memory.

Actions with owners and dates

A review producing a list of improvements without owners produces nothing, and everyone involved learns that the process is theatre.

Typical actions that emerge:

Access reduction for a category nobody had reviewed. A detection for the route that was used. An export restriction. A change to the departure process. Clarification of who authorises what.

Track them to completion, and report on the ones that were not done. Unfinished actions from previous reviews are themselves a finding.

Feeding it back

Into detection. The activity should be detectable next time. Write the rule, test it.

Into access. Most cases reveal access that was too broad.

Into awareness, if the case was negligence or a shortcut. An anonymised local example is the most effective awareness material available.

Into the departure process, if it was a leaver. It usually is.

The uncomfortable findings

We would not have caught it. Frequently true when detection came from outside. Say so.

We had the data and nobody looked. Extremely common — the evidence was in a log that was collected and unreviewed.

The control was disabled. An exclusion, a failed agent, a policy switched off during a project and never restored.

These are the findings worth having, and they only surface if the review is genuinely willing to record them.

Reviews for near misses

Run them for cases that turned out to be nothing.

A false positive that took four days to resolve is a process finding. An alert that fired correctly on activity nobody could interpret is an enrichment finding. These are cheaper lessons than real incidents and there are far more of them available.