Bowtie and barrier management software: connect the model to evidence
A barrier has an owner and a green status in the diagram, but its supporting check is overdue. What should the next reviewer see, and who decides what happens next? Start the software evaluation with that handoff. Compare the work needed to maintain a risk register, author a bowtie and keep operational evidence connected to its barriers.
Jump to the 10 products
Editorial responsibility: Dimitris Mitsios (Founder of The QHSE Standard; product marketing at Tekmon) · Tekmon pays for sponsored placements on this site (disclosure) · How pages are made · LinkedIn
Three connected buying decisions
| Scope | Record you need | What the demonstration must resolve |
|---|---|---|
| Risk register | Risks, accountable owners, assessments, actions and review dates. | Can a changed assumption reach the responsible reviewer and preserve the previous decision? |
| Bowtie authoring | A defined hazard and top event, threat/consequence paths, barriers and factors that can weaken them. | Can specialists build, explain, revise and export the agreed model? |
| Operational barrier management | Barrier responsibilities, performance criteria, current evidence, impairments and follow-up. | Can the team trace a changed or missing evidence record to the affected barrier, site and responsible decision maker? |
A model explains the path; evidence supports the status
Define the hazard and operating context first. The top event represents loss of control, with preventive controls before it and recovery or mitigating controls after it. Conditions that weaken a control belong in the review too. The CAA's bowtie elements provide an introduction in an aviation safety context.
- 1
Threat
A cause that could lead to the top event.
- 2
Preventive barrier
A control intended to stop that progression.
- 3
Top event
Loss of control over the defined hazard.
- 4
Mitigating barrier
A control intended to limit the consequence.
- 5
Consequence
A potential harmful outcome.
An explanatory sketch, not a complete hazard study. Real models can have multiple paths, shared dependencies and escalation factors. Agree those relationships with the specialists responsible for the assessment.
A risk register and bowtie can support one another; they need not be competing records. CAA guidance discusses links to a hazard log and risk matrix, and review after changes to controls, owners and assumptions. It does not establish a universal scoring method or software requirement for every industry.
Ask for a barrier record you can explain
| Field or relationship | What to show in the demo | Question for the reviewer |
|---|---|---|
| Stable barrier and model IDs | The barrier's model revision, site and links to all relevant scenarios. | Is this one shared definition or a distinct installed control at each site? |
| Accountable owner and criterion | A named role and the approved criterion used to assess the barrier. | Who owns the criterion, who performs the check and who accepts the evidence? |
| Evidence and freshness | Source, result, observation date, review state and next required check. | Can I distinguish evidence that is current from a late or missing check? |
| Impairment and response | Recorded change, affected scope, action owner and review decision. | What remains unresolved, and which procedure governs the response? |
| History and handoff | Prior values, author, reviewer and the status visible to the next shift. | Does the export explain why the displayed status changed? |
Product scopes to investigate
These are different starting points for a purchase: authoring a model, connecting assurance evidence or feeding operational inputs. They are not equivalent bundles or a performance ranking. Confirm each quoted module and interface; the broader profile scope stays visible on each linked profile.
Ordered by how closely our sources document this process, not by quality. Sponsored placements are labelled. How lists are ordered
Same rule for every product: tagged “Barrier Management”, “Risk Assessment”, “Risk Management” or “Process Safety”, with a sourced bowtie or barrier management capability in its record, or one the vendor stated to us, labelled as vendor-stated. 10 qualify; the first 8 are shown, then the other 2.
Haz360
Documented: SIL verification and bow-tie (conditional). Source: haz360.com
BowTieXP
Start with authoring: BowTieXP describes editable diagrams, barrier attributes, accountable roles, supporting activities and reports. Its product page distinguishes some Standard and Complete features. Demonstrate: a model revision, an owner-specific view and an export that retains the context of a changed barrier. The profile covers desktop modeling. Shared approval, live evidence feeds and BowTieXP Enterprise require separate confirmation. Group activation without network access does not establish disconnected Enterprise collaboration. Source: wolterskluwer.com
Onspring
Documented: Risk register and mitigation management. Source: onspring.com
Synergi Life (DNV)
Start with connected assurance: DNV describes bowtie dashboards, barrier integrity ratings, corrections and information from audits, inspections and incidents linked to barriers. Demonstrate: an inspection finding changing the evidence behind one barrier, followed by a reviewed correction and a visible history. The directory profile covers a broader modular platform. Confirm the barrier application and connections in the proposal. Connect's offline reporting scope is not evidence of offline barrier approval. Source: dnv.com
Enablon
Documented: Barrier and critical-control monitoring (conditional). Source: wolterskluwer.com
IsoMetrix
Documented: Shared risk libraries. Source: isometrix.com
Origami Risk
Documented: Enterprise risk register and control testing. Source: origamirisk.com
CORE-EHS
Documented: Bow-tie barrier management. Source: coreehs.com
Also meet the rule, in the same order (2)
Use one model with deliberately incomplete evidence
Create a fictional model M01 with barriers B01 and B02. Give B01 an owner and an overdue verification record. Give B02 a recent attachment but no recorded approval. Reuse a barrier definition at a second fictional site, keeping each site's verification record separate. Agree the expected states with your assessment team before the demo.
An overdue check does not by itself prove physical failure, and a recent attachment does not prove an accepted result. Ask the vendor to show missing, pending, verified and impaired states according to the rules you approved. The exercise tests record handling; it provides no operational permission or engineering acceptance criterion.
Run five tests from model revision to operational handoff
Build and explain the agreed model
Identify the hazard, top event, threat and consequence paths, preventive and mitigating barriers, and relevant escalation factors. Assign stable IDs. Ask a second reviewer to explain the same relationships from the exported model.
Expose missing or overdue evidence
Open B01 with its overdue check and B02 with its unapproved attachment. Inspect the displayed status, source date, owner and required follow-up. Record any manual step instead of assuming the product calculates a valid assurance status.
Change a shared definition without mixing site evidence
Revise the shared barrier definition, then inspect both sites. Show which model versions are affected, which evidence remains site-specific and who must review the change. Demonstrate the proposed approval arrangement in the actual edition.
Trace an impairment and a stale source into the next shift
In a test environment, record an impairment and delay one evidence feed or update. Follow the affected barrier, action and next-shift view. Identify freshness indicators, manual fallback and the responsible decision maker under the site's approved procedure.
Export the decision and reconcile the quote
Retrieve model revisions, barrier IDs, owners, dated evidence links and review decisions. Have each proposed role attempt the permitted tasks. List the authoring, collaboration, interfaces, hosting and training used, including anything outside the quoted scope.
Scope the work behind the diagram
Keep the open questions in the decision record
Start a scorecard with the first researched profiles of the list above. Their questions also cover broader platform and work-control scope; adapt the requirements to your proposed barrier workflow and leave results untested until observed.
Start the bowtie and barrier demo scorecardSources and review boundaries
7 sources, checked 21 Sep 2026
Sources checked 21 September 2026. CAA material provides methodological context from aviation. Vendor pages establish advertised scope, not tested barrier effectiveness, complete entitlement or a quantified risk result. The fictional model and demo tests are editorial buying exercises, not a completed hazard study or authorization to operate.
Continue with the connected risk workflows
More related guides
- Fault Tree Analysis (FTA) — definition, software & FAQs
Definition of fault tree analysis.
- EU Seveso III Compliance Guide for Major-Hazard Sites (2026)
Article on EU Seveso III compliance for major-hazard sites.
- LOPA (Layer of Protection Analysis) — definition, software & FAQs
Definition of layer of protection analysis.
- ALARP (As Low As Reasonably Practicable) — definition, software & FAQs
Definition of as low as reasonably practicable.
- PHA (Process Hazard Analysis) — definition, software & FAQs
Definition of a process hazard analysis.