ISO Compliance Insights & Best Practices

Bow Tie Analysis: The 6 Essential Elements Explained (2026)

Last updated 19 September 2026

Bow tie analysis is the risk assessment technique that puts a single unwanted event in the centre of a page, its causes on the left, its consequences on the right, and the controls that stand between them on the lines that join them — and it is the one technique in IEC 31010:2019 that a board, an operator and an auditor can all read without training.

IEC 31010 files it in Annex B.4, techniques for analysing controls, alongside HACCP and layers of protection analysis, because that is what a bow tie does: it makes visible which barriers prevent the causes from reaching the event and which mitigate the event once it has happened, and it exposes the escalation factors that degrade those barriers.

Six elements make up the diagram — the hazard, the top event, the threats, the consequences, the preventive barriers and the mitigative barriers — with escalation factors and their controls as the optional seventh and eighth. This guide sets out the six elements with the rules for each, walks through building a bow tie from a register line, explains how it connects to the ISO 31000 process and to risk criteria, shows a worked example, and lists the errors that turn a bow tie into decoration.

Bow tie analysis: the six elements — Hazard (the source) → Threats (left) → preventive barriers → TOP EVENT (loss of control) → mitigative barriers → Consequences (right) · escalation factors and escalation-factor controls hang off the barriers · one diagram per top event · IEC 31010:2019 Annex B.4.

What bow tie analysis is for

IEC 31010 groups techniques by purpose, and the bow tie’s purpose is control analysis. Identification techniques find events; likelihood and consequence techniques estimate them; the bow tie shows what the organisation relies on to keep an event from happening and to limit it when it does. It combines the left half of a fault tree — causes leading to an event — with the right half of an event tree — outcomes following it — in a form that omits the logic gates and probabilities and keeps the barriers.

That trade is deliberate: a bow tie is less rigorous than the trees and far more communicable, which is why it is used for major-accident hazards in process safety, for critical risks in enterprise registers, and increasingly for cyber and operational risk. Our guide to IEC 31010 covers the other 40 techniques and how to combine them.

The six elements of a bow tie

Element	Where on the diagram	Definition	Rule
1. Hazard	Above the knot	The source of harm the organisation deals with as part of its business — flammable inventory, customer data, a fleet, a payment system	State it neutrally; the hazard is not the event
2. Top event	The knot	The moment control over the hazard is lost — loss of containment, unauthorised access to data, vehicle leaves the road, payment sent to the wrong account	One top event per diagram; not the consequence
3. Threats	Left side	The causes that can lead directly to the top event — corrosion, phishing, driver fatigue, fraudulent instruction	Each threat must be able to cause the top event on its own
4. Consequences	Right side	The outcomes if the top event occurs — fire, regulatory fine and customer harm, injury, financial loss	Each is a distinct outcome, not a restatement of the event
5. Preventive barriers	On the lines from threats to the top event	Controls that stop a threat from causing the top event — inspection, MFA, hours-of-service limits, dual authorisation	Each barrier must be capable of stopping the threat alone, and be owned
6. Mitigative barriers	On the lines from the top event to consequences	Controls that limit the consequence once the event has occurred — detection and isolation, incident response and breach notification, airbags, recall of payment	Each must act after the top event; prevention does not belong here

Optional element	Where	What it adds
Escalation factors	Hanging off a barrier	Conditions that defeat or degrade the barrier — the inspector is untrained, MFA is bypassed for contractors, the driver falsifies the log
Escalation-factor controls	On the escalation factor	Controls on the condition — training and certification, no exceptions policy, tachograph audit

The rule that matters most is the barrier rule: a barrier is a control that, on its own, can stop the threat or limit the consequence, and that someone owns and someone tests. “Policy”, “awareness” and “management oversight” fail the rule — they are escalation-factor controls at best — and a bow tie that lists them as barriers has hidden the fact that the organisation relies on two real controls, not seven.

Building a bow tie from a register line

Pick the risk and separate its parts. A register line reads “risk of data breach causing regulatory fine”. The hazard is the personal data held; the top event is unauthorised access to it; the consequences are the fine, the customer harm and the remediation cost.
List the threats, one per line, each sufficient. Phishing of a privileged user; unpatched internet-facing system; malicious insider; misconfigured cloud storage; lost device. If a cause needs another cause to reach the event, it is an escalation factor, not a threat.
Put the preventive barriers on each threat line. Only controls that stop that threat: for phishing, MFA and privileged access management; for the unpatched system, vulnerability scanning and patch SLAs. Name the owner.
List the consequences and the mitigative barriers. Detection and containment, incident response, breach notification within the deadline, encryption that renders the data unusable, cyber insurance.
Add escalation factors where the barriers are fragile. MFA exceptions; a patch SLA that is not measured; a response plan never exercised — and the controls on each.
Assess the barriers, not the boxes. Each barrier gets an effectiveness rating from evidence — tested, partially tested, assumed — and a criticality rating from how many threats or consequences depend on it.
Read the diagram back to the register. Current risk reflects the barriers as they operate; the treatment plan is the barriers to add or strengthen; the escalation factors are the audit plan. Our guide to inherent vs residual risk covers the columns the bow tie feeds.

