Bow-Tie Analysis

Make risk controls inspectable by showing what can cause loss of control, what can follow and which barriers are supposed to prevent or recover from it.

In one minute

Bow-Tie Analysis places one top event at the centre of a risk model:

• a hazard is the source of potential harm that is present in the activity;
• threats are direct paths that can cause the top event;
• the top event is the moment control is lost, while recovery may still be possible;
• consequences are credible outcomes that can follow the top event;
• preventive barriers act between threats and the top event;
• recovery or mitigative barriers act between the top event and consequences;
• degradation factors explain how barriers can weaken;
• degradation controls protect the barriers themselves.

The diagram resembles a bow tie: threats and prevention on the left, the top event in the knot and consequences with recovery on the right.

A bow-tie model is not automatically a quantitative risk assessment. It makes the control architecture, assumptions and ownership visible so they can be tested and managed.

Best for: one material loss-of-control scenario with multiple credible threats, consequences and barriers.
Avoid when: the hazard or top event is vague, every failure is placed in one diagram, or control effectiveness cannot be examined.

The problem it addresses

Risk registers often contain a sentence, a red score and a list of mitigations without showing where each control acts. The same weak control may be credited several times. Detection may be mistaken for prevention, policies may be listed as barriers without an executable mechanism, and no one owns degradation.

Bow-Tie Analysis creates a causal control view. It distinguishes preventing loss of control from limiting consequences after loss of control. The distinction matters for safety, cyber, financial and AI-enabled operations where a single control is rarely sufficient.

When to use it

Use Bow-Tie Analysis when:

• a material hazard has several direct threat paths;
• leaders need to see preventive and recovery controls separately;
• a risk register names controls without showing their function;
• an FMEA has identified a high-priority scenario needing deeper barrier design;
• automation or AI expands execution authority;
• incidents reveal that controls exist on paper but fail in operation;
• assurance needs named owners, performance standards and evidence.

When not to use it

Do not use it:

• as one diagram for an entire enterprise risk universe;
• before agreeing the hazard and top event;
• to replace specialist quantitative assessment required by law or engineering practice;
• to assume every listed procedure is an effective barrier;
• to combine unrelated consequences into a generic “business impact”;
• when causal uncertainty requires investigation first;
• as a static workshop image without monitoring and review.

Use FMEA to scan and prioritise many failure modes. Use Root Cause Analysis to investigate an event that has already happened.

Inputs required

Prepare:

• a bounded activity and hazard statement;
• a precise recoverable top event;
• incident, near-miss, audit and operating evidence;
• credible direct threats and consequences;
• existing technical, human and organisational controls;
• control owners and performance standards;
• evidence about control presence, availability and effectiveness;
• escalation, recovery and specialist review requirements.

Step-by-step process

1. Define the hazard

Describe the source of potential harm that is part of the activity: stored energy, payment authority, sensitive data, autonomous action or hazardous material. Do not write the consequence as the hazard.

2. Define one top event

State the moment control is lost but consequence is not yet fixed. “An unauthorised payment instruction passes into approval” is more useful than “fraud happens.”

3. Identify direct threats

List credible conditions that can directly cause the top event. Separate threats by mechanism rather than by department. Retain uncertainty and avoid inventing a path to fill the diagram.

4. Identify consequences

Describe distinct credible outcomes if recovery fails: financial loss, customer harm, legal exposure, service interruption or unsafe state. Keep consequence severity separate from its path.

5. Map preventive barriers

For each threat, identify controls that can stop it reaching the top event. A barrier needs a mechanism, performance expectation and evidence. Training or policy alone is not automatically a barrier.

6. Map recovery barriers

For each consequence path, identify controls that detect, stop, contain or reduce harm after the top event. Examples include transaction hold, human confirmation, safe-state transition and tested restoration.

7. Test independence and common-mode exposure

Ask whether several barriers depend on the same identity provider, data source, model, operator, power supply or procedure. Controls that fail together do not provide the resilience implied by several boxes.

8. Add degradation factors and controls

Identify what weakens each critical barrier: stale permissions, alert fatigue, missing maintenance, poor calibration, untested handover or incentive conflict. Add controls that detect or prevent degradation.

9. Assign ownership and assurance

Name one accountable owner for each critical barrier, the evidence that demonstrates readiness and the action when performance falls below threshold.

10. Connect to operation

Define monitoring, exercises, incident learning and change triggers. Revalidate the model when the hazard, workflow, system authority, data or operating context changes.

AI automation lens

AI can help extract candidate threats and controls from authorised incident records, compare wording across risk registers and flag paths with no barrier or owner. Simulation can support scenario exploration when assumptions and model limits are explicit.

AI must not:

