Process guide

From incident to a changed risk assessment: 5 Why, CAPA and closing the loop

The full path after an event is an ordered sequence of four steps: recording the facts, establishing the root cause, implementing corrective and preventive actions, and updating the occupational risk assessment for the workplace involved. Only the last step closes the loop — without it the organisation has described an incident but has not changed the conditions that made it possible.

Most plants record events correctly and analyse them reasonably well. The problem comes later: the analysis ends in a report, the action ends in an email, and the risk assessment stays exactly as it was before the event.

Incident investigation
Root cause
CAPA
Risk assessment

Published: 2026-01-12 · Updated: 2026-02-04 · 9 min · Varilo deployment team

Incident – 5 Why analysis – CAPA – risk assessment path in the V-IMS system

Step 1. Recording: facts, not interpretations

The first minutes after an event decide the quality of the whole analysis. The record should contain what can be verified: date and time, location down to the workstation, people present, the task being performed, the state of the machine and its guards, ambient conditions, and photographs taken before the area is cleaned up. Anything starting with “probably” or “it seems” belongs in the later analysis, not in the report.

The most common loss at this stage is the photograph nobody took, because the phone stayed in the locker and the paper form was filled in two hours later at a desk. That is why reports should be captured where the event happened — from a phone, with a photo and a location.

It also pays to classify immediately: injury accident, event without injury, near miss, breakdown or property damage. That single decision drives the procedure, the deadlines and the document set, so it is better settled at the start than changed halfway through.

Step 2. A 5 Why analysis that does not hunt for a culprit

The analysis starts with one sentence describing the event in terms of its outcome: “the operator injured a hand while clearing a jam in the conveyor”. You ask the first “why” of that sentence and another “why” of each answer, until the answer concerns an organisational decision rather than an individual's behaviour.

The quality test is simple: if the final answer is “the worker was not careful”, the analysis is not finished. The next questions must address why clearing the jam without stopping the machine was possible at all, why the practice survived the inspection rounds, why the instruction did not cover the situation, and why the guard allowed access.

For events with more serious potential, 5 Why alone is rarely enough. An Ishikawa diagram helps to structure the areas (people, machine, method, material, environment, measurement), and only selected branches are then expanded with 5 Why. The output should be two to four root causes, not one convenient one.

Step 3. CAPA: choosing actions by the hierarchy of control

Actions are chosen for each identified root cause, not the other way round. The choice should start at the top of the hierarchy of control: eliminate the hazard, substitute it, engineer it out, apply organisational measures, and only then personal protective equipment and training. If the whole action list after an event consists of training and a procedure reminder, the analysis stopped at behaviour.

Every action needs an owner, a due date and a way of confirming completion. The owner cannot be a department — it must be a named person, because a task assigned to “maintenance” has nobody to answer the reminder.

Plan the effectiveness review separately, usually one to three months after implementation. The question is not “did we do it” but “is the mechanism that caused the event still possible”. If it is, the action was insufficient and goes back into the register.

Step 4. Updating the risk assessment and closing the loop

An event is empirical proof that the existing risk assessment underestimated the hazard or missed it entirely. Once actions are closed, return to the workplace risk assessment and check three things: whether the hazard was listed, whether the risk level matched reality, and whether the stated controls are the ones that actually work.

The update should leave a trace — who changed it, when, and on the basis of which event. This is exactly the material an auditor asks for and the board expects after a second similar report.

Closing the loop also means going back to the reporter and the team. Telling someone “your report led to a new guard and a changed instruction” does more for future reporting rates than any poster campaign.

Traps that spoil the whole process

The first is an analysis carried out by one person at a desk. Without the operator and maintenance in the room you get a coherent story that does not match how the work is really done.

The second is confusing outcome with cause: “the cause was a hand injury” records an outcome. The third is actions without due dates, which sit open in the register for quarters. The fourth, and the costliest, is the missing effectiveness review — when the same event repeats, the organisation has nothing to show that it responded properly.

Checklist before closing an event

The report contains facts, photos and a classification set at the start.
The operator and a maintenance representative took part in the analysis.
The final “why” addresses the work system, not a person's behaviour.
Every root cause has at least one action assigned to it.
Actions are not limited to training and a procedure reminder.
Every action has a named owner and a due date.
An effectiveness review is scheduled with a specific date.
The workplace risk assessment has been reviewed and changed where needed.
The reporter received feedback on what their report achieved.

Related modules

VIMS module

Accidents and incidents — the full investigation workflow without spreadsheets

Report an event in seconds, run the root cause analysis, plan actions and close the case with complete documentation in one place.

Root cause analysis

Root cause analysis — from the symptom of an event to what actually caused it

Repeating events usually mean the previous investigation stopped at human error. This module walks the team through structured RCA techniques and makes sure every finding becomes a concrete action.

VIMS module

CAPA — corrective and preventive actions with real accountability

No more action lists in a spreadsheet. Every action has an owner, a deadline, a status and an effectiveness check — all in one view.

Frequently asked questions

Does every event need a full 5 Why analysis?

No. The depth of analysis should follow the potential outcome, not the actual one. A minor event that could have caused a serious injury under slightly different circumstances deserves a full analysis. A routine housekeeping report can be closed with a remedial action.

How many root causes should an analysis identify?

Usually two to four. A single cause for a serious event almost always means the analysis stopped too early, while a dozen means root causes have been mixed up with contributing factors.

When should the effectiveness review be scheduled?

For engineering changes usually after a month; for organisational and instruction changes after two to three months, once every shift crew has worked under the new arrangement. The date is set when the action is closed, not later.

What if the event repeats despite the actions taken?

A repeat tells you the root cause was identified incorrectly or the action sat too low in the hierarchy of control. Reopen the analysis, starting from the question of why the implemented safeguard failed.

Walk this path in a live system

We will show how one report from the shop floor leads to an analysis, CAPA tasks and a change in the risk assessment — without retyping data between files.

Book a demo Knowledge base