Bow tie analysis in the ISO 31000 process

ISO 31000 step	What the bow tie contributes
6.3 Scope, context and criteria	The hazard and top event define the scope of the assessment; the criteria decide which consequences count as significant
6.4.2 Risk identification	Threats and consequences are the identified sources and outcomes; the diagram makes gaps visible
6.4.3 Risk analysis	The barriers are the ‘existing controls’ whose effectiveness ISO 31000 asks to be considered; the diagram is the analysis of them
6.4.4 Risk evaluation	Comparison with criteria per consequence line, informed by barrier effectiveness
6.5 Risk treatment	Treatment options are new or strengthened barriers and escalation-factor controls, placed on the diagram
6.6 Monitoring and review	Barrier testing results update the effectiveness ratings; a failed test changes the current risk
6.7 Recording and reporting	The bow tie is a reporting form in its own right — IEC 31010 lists it among the recording and reporting uses

Our guide to risk criteria covers the thresholds each consequence line is evaluated against.

A worked example

Element	Content
Hazard	Customer payment instructions processed by the treasury team
Top event	A payment is released to an account controlled by a fraudster
Threats and preventive barriers	Business email compromise of a customer → call-back verification on a known number; payment-detail change controls. Fraudulent internal instruction → dual authorisation with segregation of duties; payment limits. Compromised treasury workstation → MFA and privileged access; endpoint detection
Consequences and mitigative barriers	Financial loss → bank recall procedure within the recall window; insurance. Customer relationship damage → incident communication plan. Regulatory finding → incident record and reporting procedure
Escalation factors	Call-back skipped under time pressure → escalation-factor control: no-exception rule with monitoring. Dual authorisation shared between two people who sit together → periodic review of approver pairs
Barrier assessment	Call-back: tested quarterly, effective. Dual authorisation: tested, partially effective (approver pairing). Bank recall: untested — treatment: rehearse with the bank

Errors that turn a bow tie into decoration

A consequence as the top event. “Regulatory fine” in the knot leaves nothing on the right and everything on the left.
Threats that are not sufficient causes. “Poor culture” cannot on its own release a payment; it is an escalation factor on several barriers.
Barriers that are not controls. Policies, awareness, oversight — these degrade or support barriers, they are not barriers.
Barriers without owners or tests. A barrier no one tests has unknown effectiveness, and the diagram implies protection that may not exist.
One bow tie for a whole risk category. “Cyber risk” has a dozen top events; each needs its own diagram.
Never updated. A bow tie drawn once for a workshop and not revised when a barrier fails testing is the audit finding waiting to happen.

Frequently asked questions

What is bow tie analysis?
A risk assessment technique, described in IEC 31010:2019 Annex B among the techniques for analysing controls, that places one top event at the centre of a diagram, its threats and preventive barriers on the left, its consequences and mitigative barriers on the right, and escalation factors and their controls on the barriers.

What are the six elements of a bow tie?
The hazard, the top event, the threats, the consequences, the preventive barriers and the mitigative barriers — with escalation factors and escalation-factor controls as optional additions.

What counts as a barrier?
A control that on its own can stop a threat from causing the top event or limit a consequence after it, with an owner and a test. Policies, awareness and oversight are not barriers; they support or degrade barriers and belong with the escalation factors.

How does a bow tie relate to fault tree and event tree analysis?
It combines the causal left side of a fault tree with the outcome right side of an event tree, dropping the logic gates and probabilities to keep the barriers visible; where quantification is needed, the trees or LOPA are used alongside it.

When should we use bow tie analysis?
For the risks whose controls the organisation most needs to understand — major-accident hazards, critical enterprise risks, significant cyber and operational events — and wherever a board or regulator needs to see what is relied on; one diagram per top event.

Where this leaves you

Use bow tie analysis for the risks that matter and draw it by the rules: one top event, threats that are sufficient causes, barriers that are real controls with owners and tests, mitigations that act after the event, and escalation factors where the barriers are fragile — then rate the barriers from evidence and read the diagram back into the register and the audit plan, because the bow tie’s value is not the picture but the honest count of what the organisation actually relies on.

References

IEC 31010:2019 — Risk management — Risk assessment techniques — Annex B.4, techniques for analysing controls: bow tie analysis.
ISO 31000:2018 — Risk management — Guidelines — Clause 6, the process the bow tie serves.

More on ISO 31000

Bow tie analysis — you are here
IEC 31010: the risk assessment techniques
ISO 31000: the three components
Inherent vs residual risk
Risk criteria under ISO 31000
The risk management policy

The bow tie worksheet and diagram template, the barrier assessment register with owners, tests and effectiveness ratings, and the risk assessment procedure that selects the technique are in the ISO 31000 Risk Management Toolkit, or start with the free templates.

Governance Docs

Governance Docs LLC