Run a root cause analysis

SteadyOn doesn’t impose a particular investigation method. It holds the evidence, the reasoning and the follow-up — you choose how to get from one to the other.

This guide walks through a root cause analysis using 5 Whys, because it’s the method most small organisations can actually run without training. If your organisation uses fishbone, ICAM, or something else, the same SteadyOn fields work — only the shape of your notes changes.

Why bother

Most investigations answer what happened. A root cause analysis answers why the conditions allowed it to happen — which is the only answer that prevents a repeat.

The difference in practice:


Immediate cause	The worker slipped on spilled oil
Root cause	There’s no routine for checking the machine’s seal, and no one owns it

Fixing the immediate cause means mopping the floor. Fixing the root cause means the spill stops happening. Only one of those is worth your time twice.

Before you start

Gather what you have while it’s fresh — memories degrade within days, and scenes get cleaned up within hours.

Open the incident and set Status to Under investigation.
Set an Investigation due date so it doesn’t drift.
Assign Investigated by so it has an owner.

If the incident might be notifiable, deal with that first — the reporting clock runs independently of your investigation, and in some jurisdictions it’s measured in hours. See Report an incident.

Step 1 — Establish the facts

Use the incident’s Description and the Attachments tab. You are recording what is known, not what is suspected.

What happened, in sequence. A timeline beats a paragraph.
Where and when — the incident’s location and occurred-at fields.
Who was involved — record them in Injured parties on the Investigate tab, along with witnesses.
Evidence — photographs of the scene and the equipment, before anything is moved or cleaned. Also useful: training records, the relevant SDS, maintenance logs, rosters, shift notes.

Attach all of it to the incident. Evidence held in someone’s phone or inbox is evidence you will not have in six months.

Step 2 — Ask why, five times

Work in the Investigation notes field. Start from the immediate cause and keep asking why until you reach something your organisation controls.

The worker slipped and injured their back.
  Why? There was oil on the floor by the press.
    Why? The hydraulic seal has been weeping for weeks.
      Why? Nobody logged it — it was "just a bit of oil".
        Why? There's no routine inspection for the press.
          Why? Nobody owns preventive maintenance on this equipment.

The last line is a root cause: it’s a system failure, it’s inside your control, and fixing it prevents a whole class of incident rather than one.

Signs you’ve stopped too early:

The answer is “the worker wasn’t paying attention”. People make mistakes — that’s a constant, not a cause. Ask why the system allowed a moment’s inattention to cause an injury.
The answer blames an individual. Blame ends investigations; it doesn’t prevent recurrence.
You can’t act on the answer. “Bad luck” isn’t a root cause.

Signs you’ve gone too far: if the answer is now about company culture or the economy, back up one step to the last thing you can actually fix.

Most incidents have more than one root cause. Write all of them down.

Step 3 — Separate immediate from long-term

The Investigate tab keeps these apart deliberately, because they operate on different timescales and it’s easy to do only the first.

Immediate control measures — what you did straight away to make it safe. Cleaned the spill, isolated the press, sent someone home.
Long-term corrective actions — what stops it recurring. A maintenance schedule, a named owner, a revised procedure.

If your long-term section is empty, you have documented an incident, not investigated one.

Step 4 — Turn each root cause into an action

This is the step that decides whether the investigation was worth doing.

For every root cause, raise a corrective action from the incident’s Related tab, with:

A specific description — “Add fortnightly seal check to the press maintenance schedule”, not “improve maintenance”
A named owner — a person, not a department
A realistic due date
A priority matching the risk

SteadyOn then tracks them to closure and flags them when they run late. An action with no owner and no date is a wish.

Use the hierarchy of controls when choosing what to do — eliminate beats substitute beats engineering beats administrative beats PPE. A toolbox talk is the weakest option available; reach for it last, not first. See Hierarchy of controls.

Step 5 — Close the loop

Link the incident to its hazard. If a hazard already covers this, link them from the Related tab. If none exists, create one — you’ve just proved it’s real.
Reassess the hazard’s risk rating. An incident is evidence your previous assessment was optimistic.
Check the controls actually landed. Verify the action, don’t just mark it done.
Close the incident once the corrective actions are in place.

What SteadyOn doesn’t do

There is no built-in RCA template — no guided 5 Whys form, fishbone diagram, or ICAM worksheet. The investigation fields are free text by design, so the method stays yours.

If you want a repeatable structure, two practical options:

Keep a blank RCA worksheet in Documents and attach a completed copy to each incident.
Agree a house format for the Investigation notes field — a heading per why, or immediate / underlying / root — and use it every time.

A structured investigation template is on the roadmap. If it would make a difference to you, tell us.

Where to go next

Investigate an incident — the mechanics of the investigation workflow
Hierarchy of controls — choosing effective corrective actions
Corrective action workflow — how actions are tracked to closure