What this is
What is a critical control?
What is a critical control?
A critical control is a barrier that, on its own, prevents or mitigates a fatal or catastrophic event — remove it and the risk is no longer adequately controlled. It sits at the top of a bow tie, directly on the pathway between a hazard and the unwanted event, which is why ICMM's guidance treats it differently from ordinary process or administrative controls. Not every control on a task is critical; most aren't.
How is a critical control different from a critical control verification?
The register in this template is the master list — one entry per control, with an owner, a description and a stated verification frequency. Critical Control Verification is the separate, repeating record that proves the check actually happened on schedule. The register defines what should be checked and how often; verification is the evidence that it was.
Why does each control need its own verification frequency instead of one site-wide schedule?
Controls degrade at different rates and carry different consequences if they fail silently. A physical barrier inspected quarterly and a permit-to-work check done every shift cannot share a single audit cycle without one of them being under- or over-checked. ICMM's model ties the frequency to the individual control's performance requirement, not to a generic audit calendar.
Scope
When is a critical control register required?
This register is master data, not an event record. It exists once per workspace and gets updated, not re-created every time a control is reviewed — using it to log a single verification or risk assessment defeats the point of having it.
Use this template when
- A risk study (bow tie, HAZID or similar) has identified a genuine critical control against a fatal or catastrophic event
- A new critical control is added, an existing one retired, or its owner, frequency or performance requirement has changed
- You need one authoritative list of critical controls to drive the Critical Control Verification schedule
- An auditor or regulator asks which controls stand against your fatal risks and who owns each one
- A bowtie or barrier review has changed the hierarchy-of-controls level of an existing control
Do not use it for
- Critical Control Verification, which records that a scheduled check on a specific control happened, not the control's master definition.
- Bow Tie Analysis Record, which maps the full pathway from hazard to unwanted event and identifies which controls are critical in the first place.
- Barrier Health Review, which assesses the ongoing condition of a barrier, not whether it is defined and owned.
- Risk Assessment, which covers the wider population of hazards and controls, most of which aren't critical controls.
- Anything outside General, which belongs in the workspace that owns that process
Compliance mapping
Which ICMM Critical Control Management requirements does this satisfy?
ICMM's guidance is a practice framework, not a numbered standard, so the mapping below cites its core elements rather than clause numbers that don't exist. Each element has a direct home in the form.
| Clause | Requirement | Where it lands |
|---|---|---|
| ICMM CCM — material unwanted event | Name the fatal or catastrophic event the control stands against, not just the hazard | Identification |
| ICMM CCM — critical control identification | Distinguish a critical control from ordinary process, administrative and detection-only controls | Control detail |
| ICMM CCM — hierarchy of controls | Record where the control sits from elimination through to training, reflecting what is actually installed | Control detail |
| ICMM CCM — performance requirement | State what good looks like in terms a verifier can judge on site, not policy language | Control detail |
| ICMM CCM — verification | Set a verification method and frequency proportionate to how the control can fail | Verification |
| ICMM CCM — accountable ownership | Name a senior individual, not a role or department, against each control | Verification |
| ICMM CCM — traceability to source | Link the control back to the site, asset, task or bowtie that generated it | Context |
What it does not cover
- a Verification Frequency with no corresponding Last Verified date, which means the schedule exists on paper only and nobody can say when the control was last checked
- a Control Owner recorded as a department rather than a named person, which means accountability dissolves the moment something goes wrong
- a Control Level of 'Engineering' with a Performance Requirement written in policy language, which a verifier cannot judge against what they see in the field
- a Verifier Role of 'Supervisor' on a control whose performance requirement demands specialist knowledge, which produces a verification nobody competent actually performed
- an entry with no Source Bowtie and no Related Task, which leaves the control's origin unrecoverable the first time someone asks why it exists
Global
Critical Control Register requirements by country
ICMM's guidance began in mining, and it carries the most practical weight in jurisdictions with statutory principal-hazard or major-hazard regimes that critical control management was built to satisfy.
Mine Health and Safety Act 1996, s.11
A statutory duty to identify hazards and implement control measures, backed by inspectorate enforcement
A South African mine's register is effectively evidence for a legal duty, not just good practice — gaps are inspectable.
Model Work Health and Safety (Mines) Regulations — principal hazard management
Mining regulators expect a documented, owned set of controls against principal hazards, closely mirroring ICMM's language
Australian mine sites tend to run this register as a direct input to principal hazard management plans, so the two need to stay aligned rather than diverge.
ICMM Mining Principles — health and safety performance expectations
A membership commitment rather than law, but publicly reported against and subject to independent assurance
For members, a weak register is a reputational and assurance risk even where there's no equivalent statutory duty.
How to complete it
How to complete a critical control register, step by step
A fully filled register looks complete. Whether it's defensible turns on four judgement calls a form can't make automatically.
A hierarchy-of-controls rating is only honest if it describes the barrier as it exists today. If a risk assessment recommended an engineering control but budget only delivered an administrative one, the register has to say 'Administrative' until the capital work lands — recording the aspiration is the single commonest way this register becomes indefensible.
A 'Site visit' every shift is realistic for a control at the plant entrance and unrealistic for one on a remote asset three hours away. Where the two don't match reality, the frequency gets missed quietly, and the gap only surfaces when someone checks Last Verified against the calendar.
ICMM's model depends on a named senior person who can be asked, directly, why a control has drifted. An owner field populated with a job title or a shared inbox has no one to answer that question, and the register quietly becomes unowned the day that person moves on.
Reviewed yearly is the stated cadence, but a register only touched when a new bowtie is run will drift from what verification records actually show. The annual review needs to reconcile the register against the verification history, not just re-confirm the same entries.
What auditors find
Most common critical control register findings
Patterns that recur when this register is reviewed months after set-up.
| Finding | Clause | What fixes it |
|---|---|---|
| Control Level recorded as 'Engineering' or 'Eliminated' for a control that verification records show is being checked by observation only | ICMM CCM — hierarchy of controls | Re-grade the control to match what verification evidence demonstrates is installed, and flag the gap as an action rather than quietly correcting the record. |
| Verifier Role set to 'Supervisor' on controls whose Performance Requirement clearly needs a technical specialist to judge | ICMM CCM — accountable ownership | Match the Verifier Role to the competency the Performance Requirement demands, and re-issue past verifications for review if the mismatch is longstanding. |
| Verification Frequency set but Last Verified left blank for controls that have existed since the register was first built | ICMM CCM — verification | Treat a missing Last Verified date as an overdue verification, not an empty field, and schedule the first check immediately. |
| Control Owner populated with a team name or generic title instead of a named individual | ICMM CCM — accountable ownership | Reassign ownership to a specific senior manager and record their name, not their function. |
| Source Bowtie left blank on controls that clearly originated from a formal risk study | ICMM CCM — traceability to source | Backfill the link to the originating bowtie so the control's justification is recoverable without institutional memory. |
| Performance Requirement written as a policy statement rather than something a verifier can judge in the field | ICMM CCM — performance requirement | Rewrite the requirement as an observable, testable statement — what the verifier should see, measure or find when the control is working. |
Case in point
Case in point: the barrier that was engineering on paper
A processing site's register listed a gas detection interlock as an 'Engineering' control with quarterly verification. The interlock had failed eighteen months earlier and been replaced, informally, with a manual gas-check procedure while the capital request for a new interlock sat in a budget queue.
Nobody updated Control Level or Performance Requirement, because the quarterly verification kept being signed off against the old wording — a supervisor doing a manual check ticked the box for a test they'd never performed. The gap surfaced only when an incident investigation compared the register against maintenance work orders.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
4 sections
- Reference
- FDN-011
- Archetype
- Register
- Record ID
- CCTRL-2026-000
- Scoring
- None
- Direction
- n/a
- Singleton
- Yes
- Basis
- ICMM Critical Control Management
- Links
- Feeds Critical Control Verification
- Tags
- Master data, Critical risk
- Sections
- 4
- Fields
- 21
- Follow up fields
- 0
- Repeating sections
- 0
- Links out
- 4
Identification
4 fieldsControl ID*
Format CCTRL-000.
The record's own ID. Other templates point at this value.
Status*
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Control Name*
This is what Pick Lists display.
Material Unwanted Event*
The fatal or catastrophic event this control stands against.
Control detail
4 fieldsControl Type*
Preventive controls stop the event. Mitigating controls reduce its consequences.
Control Level*
Where this sits in the hierarchy of controls.
- Eliminated4 pts
- Engineering3 pts
- Aid provided3 pts
- Administrative1 pt
- Training only0 pts
Control Description*
What the control physically is and how it works.
Performance Requirement*
What good looks like, stated so a verifier can judge it in the field.
Verification
6 fieldsVerification Frequency*
How often this control is physically checked.
Verification Method*
Observation, test, measurement or record review.
- Site visit4 pts
- Record review3 pts
- Photograph2 pts
- Statement only0 pts
Control Owner*
A named senior manager, not a department.
Owner Person ID*
Links to FDN-003 Person ID
Verifier Role*
Who is competent to verify this control.
Last Verified
Context
7 fieldsApplies To Site*
Site ID*
Links to FDN-001 Site ID
Related Asset
Asset ID
Links to FDN-002 Asset ID
Related Task
Job ID
Links to FDN-004 Job Task ID
Source Bowtie
The bowtie analysis this control came from.
FDN-011 · record IDs look like CCTRL-2026-000 · Feeds Critical Control Verification
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The form is the easy part. Keeping it current, routing it to the right owner and holding the evidence together is the work that actually slips.
Holds the register against the bowties and risk assessments it came from, flags entries where Control Level and verification evidence have drifted apart, and keeps it aligned to Critical Control Verification.
Ties engineering-level controls back to the asset and maintenance records that keep them real, so a control graded 'Engineering' has the work orders to back it up.
Rolls the register's verification status into audit and regulator-facing reporting, so gaps surface before an inspector finds them.
Coordinates the crew, rolls completion and exceptions into one view, and holds every write for your approval before it touches a record.
This template lives in General — control tower. The orchestration layer. Registries and engines every other workspace reads from.
Meet General→Glossary
Critical Control Register definitions and key terms
- Critical control
- A barrier that, on its own, prevents or mitigates a fatal or catastrophic event. Losing it materially increases the risk of that event, which is why it's tracked apart from the wider population of controls.
- Bow tie
- A diagram that maps threats on one side and consequences on the other, joined through a central unwanted event, with controls (barriers) placed along each pathway. Critical controls sit closest to the centre.
- Hierarchy of controls
- The ranked order of control types by reliability — elimination and engineering controls at the top, administrative controls and training at the bottom — used to grade how much a control can be trusted.
- Material unwanted event
- The specific fatal or catastrophic outcome a critical control exists to prevent — a fall from height, a vehicle-pedestrian collision, an uncontrolled release — named precisely enough that a verifier knows what failure looks like.
- Verification
- Confirming, on the stated frequency, that a control is present and performing as specified. Distinct from validation, which asks whether the control was ever an adequate design response to the risk in the first place.
FAQ
Frequently asked questions about critical control register
Who should own an entry in the critical control register?+
A named senior manager accountable for the control's performance, not a department or a job title. ICMM's model depends on there being one person who can be asked directly why a control has drifted.
How often should a critical control register be reviewed?+
The register itself is typically reviewed yearly, alongside the risk studies that feed it, but individual controls are verified on whatever frequency their performance requirement demands — some every shift, some quarterly.
Does every safety control belong in this register?+
No. Only controls meeting the critical-control definition — losing them materially increases the risk of a fatal or catastrophic event — belong here. Routine process and administrative controls sit in the wider risk assessment, not this register.
What happens if a control's Control Level doesn't match what verification evidence shows?+
Treat it as a finding, not a data-entry correction. A mismatch between the recorded hierarchy level and what's physically verified in the field usually means the control has degraded or was never installed as designed.
Why does this register feed Critical Control Verification rather than contain the checks itself?+
Separating the master definition from the repeating check keeps the register stable — one entry per control — while verification accumulates a full history against it over time.
Is ICMM's critical control management framework only relevant to mining?+
It originated there, but the underlying discipline — naming the few controls against fatal risk and proving they work — has been adopted well beyond mining, in any high-hazard operation with a small number of catastrophic failure modes.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Used together in Critical Control and Fatal Risk
Bow Tie Analysis Record
Maps threats, the top event, consequences and the barriers on each side for a major hazard
Barrier Health Review
Reviews whether the barriers relied on in a bow tie are actually in place and working
Risk Assessment
The single risk assessment used across the whole business
Serious Potential Incident Report
Used when an event could have killed or seriously injured someone, whatever the actual outcome
Job Safety Analysis
Breaks a job into steps, finds the hazards in each and sets the controls
Pre-Task Risk Assessment
A short check done by the crew right before work starts, covering what has changed today
More in Registries
Site and Location Register
Holds every site, building, area and zone your organisation operates
Asset Register
Holds every piece of equipment, machine, vehicle and tool you track
Worker Profile
Holds a record for each worker, including role, department, site and start date
Job and Task Register
Lists the jobs and tasks people perform, so risk assessments and ergonomic assessments can be tied to real work rather than job titles
Vendor and Contractor Register
Holds every supplier, contractor and service provider you work with, including their status and approval level
Chemical and Substance Register
Lists every chemical and hazardous substance held on site, with quantity, location and hazard class
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- ICMM — Critical Control Management: A Guide to Implementation
- ISO 45001:2018, cl.8.1.2 — hierarchy of controls
- Mine Health and Safety Act 1996 (South Africa), s.11
- ISO 45001:2018, cl.9.1 — monitoring, measurement, analysis and evaluation
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.