What is bowtie analysis? A practical guide

The short answer. Bowtie analysis is a structured way to examine one unwanted event — a loss of containment, a runway excursion, a data breach — by mapping everything that could cause it, everything that could follow it, and every barrier standing in the way, on a single bowtie-shaped diagram. The result is a control picture that an engineer, an operator, an executive, and an auditor can all read the same way.

The anatomy of a bowtie

Six elements, always in the same places:

• Hazard — the thing with the potential to do harm: the flammable inventory, the moving aircraft, the sensitive dataset. Written in the header, not on the diagram lines.
• Top event — the knot of the bowtie: the moment control of the hazard is lost. Undesirable, but not yet the damage itself.
• Threats — the credible causes, one line each, entering from the left.
• Consequences — the distinct harmful outcomes, one line each, exiting to the right.
• Barriers (controls) — preventive on the left of the knot, recovery on the right. The working parts of the diagram.
• Degradation factors — the conditions that defeat a barrier, each with its own degradation control. The honest part of the model, and the part audits probe.

The method, step by step

1. Define the hazard and the top event. This is the decision that makes or breaks the analysis. The top event must sit between cause and harm: "loss of containment", not "corrosion" (too early) and not "explosion" (too late). If prevention and recovery both make sense around it, it is well placed.

2. List the threats. Ask what could credibly bring the top event about. Write each as a specific mechanism — "isolation error during live maintenance", not "human error". Five to eight is the usual healthy range.

3. List the consequences. Ask how the event ends, and keep genuinely different outcomes separate: a pool fire and a toxic exposure are fought with different controls, so they get different lines.

4. Place the barriers. For each threat line: what stops this cause reaching the top event? For each consequence line: once the top event has happened, what limits this outcome? A barrier must be a real, failable measure — equipment, system, or defined human intervention — not an aspiration. Where the same barrier defends several lines, model it once and link it, or your register will lie to you later.

5. Interrogate every barrier. How effective is it, on evidence, today? What degrades it? Which barriers are critical — the ones whose failure would significantly raise the risk despite everything else? For those, write a performance standard: what the control must achieve, the criteria, the verification, and the trigger when verification fails.

6. Keep it alive. A bowtie in a slide deck decays the way the Swiss cheese model predicts — holes widen quietly. The diagram earns its keep when it stays connected to the control register, the effectiveness ratings, and the verification evidence, and gets re-reviewed when the plant, the organisation, or the threat picture changes.

Bowtie vs the other methods

Bowtie analysis does not replace the quantitative and bottom-up methods; it sits above them and communicates what they find.

• HAZOP finds deviations exhaustively, node by node. Its high-consequence findings become bowtie top events; its safeguards become barriers you can then rate and verify.
• FMEA works bottom-up from component failure modes. It decides what to maintain and design out; the bowtie shows how the big event is controlled.
• LOPA counts independent protection layers for one scenario and proves the arithmetic. The bowtie carries those layers forward as controls with owners and standards.
• Fault tree analysis gives Boolean rigour and cut sets where quantification is demanded. A bowtie is, structurally, a simplified fault tree married to a simplified event tree — the readable version operations can own.

What auditors and regulators look for

A reviewer rarely challenges the shape of a bowtie. They challenge its honesty, in predictable places: effectiveness ratings with no evidence behind them; barriers written as aspirations; no degradation factors anywhere (a sure sign of an unexamined model); critical controls with no performance standard; and a diagram whose register lives in a separate spreadsheet that stopped matching it two revisions ago. Under Australian WHS law the stakes are explicit — the SFAIRP duty is demonstrated through exactly this control evidence.

The cure for all five findings is the same: keep the diagram, the register, and the verification connected in one model. That is the problem Bowtie Risk Engine exists to solve — the diagram, the control register, the performance standards, and the audit PDF are one artefact, not four.

See it, don't take my word for it

Six complete worked bowties ship with the product — process safety, aviation SMS, cyber security, medical devices, reliability, and psychosocial hazards. Every one opens read-only in the real editor with no sign-in, with every control, degradation factor, and performance standard readable in full.