What is a bow tie?
A bow tie is a causal diagram of a single risk event. It places the event at the centre, the things that could cause it on the left, the things that could result from it on the right, and the controls that sit on each pathway in between. Read left-to-right, it answers three questions in order: what could trigger this?, what stands in the way?, and if it happens anyway, what then?
The technique formalises something risk teams already do informally when they whiteboard a scenario. ISO 31000:2018 calls it out explicitly as a structured analysis technique, and IEC 31010:2019 catalogues it alongside fault-tree and event-tree analysis as a complementary approach. What separates a bow tie from a generic cause-and-effect map is the discipline: one event per diagram, controls explicitly typed and rated, and a clean split between the prevention side (left) and the recovery side (right).
The five elements
Every bow tie has the same vocabulary. Memorising it pays off because it's also the vocabulary of the supporting standards, regulators, and most enterprise GRC platforms.
Risk event
The single thing this diagram is about — sometimes called the top event. Phrased as a noun-form occurrence, not a verb. "Loss of sensitive customer data" is a risk event; "Hackers steal data" is a cause; "Customers stop trusting us" is an impact.
Causes
Distinct pathways through which the event could occur. A good cause is something a stakeholder could plausibly testify to as the pre-condition: "phishing of staff credentials", "unpatched software vulnerability", "third-party supplier compromise". Each cause gets its own line on the left side; controls are arranged along that line.
Impacts
The consequences if the event happens. Impacts should be distinct, not paraphrases of one another: "regulatory fines and penalties", "reputational damage", "direct financial loss" are three; "financial loss" and "loss of revenue" are one.
Controls
Things you do (or could do) that change the probability or consequence of the event. Each control on a bow tie has four properties:
- Type — preventive (P), detective (D), corrective (C), or directive (Di). Preventive and detective sit on the cause-side; corrective sits on the impact-side; directive can sit anywhere it shapes behaviour.
- Status — existing (running today) or planned (committed but not live). Planned controls render as dashed circles in Beau-Tie so the diagram doesn't overstate today's posture.
- Effectiveness — ineffective, partially effective, effective, or highly effective. A judgement, not a measurement.
- Implementation timeline — only on planned controls (0–3 months, 3–6 months, 6–12 months, 12+ months).
Ratings
A bow tie is rated three ways: residual (the risk as it stands today, with current controls running), target (where you intend to get it to once the planned controls land), and optionally appetite (the level above which the organisation will not tolerate the risk). These three plot on the same matrix and tell three different stories. See the risk matrix article for the mechanics.
Why bow ties earn their place
The flat alternative is a register row: a one-line risk title with a rating column, optionally a controls column. That works for tracking but loses three things a bow tie preserves:
- Pathway-specific control posture. A register row tells you the risk is "high"; the bow tie tells you that one cause has three effective controls and another has only a partially-effective one. The treatment plan is different.
- The prevention / recovery split. Cause-side controls reduce the chance the event occurs; impact-side controls reduce the consequences if it does. Conflating them produces plans that over-invest in one and under-invest in the other.
- A diagram that workshops well. A bow tie on a screen is a focal point for a workshop in a way a register row isn't. Subject-matter experts add causes; treatment owners challenge effectiveness ratings; the central event keeps the conversation honest.
How Beau-Tie maps onto this
Beau-Tie is a one-event-per-bow-tie editor. You edit causes, the central event, and impacts as labelled boxes; you drop control circles onto the lines connecting them; you rate the residual and target risks via a 5×5 matrix; you export the result to PNG, PDF, Excel (as a controls register), or PowerPoint.
The visual encoding follows the May 2026 design system: causes lean cool (10% teal tint), impacts lean warm (10% ochre), the central event is brand ink, and effectiveness colours come from a matched- chroma palette so the diagram reads calmly even when packed with controls. The intent is that a printed bow tie at A4 landscape is legible from a metre away — i.e. usable in a meeting.
What bow ties don't do
Bow ties are causal diagrams, not quantitative models. They make no claims about how likely the event is in absolute terms or how big the financial impact would be. The matrix rating is a judgement about likelihood × consequence on a five-step scale, not a probability or a dollar figure. If you need numbers, the bow tie feeds the conversation but doesn't replace a Monte Carlo run — see Monte Carlo basics for project risk for the quantitative side of the suite.
Bow ties also don't capture interactions between events. If one risk's occurrence makes a second risk more likely, that relationship lives in a different model (a causal Bayesian network or a system-dynamics simulation). For most operational risk work the per-event bow tie is the right resolution; for portfolio-level analysis you stitch many bow ties together via shared controls and shared impacts.
Standards alignment
Beau-Tie's bow tie structure follows ISO 31000:2018 and IEC 31010:2019 vocabulary. Specifically:
- The four control types (preventive, detective, corrective, directive) come from the BS/ISO 22301 business- continuity tradition and are widely used in COSO and SOX frameworks.
- The 5×5 likelihood × consequence matrix is the most common encoding worldwide, but the underlying matrix is fully configurable in-tool — replace the band labels and colour bands if your organisation's standard differs.
- The "residual / target" pair is ISO 31000:2018 §6.5 vocabulary; "appetite" is from ISO Guide 73:2009.