Most incident software is a form builder with a workflow engine attached: it records what happened and routes approvals. That is incident management. Incident investigation is a different discipline. It exists to find out why the event happened and to change the system so it cannot happen again. If your organisation investigates under ICAM (the Incident Cause Analysis Method used across Australian mining, infrastructure and energy), the software you choose either supports that discipline or quietly erodes it.
1. Methodology fidelity, not a methodology sticker
Plenty of platforms claim ICAM alignment because they offer four category dropdowns. Fidelity looks different: contributing factors analysed across the four ICAM families of Absent/Failed Defences (DF), Individual/Team Actions (IT), Task/Environmental Conditions (TE, including human factors) and Organisational Factor Types (OFT), with the platform steering systemic corrective actions toward DF and OFT, where lasting fixes live. Ask the vendor who validated their factor taxonomy. If the answer isn't a practising ICAM training organisation, the sticker is doing the work.
2. Evidence before analysis, enforced by structure
ICAM's quality comes from sequence: plan evidence collection across People, Environment, Equipment, Procedures and Organisation (PEEPO), collect facts, build the timeline, and only then analyse. Good software encodes that sequence: phase gates that keep analysis locked until evidence and timeline exist, and a factual timeline that captures work-as-imagined, work-as-normal and work-as-done so the gaps between them surface systemic learning. If investigators can jump straight from event description to conclusions, the tool is training your team to skip the method.
3. Traceability from recommendation back to evidence
A defensible investigation lets a reviewer, or a regulator, walk any recommendation back through the contributing factors it addresses to the evidence those factors rest on. In software terms: recommendations linked to factors, factors linked to evidence items, and a report generator that carries those links rather than flattening them into prose. This single capability is what separates investigation platforms from document templates.
4. Australian data residency, stated precisely
For mining and infrastructure operators, data sovereignty questions arrive early in any IT review. The bar to look for: application data at rest in Australia; AI processing (if the platform offers it) also confined to Australian regions, not routed through the US or Asia; and a published subprocessor list so nothing needs to be taken on faith. Treat vague phrases like "hosted on world-class cloud infrastructure" as a request to keep asking questions.
5. Investigation quality you can measure
Boards and regulators increasingly ask not "did you investigate?" but "how good are your investigations?". A modern platform should answer with data: indices for investigation quality, corrective-action closure reliability and control health, computed from the investigations themselves. If quality is only visible by reading every report, it isn't governed. It's hoped for.
The short checklist
- Factor taxonomy validated by a practising ICAM organisation (DF / IT / TE / OFT, human factors included)
- PEEPO evidence planning and phase-gated workflow: evidence before analysis
- Work-as-imagined vs work-as-normal vs work-as-done timeline
- Recommendation → factor → evidence traceability, preserved in the report
- Australian data residency including AI processing, with a published subprocessor list
- Measurable investigation quality, not just completed forms
SafetyPulse was built against exactly this checklist, designed with ICAM Australia: the team that has trained more than 7,500 investigators. If you're evaluating platforms, our Trust Centre publishes the residency and security detail your IT team will ask for, and a demo takes thirty minutes.