A HIRARC that passes every audit is not the same thing as a HIRARC that accurately describes the hazards on the floor. Those two outcomes usually move together — until a review procedure exists that can satisfy the first without ever testing the second. That gap sits inside the procedure itself, not inside any individual reviewer’s diligence.
Three Years, One Document
At a food processing plant in Malaysia, a HIRARC came up for its annual review — a requirement written into the client’s supplier audit checklist rather than an internally driven risk management decision. The reviewer opened the previous year’s file, checked that the risk ratings still looked reasonable on paper, updated the date field, and resubmitted it. The same process repeated for three consecutive years, and the audit accepted it each time, because the audit’s own check was limited to confirming that a review had taken place within the required interval — not to verifying what, if anything, had changed on the floor since the previous review.
Over that period, the line in question added a second shift, installed a new packaging machine with a different guarding profile from the one the original HIRARC described, and changed suppliers for a cleaning chemical in a way that altered how it was diluted and handled on site. None of these changes made it into the HIRARC, because the review procedure that governed it only ever specified a calendar-based trigger — once a year — and never specified a trigger tied to an actual process, equipment, or material change.
Procedures BRF: The Fault Lives in the Review Design
Within Tripod Beta’s framework of Basic Risk Factors, this pattern is a Procedures BRF — a systemic gap in how a written procedure is designed, rather than an error made by the person following it. The reviewer in this case did exactly what the procedure asked: confirm the ratings still looked reasonable, update the date, resubmit within the required window. The procedure itself never asked the reviewer to check for process drift, so nothing in the reviewer’s compliant execution of the procedure was ever going to surface it.
This distinction matters for how a corrective action gets scoped. Retraining a reviewer to be more thorough does nothing if the procedure they’re following never directs their attention toward what actually needs checking. The fix belongs in the procedure’s trigger design, not in the reviewer’s competency file.
Why an Audit-Only Trigger Creates a Blind Spot
A HIRARC review procedure built around a calendar trigger is efficient to administer and easy to demonstrate compliance against — it produces a clean, verifiable record that a review occurred on schedule. What it does not do is connect the review to the actual rate of change on the floor. A line that adds a shift, changes equipment, or substitutes a material mid-cycle carries a HIRARC that stopped being an accurate description of its hazards from the moment that change took effect — not from the moment the next scheduled review happens to fall due.
What DOSH Expects From a Risk Assessment That Stays Current
DOSH’s guidance on risk assessment under Malaysia’s occupational safety and health framework treats a HIRARC as a living document that should reflect current operating conditions, not a periodic compliance artefact. A HIRARC that technically satisfies its review schedule while describing a process that no longer exists carries a real exposure: if an incident occurs on a hazard the document never captured, the paper trail shows a documented review history sitting alongside a risk assessment that had stopped being accurate — a harder position to defend than having no review history at all.
Building a Trigger-Based Review Instead of a Calendar-Based One
A HIRARC treated as an operational tool rather than an audit artefact gets reopened at the moment something changes — a new machine, a shift pattern change, a supplier substitution, a modified procedure — rather than waiting for the next scheduled date. Building that trigger into a facility’s Management of Change process, so that any process, equipment, or material change automatically flags the relevant HIRARC sections for review, closes the exact gap that a purely calendar-based procedure leaves open. This is cheaper to build into the review procedure upfront than to discover the gap after an incident tests a control that quietly stopped being valid.
The Question Worth Asking Your Own HIRARC
For any HIRARC currently on file, it’s worth asking when it last changed because the underlying process changed — not because the scheduled review date arrived. If every change in the answer traces back to a calendar entry rather than an actual shift on the floor, the document may be passing every audit while describing a version of the operation that no longer exists.
A Simple Starting Check
For any HSE team wanting to test whether this gap exists in their own facility, one starting exercise is worth running before the next scheduled review: list every process, equipment, or supplier change on a given line over the past two years, then check each one against the current HIRARC. Any change that isn’t reflected in the document is a gap the calendar-based review cycle didn’t catch — and a concrete demonstration of why a trigger-based review procedure, not a more diligent reviewer, is the fix that closes it.
Build HIRARC review processes that catch drift before it costs a stoppage. Cikgu Barrier’s Risk Assessment That Works (HIRARC) program teaches Malaysian HSE teams to design risk assessments — and review procedures — that reflect the actual workplace, not just a form that satisfies an auditor. Register your interest in upcoming public and in-house dates — no cost, no commitment.