• invent control effectiveness or independence;
• classify a policy statement as an operational barrier without evidence;
• hide common dependencies between model, data and tool access;
• own residual-risk acceptance;
• receive broader production authority merely to monitor its own actions.

For AI-enabled systems, include prompt or input manipulation, model error, stale data, tool misuse, permission drift and human over-reliance only where they are credible direct threats. Controls need tested stop and recovery paths.

Visual model

Text alternative: direct threats approach a central loss-of-control event through preventive barriers. From the top event, recovery barriers act before distinct consequences. Degradation factors can weaken barriers and require controls of their own.

Interactive example

Scenario

A finance team allows an AI assistant to draft supplier-payment instructions from email and invoices. A human approves payments, but the interface shows the generated instruction without source comparison. The central concern is an unauthorised or materially altered instruction entering approval.

Your move

Define the hazard, top event, two threats, preventive barriers, one consequence path, recovery barriers and a degradation factor.

Worked answer

The hazard is access to supplier data and payment-instruction drafting authority. The top event is an instruction that does not match authorised supplier evidence entering the approval queue as valid.

Threats include a compromised supplier email and extraction from an altered invoice. Preventive barriers include verified supplier-master matching, permission-limited source retrieval and a deterministic comparison that blocks changed bank details. Consequences include unauthorised payment and delayed legitimate payment.

Recovery barriers include an independent beneficiary confirmation for bank-detail changes, a payment hold, rapid recall procedure and incident escalation. A degradation factor is stale privileged access after role change; its degradation control is automated entitlement review with an accountable access owner. Human approval is not credited as independent if the human sees only the same generated summary.

Facilitation notes

• Keep one top event per model.
• Use direct threat-to-event and event-to-consequence paths.
• Ask what a control physically or procedurally does.
• Require evidence and a performance threshold for critical barriers.
• Challenge shared dependencies and human-overload assumptions.
• Include operators, engineering, risk and recovery owners.

Expected output

• a defined hazard and top event;
• evidence-linked threat and consequence paths;
• preventive and recovery barriers by path;
• critical barrier performance standards;
• degradation factors and controls;
• independence and common-mode findings;
• accountable owners and assurance evidence;
• monitoring, response and review triggers.

Common mistakes

1. Consequence as top event. Recovery opportunities disappear from the model.
2. Control list without mechanism. Policies and training receive untested credit.
3. Detection called prevention. A control acts after the top event but appears on the left.
4. Repeated dependent barriers. Several boxes fail through one shared service or person.
5. No degradation model. Controls are assumed permanently available.
6. Static diagram. Ownership, monitoring and change control are absent.

Quality checklist

• The activity, hazard and one recoverable top event are explicit.
• Threats directly lead to the top event.
• Consequences follow the top event through credible paths.
• Preventive and recovery barriers are correctly positioned.
• Critical barriers have mechanisms, standards, evidence and owners.
• Common-mode dependencies are visible.
• Degradation factors and controls are recorded.
• Monitoring, response and review triggers connect the diagram to operation.

Template

Use the structured Bow-Tie workspace template to maintain traceable threat, barrier, consequence and assurance records.

Knowledge check

Question: Two preventive barriers depend on the same identity service and entitlement data. How should they be represented?

A. As fully independent layers.
B. With the shared dependency and common-mode failure visible, followed by an independence or recovery decision.
C. As one guaranteed control because two teams own them.
D. Only on the consequence side.

Answer: B. Several boxes do not create resilience when one dependency can disable them together.

Related tools

• FMEA identifies and prioritises potential failure modes.
• Root Cause Analysis investigates mechanisms after an event.
• Mistake Proofing strengthens selected preventive controls.
• Process Decision Program Chart anticipates implementation disruptions.
• RACI Matrix clarifies control and recovery ownership.

References

1. UK Civil Aviation Authority. “Bowtie.” https://www.caa.co.uk/safety-initiatives/working-with-industry/bowtie/ (opens in a new tab)
2. UK Civil Aviation Authority. “Creating BowTies — step by step guide.” https://www.caa.co.uk/publication/download/17949 (opens in a new tab)
3. UK Civil Aviation Authority. CAA Strategy for Bowtie Risk Models. https://www.caa.co.uk/publication/download/15216 (opens in a new tab)
4. International Association of Oil & Gas Producers. Bow tie diagrams in risk management. Report 544, 2016.

Method profile

• Primary job: make one material risk scenario and its control architecture inspectable.
• Core artifact: a threat–top-event–consequence model with owned barriers and degradation controls.
• Decision boundary: Bow-Tie supports control and assurance decisions; it does not accept residual risk or replace required specialist analysis.
• Evidence standard: credible paths, barrier mechanism, performance evidence, independence and operating ownership.
• Review trigger: incident, barrier failure, authority change, new threat, process redesign or changed recovery capability.