How to Choose Risk Management Software for Mining and Heavy Industry

Most risk management software was built for financial services, enterprise compliance, or healthcare governance. It reached mining and construction through repositioning — updated marketing, adjusted screenshots, the same underlying data model. The core capability — risk registers with heat maps — remained unchanged.

The problem is that a heat map risk register does not tell you whether the controls preventing a fatality are functioning. It records that controls exist. It does not verify them. It does not connect them to incidents. It does not surface degradation before something fails.

Selecting software for a high-hazard operation requires a different evaluation framework than selecting a general GRC platform. This guide covers what to look for, what to test, and what to treat as disqualifying.

What Generic Risk Software Gets Wrong

Generic risk platforms are built around a straightforward model: identify a risk, score it, record a control, assign a treatment action. For enterprise compliance or financial risk, this is often sufficient.

For operational risk in mining or construction, the model breaks at several points.

Controls are recorded as free text. There is no structured link between a control in the register and the physical system or procedure it refers to. A free-text control cannot be verified. Its degradation cannot be detected. It exists in the register, and nowhere else.

Incidents are handled in a separate module. Investigation findings do not flow back to the risk register. Corrective actions from investigations are not tracked against the controls they address. Each module holds its data. Nothing connects.

Critical controls receive no special treatment. A critical control — one whose failure creates a direct path to a fatality — sits in the same list as a document filing requirement. There is no differentiation in the data model, no verification schedule, no monitoring of health over time.

These are not gaps that configuration will fix. They reflect the original design intent of the platform.

What Native Bowtie Capability Looks Like

Bowtie analysis is the primary risk visualisation method in Australian mining, oil and gas, and heavy industry. Most enterprise risk platforms now claim to support it. The claims require close examination.

Cosmetic bowtie support means the platform can display a bowtie diagram, usually by importing one from a dedicated tool. The diagram is static. It does not connect to the risk register or to control records. Updating a control in the register does not update the bowtie. Logging an incident does not mark a barrier as failed.

Native bowtie capability means the bowtie is part of the risk data model. Barriers on the bowtie correspond to control records in the register. When a control degrades or fails, the bowtie reflects that automatically. When an incident is investigated, failed defences are linked to specific barriers, and those barriers update in the register.

To test this: ask the vendor to show what happens to a bowtie when a critical control is marked as failed. Ask them to trace a path from a specific barrier on the bowtie to its verification records. If either demonstration requires navigating to a different system or a separate module, the bowtie is not native — it is decorative.

What ISO 31000 Alignment Actually Requires

ISO 31000 is a principles-based framework, not a prescriptive standard. Vendors apply “ISO 31000 aligned” to a wide range of products, from comprehensive operational risk platforms to basic spreadsheet-replacement tools.

In practice, an ISO 31000-aligned risk register should:

Record each risk with context, likelihood, consequence, and existing controls
Distinguish between inherent risk (before controls) and residual risk (after controls)
Link controls to risks as structured records, not free-text descriptions
Capture treatment actions against each risk and track their status
Support periodic review with evidence of review recorded in the system
Produce audit-ready reports that show the complete risk record

During a product demonstration, request a view of 20 or more populated risks. Look specifically at whether controls are linked records or text fields. Look at whether the system captures inherent versus residual ratings separately. Look at whether treatment actions connect back to the risk or sit in a standalone task list.

If controls are text fields, the platform cannot verify them. If treatment actions sit in a separate task list with no link to the risk, the system cannot demonstrate control effectiveness over time.

What Genuine ICAM Support Requires

The Incident Cause Analysis Method (ICAM) is the standard investigation methodology across Australian mining and heavy industry. Regulatory expectations in Queensland, New South Wales, and Western Australia effectively require ICAM or a comparable structured method for serious incidents.

ICAM support in software ranges from a form with ICAM headings to a structured workflow that connects findings to the risk register.

A genuine ICAM workflow guides investigators through four layers of causation in sequence:

Absent or failed defences
Individual and team actions
Task and environmental conditions
Organisational factors

At each layer, investigators must be able to attach evidence, link findings to specific barriers or controls, and generate corrective actions assigned to those controls. The investigation output should connect directly to the bowtie — marking which barriers failed, which held, and which were absent.

The test: ask the vendor to demonstrate an investigation on a sample incident. Follow a specific failed defence from the investigation through to the barrier it corresponds to on a bowtie diagram. If that connection does not exist in the system, the platform is an incident log with ICAM headings — not an investigation tool.

For a detailed comparison of investigation methods, see Incident Investigation Methods: ICAM, 5 Whys, and Root Cause Analysis.

What Critical Control Management Needs From Software

Critical control management (CCM) requires more than identifying critical controls. It requires verifying them at defined intervals, monitoring the verification record across the operation, and responding when a control degrades.

Software that genuinely supports CCM must:

Allow controls to be designated as critical within the risk or bowtie model
Support verification schedules with defined frequency, responsible person, and required evidence
Enable field verification on mobile devices, with offline capability and photo evidence
Surface overdue verifications and escalate them automatically
Report control health — the proportion of critical controls meeting their performance standards — at site and portfolio level
Connect verification failures to an alert and investigation workflow

An inspection or checklist module positioned as critical control verification is not equivalent. The critical test: do the checklists link to specific controls in the risk register? Do overdue verifications appear on the risk dashboard? If checklist data exists only in an inspection record, it is not connected to the risk model.

A critical control whose verification record lives in a disconnected inspection system is, in practice, unmonitored.

What to Ask Before You Sign a Contract

The following questions distinguish a platform built for operational risk from one repositioned for it. Request a live demonstration of each answer — not a slide:

Does a control marked as failed in the field update the bowtie and risk register automatically?
Can an investigation finding link directly to a specific barrier on a bowtie diagram?
Are corrective actions from investigations assigned to the control they address, or do they sit in a separate task list?
Does the ICAM investigation workflow connect failed defences to control records in the register?
Can critical controls be verified in the field on a mobile device, offline, with photo evidence?
Where is data hosted, and is Australian data residency available?
What is the pricing model — per seat, per site, or flat fee?
What does implementation require, and what is the realistic time to a live, populated risk register?

No vendor will answer these questions against their product in a way that is unfavourable to them. Test each claim in a trial environment before committing.

What Red Flags Reveal in an EHS Tool Sold as Risk Software

EHS (environmental, health, and safety) platforms serve a different function from operational risk management platforms. EHS platforms are designed for inspection management, compliance tracking, and incident logging. Many are well-built for those purposes. They are not built for managing operational risk at the barrier and control level.

The signs that an EHS tool is being sold outside its design intent:

Bowtie diagrams are available only as imported images or via a partner integration
Risk registers are standalone records with no links to controls, barriers, or incidents
Incident investigations are limited to short forms with no bowtie linkage
Critical control management is offered as an add-on module with separate data
Per-user pricing that increases sharply as field adoption grows

None of these are deficiencies for an EHS use case. They become deficiencies when the procurement objective is managing operational risk in a high-hazard environment — where the connection between the risk model, the control record, and the incident investigation is what keeps people alive.

For a full breakdown of what operational risk management software looks like when it is built for mining and heavy industry — bowtie native, ISO 31000 register, ICAM investigations, and critical control management in one connected model — see Risk Management Software for Mining, Construction & Heavy Industry.

Start a 30-day free trial with demo data included. No credit card required.