Home
AboutReviewsEnquire Now

Executive Education

Bowtie Risk Assessment: How to Build One, With an Example

How a bowtie risk assessment works: the hazard, top event, threats, consequences, preventive and recovery controls, and escalation factors, worked through step by step for one business risk.

Colleagues mapping the causes, controls and consequences of a business risk

A bowtie risk assessment is a diagram that shows, on one page, how a risk event could happen, what it would lead to, and which controls stand in the way on each side. The event sits in the middle. Its causes fan out to the left and its consequences fan out to the right, so the finished picture looks like a bow tie.

The method was developed in high-hazard industries such as oil and gas, but it works just as well for business risks. Its strength is that it makes controls visible: instead of a single risk score, you can see exactly what is meant to stop the event and what will limit the damage if it happens anyway.

The parts of a bowtie

Element What it means
Hazard The activity or condition that carries the potential for harm
Top event The moment control is lost: the event at the centre of the diagram
Threats The causes that could trigger the top event (left side)
Preventive controls Barriers that stop a threat leading to the top event
Consequences What happens after the top event (right side)
Recovery controls Barriers that reduce or contain the consequences
Escalation factors Conditions that make a control fail, such as a skipped test

How to build a bowtie, step by step

  1. Name the hazard. Describe what you are exposed to, for example dependence on a single payment provider.
  2. Define the top event. Make it specific and measurable. "Payment problems" is too vague; "loss of our main payment provider for more than 24 hours" can be tested.
  3. List the threats. Ask what could realistically cause the top event. Keep each threat distinct and limit the list to the ones that matter.
  4. List the consequences. Ask what would follow, in money, customers, reputation and compliance.
  5. Add preventive controls on each threat line, between the threat and the top event.
  6. Add recovery controls on each consequence line, between the top event and the consequence.
  7. Add escalation factors for the controls you rely on most, and the controls that stop those factors.
  8. Assign owners and check effectiveness. A control nobody owns or tests is an assumption, not a barrier.

Worked example: a payment provider outage

Take a fictional online retailer. The same risk appears as an entry in the risk register example.

Hazard: reliance on one online payment provider. Top event: loss of the main payment provider for more than 24 hours.

Left side: threats and preventive controls

Threat Preventive controls
Technical outage at the provider Service-level agreement with uptime commitments; outage monitoring and alerts
Contract dispute or provider failure Contract review before renewal; annual check of the provider's financial health
Faulty release of our own checkout software Testing before release; documented rollback plan
Cyber attack on the provider Security assurance requested from the provider at onboarding and renewal

Right side: consequences and recovery controls

Consequence Recovery controls
Lost online revenue Contracted back-up provider with a tested switch-over
Customer complaints and lost trust Prepared customer messages and a status page
Orders that cannot be completed Manual order capture for high-value customers
Repeat incidents Post-incident review with actions tracked to closure

Escalation factor: the switch-over to the back-up provider has not been tested recently, so it may fail when needed. Control on the escalation factor: a quarterly switch-over test, with the date tracked as a key risk indicator.

Read across the diagram and the weak points stand out. Three of the four threats depend on the provider's own controls, so the retailer's real protection is on the right side, and almost all of that depends on one recovery control working.

When to use a bowtie

A bowtie is qualitative. It does not calculate a probability or a loss figure, and it takes time to build well. Use it for a small number of high-impact risks where you need to understand and challenge the controls, not for every line in the register.

It complements other tools rather than replacing them. A risk matrix helps you decide which risks deserve a bowtie; the register records the owner, rating and response; KRIs show whether the critical controls are still working.

A bowtie is also different from a fault tree. A fault tree analyses in detail how combinations of failures cause an event, often with probabilities. A bowtie gives a simpler, visual view of both causes and consequences on one page, which makes it easier to discuss with managers and boards.

Common mistakes

  • Vague top events. If people cannot agree when the event has happened, the diagram cannot be tested.
  • Actions listed as controls. "Review supplier contracts" is a task. A control is something in place that stops or limits the event.
  • Too many threats. A diagram with twenty threats is unreadable. Group them or split the bowtie.
  • No owners. Every control should name the person responsible for keeping it working.
  • Never checking effectiveness. A control that exists on paper but has not been tested gives false comfort.

Bow-tie analysis is one of the decision tools covered on LSBUK's enterprise risk management course, alongside risk registers, heat maps, FMEA and Monte Carlo simulation.

Frequently asked questions

What is a bowtie risk assessment?

A bowtie risk assessment is a diagram that places a risk event in the centre, its causes (threats) on the left and its consequences on the right. Preventive controls sit between the threats and the event, and recovery controls sit between the event and its consequences.

What is the top event in a bowtie?

The top event is the moment control is lost, such as a system outage or a supplier failure. It should be specific enough that everyone can agree whether it has happened.

What is the difference between preventive and recovery controls?

Preventive controls stop a threat from causing the top event, such as testing software before release. Recovery controls act after the event to reduce the harm, such as switching to a back-up provider.

Is a bowtie the same as a fault tree?

No. A fault tree analyses in detail how combinations of failures lead to an event, often with probabilities. A bowtie is a simpler visual summary of causes, consequences and controls, designed for discussion and challenge.