Post-incident review: how to turn security incidents into actions and lessons learned
An incident can be investigated properly, documented thoroughly and discussed at a review meeting, yet still change very little. Recommendations are recorded, actions are added to a tracker and the incident is eventually closed, but months later it may be difficult to establish what was actually decided, whether the action happened, whether it made any difference or whether the same weakness has appeared again.
Post-Incident Review Template
A structured Word template covering evidence, findings, decisions, actions, outcomes and retained learning.
Post-Incident Action & Lessons Tracker
An Excel tracker for action ownership, completion evidence, effectiveness checks and retained learning.
That is the gap a good post-incident review should close. Its purpose is not simply to look back at what happened. It is to decide, on the available evidence, whether anything needs to change and then make sure the decision leads somewhere.
A completed review is therefore not necessarily the same thing as a lesson learned.
What is a post-incident review?
For the purposes of this guide, a post-incident review is a structured examination of an incident after the immediate response has finished and enough information is available to consider what it means for future operations.
If the immediate task is to create the underlying incident record, see our security incident report template and worked example.
In this guide, we distinguish the post-incident review from the incident report and any investigation that may be required. The incident report establishes the record of what happened, what evidence exists, what actions were taken at the time and what remains uncertain. An investigation, where one is required, goes further into causes and contributing circumstances. The post-incident review asks what the organisation should do with those findings.
That might lead to a change in a procedure, a briefing, a physical security measure, contractor instructions or the way a particular risk is reviewed. It might also lead to a decision that no further change is justified.
That last outcome matters. A review should not begin from the assumption that every incident requires another control. If a controlled door operated exactly as designed but somebody followed an authorised employee through it, replacing the access-control reader may achieve nothing. The more useful questions may concern staff behaviour, contractor instructions or whether the organisation was relying on a control that had gradually weakened in practice.
This distinction is consistent with NPSA guidance, which recommends a post-incident debrief to review the response, identify areas for improvement and consider whether security measures need to change.
Start from the evidence, but do not turn uncertainty into certainty
The post-incident review should start from the evidence already established through the incident report or investigation. It should not rebuild the whole incident record unless something material is missing.
The important discipline is to preserve uncertainty where it exists. If CCTV shows a contractor following an employee through a controlled entrance and the access-control record shows only the employee’s credential being used, those are supported findings. It may also be possible that the employee deliberately allowed the contractor to follow them, but unless the evidence establishes that point, the review should not quietly convert it into a fact.
The same applies to accounts given by people involved. A contractor may say they believed they were allowed to use a staff entrance. That is relevant evidence about their understanding. It does not, by itself, establish whether the joining instructions were clear. The reviewer still needs to look at the instructions.
Preserving uncertainty matters because the next decision may involve training, disciplinary action, a procedure change or expenditure on physical security. A neat explanation is not necessarily a reliable one.
Look beyond what went wrong
A useful review should examine more than failure. Something may have worked exactly as intended and still deserve attention, while an incident does not necessarily mean that every control involved was defective.
Consider a fictional example. A contractor follows an employee through a controlled office entrance without using an access credential. The obvious conclusion might be that the access-control system failed. But suppose the records show that the employee presented a valid card, the reader released the door and the door subsequently closed normally. Technically, the system did what it was designed to do.
The review therefore needs to look at the controls around the event. Was the organisation relying partly on employees to prevent other people following them through the door? Was that expectation clear? Did the contractor know that they had to report to reception before entering? Had similar events happened before, even if they were dealt with informally?
The review should also look at what worked. In this example, a security officer later noticed the contractor in an internal corridor, challenged them and established that they were legitimately working in the building but had bypassed the reception process. The challenge limited the period in which the contractor remained inside without having completed the expected reception process.
This is why post-incident review is more useful when it looks at the way the whole operating arrangement behaved, rather than simply searching for a single cause.
A recommendation is not yet an action
Post-incident reviews often become weak at the point where findings turn into recommendations.
Suppose the review finds that the contractor entered through a staff entrance and that the existing contractor instruction says only that contractors should “report on arrival”. A recommendation to “review contractor procedures” sounds reasonable, but it leaves most of the important questions unresolved.
A stronger review separates the recommendation from the decision and the action.
The recommendation might be to clarify the contractor arrival process. The accountable manager may then decide that contractors must continue to report to reception before entering controlled areas and that the joining instruction should be amended to make this explicit. The resulting action is specific: the Facilities Manager will issue the revised instruction by an agreed date.
That distinction matters because a recommendation is a proposal, not an automatic instruction. A review may reasonably conclude that the existing control remains appropriate, that a suggested change would create a greater problem elsewhere or that more evidence is needed before deciding.
Human judgement sits between the finding and the action.
Give accepted actions an owner and something that proves completion
A named owner and due date are useful, but they are not enough on their own. The review should also record what evidence will show that the action has actually been completed.
For a revised contractor instruction, that might be the approved new document and evidence that it has entered use. For a physical security change it could include installation and commissioning records. For a briefing, it could be the issued material and attendance record.
This prevents an action from being closed simply because somebody says it has been done.
For more significant findings, the review should go one stage further and decide how effectiveness will be checked. A security briefing can be delivered on time and evidenced as complete, but that does not establish that behaviour has changed. The organisation might therefore review related incidents after three months, conduct an assurance check or test the revised process during an exercise.
Completion evidence and effectiveness evidence answer different questions. One shows that the agreed work was carried out. The other helps establish whether the change achieved what was intended.
HSE’s HSG245 health and safety investigation guidance includes implementation of the action plan as a distinct stage of the investigation process. Although it is health and safety guidance rather than a prescribed security-review method, the action-management discipline is relevant here. UK Resilience Academy guidance makes a further distinction between a lesson being identified, implemented and eventually embedded in practice.
A lesson identified is not necessarily a lesson learned
“Lessons learned” is one of those phrases that can make a process sound more complete than it really is. A review identifies that something needs to change, a recommendation is agreed and the action eventually appears as complete in a tracker. But that does not necessarily mean the organisation has learned the lesson.
Return to the controlled-entry example. The security manager briefs staff about tailgating and the facilities manager clarifies the contractor arrival instructions. Both actions can be evidenced as complete.
Three months later, another person attempts to follow an employee through the same entrance. This time the employee challenges them and directs them to reception. That does not prove that tailgating has been eliminated, and it cannot establish how many unreported incidents may have occurred. It does, however, provide some evidence that the expected behaviour was understood and applied in a later situation.
The review can now record more than the fact that the briefing happened. It can record the observed outcome and the remaining uncertainty.
The lesson retained by the organisation should also be specific enough to be useful later. “Staff should remain vigilant” tells a future reviewer very little. A more useful lesson would be that where a controlled entrance relies partly on authorised users preventing tailgating, the access technology needs to be considered alongside staff expectations, contractor arrival instructions and challenge arrangements.
Six months later, facilities may propose a new contractor entrance at another site. The value of retained learning is not simply that somebody can find the old incident report if they know to look for it. It is that the relevant lesson can inform the new decision.
The aim is to move from understanding the incident to deciding what should change, making that change, checking the result and retaining anything that should influence future work.
UK Resilience Academy guidance makes a useful distinction between a lesson being identified, implemented and eventually embedded in practice. The guidance is non-statutory and non-mandatory, but its approach to managing learning is relevant well beyond the civil contingencies context.
Not every incident needs the same level of review
A formal lessons-management process would be disproportionate for many minor incidents. The amount of follow-up should reflect the seriousness of the event, the significance of any control weakness, the uncertainty around what happened and the likelihood that the same issue could recur elsewhere.
A straightforward incident with an obvious cause and a simple corrective action may only need a short review, a named owner and evidence that the action was completed. More substantial follow-up becomes more useful where the incident exposed a significant weakness, the same event has happened before, several teams or suppliers were involved, an existing procedure was followed but still failed to control the risk, or the proposed change is substantial enough that its effectiveness should be checked.
The process can become counterproductive if every minor event creates a large administrative burden. The opposite problem is closing a serious finding after recording a vague recommendation and creating the appearance that the issue has been dealt with.
The level of review should match the decision that needs to be made and the consequence of getting that decision wrong.
What to record in a post-incident review
A practical review does not need to become another lengthy report. The accompanying SIRV template is designed to capture the information needed to move from the incident record to a decision and then into follow-up.
It records the incident and review details, the material evidence considered, any important uncertainty, the findings, what worked, what needs attention and whether the same condition could exist elsewhere. Recommendations are recorded separately from the decision taken so that proposals do not automatically become approved actions.
Accepted actions then move into the accompanying tracker, which records the owner, due date and the evidence required to demonstrate completion. Where the issue warrants it, the tracker also records how effectiveness will be checked and what outcome was observed.
The final part of the review asks what should actually be retained from the incident and where that learning may be relevant in future. That might include procedures, contractor controls, future risk assessments, security design, similar sites, exercises or subsequent reviews.
Post-Incident Review Template
A structured Word template covering evidence, findings, decisions, actions, outcomes and retained learning.
Post-Incident Action & Lessons Tracker
An Excel tracker for action ownership, completion evidence, effectiveness checks and retained learning.
Where AI can assist
In many organisations, procedures, incident reports and lessons learned already exist in SharePoint or other document libraries. The information is there, but it is largely static. Someone has to know that a relevant lesson exists, find the right file and work out whether it applies to the issue in front of them.
Where AI has controlled access to existing procedures, incident reports and lessons learned, it can reduce that friction. A reviewer can ask for previous incidents with similar characteristics, find earlier decisions or unresolved actions, and bring relevant approved learning into the current review without manually searching through folders and documents. This does not create new organisational knowledge, but it can make existing knowledge much easier to use.
That matters because retained learning has little operational value if it can only be found by someone who already knows where to look. Making approved lessons easier to retrieve when a similar issue arises increases the likelihood that they are considered in the next relevant decision rather than remaining buried in an old file.
The boundary is still important. AI can surface evidence, identify relevant material and show where information came from, but it should not decide whether a control was adequate, whether a recommendation should be accepted, whether a risk is tolerable or whether an action has proved effective in practice. Those decisions remain with the appropriate person.
In the controlled-entry example, the useful outcome is not an AI-generated summary of an old incident months later. It is that the approved learning about contractor access and tailgating can be brought into view when a new contractor entrance is being reviewed, together with the evidence and decision that originally supported it.
Closing the review
A post-incident review should do more than produce a record of what was discussed after an event. Its value lies in what happens afterwards: whether findings are supported by evidence, whether decisions become specific actions, whether completion is checked and whether useful learning is carried forward.
The process does not need to be elaborate. For a straightforward incident, a short review and a small number of clearly owned actions may be enough. Where the issue is more significant, recurring or uncertain, the organisation may need to go further and check whether the action achieved what was intended.
A useful test is whether, if the same issue appeared again six months later, the organisation could establish what it learned last time, what it decided to do and whether that decision made any difference.
That is a stronger standard than simply marking the review complete.
"SIRV helped us move beyond basic reporting into a system that actively supports decision-making". Les O'Gorman, Director of Facilities, UCB - Pharma and Life Sciences
