The corrective action was logged as complete six weeks before the second incident. The same hazard. The same location. A different worker, a different shift, and almost the same outcome as the one that had prompted the investigation the first time around.
Every safety manager who has been in the profession long enough has a version of this story. The investigation was thorough, by any reasonable measure. Statements were taken, the five-whys was worked through, a corrective action was assigned and closed. And then the incident recurred, because the corrective action had not changed what people actually did.
This is the gap at the centre of most root cause analysis: the distance between what the paperwork says happened and what the cameras saw. Between the narrative reconstructed from memory and the sequence of events as it actually unfolded. Between "corrective action complete" and a verified change in behaviour on site.
Why the same incidents keep recurring
Incident investigation is limited by the quality of its inputs. Witness statements are constructed after the fact, shaped by stress, memory and, sometimes, a reasonable reluctance to say something that might be held against a colleague. Paper-based near-miss reports are filed — or not filed — based on whether the person involved thought it was worth the trouble. The physical evidence at the scene tells you something, but it rarely tells you what happened in the two minutes before the incident began.
The result is that most root cause analysis is, at its core, a reconstruction. An investigator assembles the most coherent account they can from incomplete and partly unreliable inputs. The five-whys leads to a root cause that is plausible, credible, and sometimes correct. And then a corrective action is designed to address that plausible root cause — which may or may not have been the real one.
Recurrence happens when the true root cause was not what the investigation concluded it was, or when the corrective action addressed the identified cause in theory but not in practice. The signage was improved. The training was refreshed. The crossing was repainted. And the behaviour that created the hazard — which neither the signage nor the training actually changed — continued exactly as before.
The five-whys problem
The five-whys is a good framework. The problem is that it is only as good as the evidence you feed into it.
Ask "why did the worker enter the restricted zone?" and the honest answer, based on the available evidence, might be "the signage was unclear" or "the worker was unfamiliar with the site layout." Both are plausible. Both can be corrected. But if the camera shows that the same zone boundary had been crossed fourteen times in the preceding week — by experienced workers who knew exactly where it was — then the real why is different. It is not signage. It is something structural about the flow of that area, the time pressure of the operation, or the fact that the authorised route adds two minutes to a task that every worker does twenty times a shift.
That distinction matters because the corrective actions are completely different. Correcting signage is cheap and fast and does nothing when signage was not the problem. Correcting the structural incentive that made the shortcut rational is harder, takes longer, and is the only thing that prevents recurrence.
The camera saw all fourteen crossings. The investigation, working from one incident and a handful of statements, saw one.
What objective evidence changes in RCA
A computer-vision layer on your existing CCTV does not replace investigation. It changes what investigators have to work with.
When a reportable incident occurs, the footage is no longer a passive record of the moment of harm. It is a searchable, timestamped log of everything that led up to it: the near-misses in the days before, the pattern of zone breaches, the PPE compliance rate in that area, the vehicle movements that created the congestion. The investigator does not have to reconstruct a sequence from memory. They can watch it.
This matters for the immediate investigation, but it matters more for the five-whys. When the question is "why did this happen?", a dataset of forty similar precursor events — each one logged automatically, with camera reference and clip — is a qualitatively different input from three witness statements and a site walk. The systemic cause, the one that explains why the same near-miss kept occurring before it finally resulted in harm, is visible in the data. The proximate cause — the immediate trigger of the specific incident — is often not the same thing.
SecureSafety was built in environments where this distinction is not academic. On offshore oil and gas rigs, an incident investigation that stops at the proximate cause and misses the systemic one will see the same event again, in a different watch rotation, with a different crew. The detection pedigree forged there — running at a sub-0.05% error rate across 18,000 events per day — produces the volume of precursor data that makes systemic root-cause analysis possible. On land, in a port, a warehouse or a construction site, the same logic applies.
From single incident to pattern
The value of continuous detection is not just in the incident record. It is in what the data shows about the distribution of unsafe events across the site, over time.
Plot every red-zone incursion over a month and the hotspots draw themselves. A particular aisle end, a shift-changeover window, a camera zone that accounts for a third of all proximity alerts. These patterns are the systemic root cause, made visible before they produce another incident. The five-whys applied to a pattern is a different and more powerful exercise than the five-whys applied to a single event.
This is how AI safety monitoring changes the economics of prevention: by turning the exception (one investigated incident) into a population (a full statistical picture of the precursor events that preceded it). The corrective action can then be targeted at the actual failure mode, not the most available narrative about it.
Closing the loop: verifying that the action worked
The last failure point in most RCA processes is verification. The corrective action is logged as complete when the task is closed — when the new barrier is installed, the training is delivered, the procedure is updated. Whether the barrier changed what actually happens at that location is rarely checked with any rigour.
A camera-based detection layer makes verification possible in a way that manual spot-checks cannot. If a zone incursion was the root cause and a physical barrier was the corrective action, the detection data after the barrier was installed either shows a reduction in incursions at that location or it does not. The corrective action either worked or it did not. That is a factual answer, not an assumption.
This closing of the loop — from incident to investigation to corrective action to verified outcome — is what ISO 45001's continuous improvement requirement actually demands. The standard expects organisations to evaluate the effectiveness of actions taken, not merely to record that actions were taken. Detection data is the mechanism that makes effectiveness measurable.
Recurrence, compliance and the audit trail
RIDDOR imposes a ten-day reporting clock from the point an injury crosses the reportable threshold. What it does not create is any obligation to demonstrate, to the HSE, that the conditions that produced the incident have been corrected. That obligation is imposed by the broader framework: the Health and Safety at Work Act, the Management of Health and Safety at Work Regulations, and, where an organisation has adopted it, ISO 45001.
What regulators and auditors consistently find, in prosecutions and enforcement investigations following serious incidents, is that evidence of an effective safety management system is a significant factor in the outcome. The organisation that can show not just that it investigated but that it measured the effectiveness of its response, with objective data, over time, is in a materially different position from the one whose corrective actions are a stack of closed tickets.
The timestamped, camera-referenced detection record that AI monitoring produces is that evidence. It does not create a better paper trail. It creates a factual record of site behaviour before and after every corrective action — the audit trail that a safety management system is supposed to generate and that manual processes, by their nature, cannot reliably produce.
The same incidents will recur without the right evidence
Investigation quality is a function of evidence quality. Near-miss data that is logged by an AI layer on existing cameras is not the same kind of data as near-miss data that relies on workers filing reports. The first is objective, continuous and complete. The second is intermittent, filtered through reporting culture, and missing most of the events that would have changed the conclusion.
The incidents that recur are the ones where the investigation worked from the second kind of data and drew the wrong conclusion, or the right conclusion and applied the wrong corrective action, or the right corrective action and never checked whether it held.
Every piece of evidence that changes the quality of the analysis changes the probability of recurrence. The footage is already running on your cameras. The question is whether anything is watching it closely enough to see the pattern before the next incident adds itself to the record.
Root cause analysis checklist: integrating AI monitoring data
Pre-investigation evidence preservation
When an incident occurs at a camera-monitored location, the first action in the investigation should be to preserve the AI monitoring event log. This includes: the near-miss event log for the relevant camera zone and time period; the alert log showing whether any alerts were generated before the incident and what the response was; and the compliance log for PPE and zone monitoring in the area. These records must be preserved before any system configuration changes are made that might affect the data.
Pattern analysis in the near-miss data
The AI monitoring event log for the incident location should be reviewed for the period preceding the incident — typically 30-90 days. The analysis should address: how many similar events occurred in this period; what was the time distribution (specific shifts, times of day); whether there were any alert responses to prior events; and whether corrective actions were taken following prior events. This analysis is the foundation of a root cause finding that goes beyond the immediate incident to the underlying pattern.
Systemic comparison across the site
After establishing the root cause at the incident location, the AI monitoring data for the entire site should be reviewed for similar patterns. If the root cause is a blind crossing with high vehicle-pedestrian conflict frequency, the monitoring data for all similar crossings on the site should be reviewed to identify whether the same precursor pattern is present elsewhere. Proactive corrective action at similar locations, informed by the incident investigation, is the systemic improvement that a mature safety management system requires.
- Preserve: event log, alert log and compliance log for the incident location and time period
- Analyse: near-miss frequency, time distribution and alert response history for 30-90 days before the incident
- Compare: identify similar patterns at other locations on the site
- Verify: measure the near-miss frequency at the corrected location after the corrective action is implemented
Book a demo and see what the cameras on your site have been capturing that no investigation has yet used.
