Framework library · Risk management and assessment

Bow tie analysis

A bow tie takes one event you cannot afford, such as losing control of a network or a site, and lays out what could cause it and what it would lead to. Preventive barriers sit between the threats and the event; recovery barriers sit between the event and its consequences. The diagram shows at a glance which paths depend on a single barrier, and prompts the test that matters: whether anyone has seen that barrier work.

LevelIntermediate
TimeTwo to three hours for one top event
Who to involveThe engineers and operators who run the system, the owner of the risk, and someone from incident response who knows what happens after things go wrong.
Also calledbowtie diagram, bow-tie analysis, bowtie risk assessment, barrier analysis

Use it when

  • One event would be severe enough to justify looking at it on its own, such as a national network outage, a tower collapse or loss of control of a satellite.
  • You need to show a board or regulator which barriers stand between a threat and a serious outcome, and who owns each.
  • An incident elsewhere in the industry prompts the question of whether it could happen here, and what would stop it.
  • Controls have been added over the years and nobody is sure which ones carry the weight.

Avoid it when

  • You need a view across many risks. A bow tie covers one event. Use a risk register and a risk heat map for the portfolio.
  • You need to rank the failure points in a process by severity, occurrence and detection. FMEA does that step by step.
  • The event has already happened and you need its root cause. Use five whys or a fishbone diagram.
  • You need a probability for the event. The bow tie is qualitative. A fault tree or a Monte Carlo simulation is needed for numbers.

How to run it

  1. Name the hazard and the top event

    The hazard is the activity that is useful but dangerous, such as changes to the live core network. The top event is the moment control is lost, before any harm is done, such as nationwide loss of voice and data.

  2. List the threats on the left

    Each threat is a distinct way the top event can happen: a faulty vendor release, a configuration error, an expired certificate. Four to six is usual.

  3. List the consequences on the right

    What follows if the event happens and nothing else works: customers unable to reach emergency services, regulatory action, compensation and churn.

  4. Add the barriers on each side

    Preventive barriers stop a threat becoming the event; recovery barriers limit the consequences. A barrier must be able to stop the path on its own. A policy or a training course usually supports a barrier rather than being one.

  5. Add the escalation factors

    Conditions that weaken a barrier, such as changes made at night with a reduced team, or a rollback that has never been tried on the current release.

  6. Test each barrier

    For every barrier, ask who owns it, when it was last shown to work and what would make it fail. Paths that rest on one untested barrier are the findings.

Work through it

Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.

What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.

Mistakes to avoid

  • Choosing a top event that is really a consequence ("the regulator fines us"). The top event is the loss of control; fines sit on the right.
  • Listing barriers that exist only on paper. A rollback plan never rehearsed on the current release is not yet a barrier.
  • Drawing one bow tie for everything. Each top event needs its own diagram, or the threats and barriers stop lining up.
  • Counting barriers instead of testing them. Three barriers that share a cause, such as the same on-call engineer or the same software, can fail together.

Where it comes from

No single published origin: the diagram is usually traced to Imperial Chemical Industries course notes for a hazard analysis lecture at the University of Queensland in 1979. Royal Dutch Shell adopted it as a company standard in the early 1990s, after the Piper Alpha disaster of 1988 pushed the oil and gas industry to manage hazards more systematically. The Center for Chemical Process Safety and the Energy Institute set out current practice in Bow Ties in Risk Management: A Concept Book for Process Safety (2018). Source.

Use it with

Work through it with us

The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.