Monty & CoMonty&CoLearn
Methodology

What is a bow tie?

A bow tie is a diagram of a single risk event. The event sits at the centre, the things that could cause it fan out to the left, the things that could follow from it fan out to the right, and the controls sit as bars across each pathway. Read left to right it answers three questions in order: what could set this off, what stands in the way, and if it happens anyway, what then.

The technique is described in AS/NZS IEC 31010:2020, the Australian adoption of IEC 31010:2019, at clause B.4.2:

A bow tie is a graphical depiction of pathways from the causes of an event to its consequences. It shows the controls that modify the likelihood of the event and those that modify the consequences if the event occurs.

When should you reach for one?

The standard is specific about the circumstances, and they are worth taking literally.

  • The event has several possible causes and several possible consequences. A bow tie is used "when the situation does not warrant the complexity of a full fault tree analysis and event tree analysis but is more complex than can be represented by a single cause-event-consequence pathway". If your risk really is one cause leading to one outcome, a register row says the same thing faster.
  • You are assessing controls. Specifically, "to check that each pathway from cause to event and event to consequence has effective controls, and that factors that could cause controls to fail (including management systems failures) are recognized".
  • The consequences are serious. The standard notes it is "particularly used for analysing events with more serious consequences". Effort should follow exposure.
  • You need to expand a register entry. A bow tie "can be used to explore in detail the causes and consequences of events that are recorded in a simple form in a risk register", and to record a risk "that does not fit the simple linear representation" of one.
  • After the fact, not just before. It "can be used proactively to consider potential events and also retrospectively to model events that have already occurred". A bow tie built after an incident is one of the more honest post-incident artefacts available, because it forces you to show which barrier failed.

Reach for something else when the pathways interact. If two causes must both occur for the event to happen, a bow tie cannot show it (see the limitations below) and you want fault tree analysis. If you need the numbers rather than the structure, see Monte Carlo basics for project risk.

How do you build one?

The construction order below is the standard's own, at B.4.2.1. It is worth following in sequence: each step constrains the next, and teams that start with controls rather than the event tend to produce a diagram of what they already do rather than of the risk.

1. Put the event of interest at the knot

One event per diagram. Phrase it as an occurrence, not an action and not an outcome. "Loss of sensitive customer data" is an event; "hackers steal data" is a cause; "customers stop trusting us" is a consequence.

2. List the risk sources to the left

The standard says to list "sources of risk (or hazards/threats in a safety context)" and join each to the knot with a line "representing the different mechanisms by which sources of risk can lead to the event". ISO 31000:2018 defines a risk source (clause 3.4) as an "element which alone or in combination has the potential to give rise to risk".

Beau-Tie labels these causes, which is the commoner word in bow-tie practice. A good one reads as a precondition a witness could testify to: phishing of staff credentials, unpatched software vulnerability, third-party supplier compromise. Each gets its own line, because the whole point of the left side is that different pathways have different control coverage.

3. Put barriers across each line

Controls on the cause side are drawn "as vertical bars across the lines". The mental model is physical: a barrier interrupts a pathway. A control that does not sit on a specific pathway is usually either a management function (step 6) or not really a control.

ISO 31000:2018 clause 3.8 defines a control as a "measure that maintains and/or modifies risk". The maintains half is deliberate 2018 wording and often forgotten: a control that holds a risk where it is, rather than reducing it, is still a control and still needs to keep working. The standard's second note is the one to read aloud in a workshop: "Controls may not always exert the intended or assumed modifying effect."

4. Fan the consequences out to the right

Lines "radiate out from the event to each potential consequence". Keep them distinct rather than restating one another: regulatory penalties, reputational damage and direct financial loss are three consequences; financial loss and loss of revenue are one consequence written twice.

ISO 31000:2018 clause 3.6 calls these consequences, and Beau-Tie's interface uses the standard's word. Most registers in the wild say impacts. Same thing.

5. Put reactive controls after the event

On the right, "vertical bars represent reactive controls or barriers that modify consequences". This is the split that matters most and the one most often blurred: cause-side controls change whether the event happens, consequence-side controls change how bad it is once it has. A treatment plan that cannot say which of the two it is buying is not finished.

6. Add escalation factors, and controls on them

This step is routinely skipped and it is the one that separates a real bow tie from a pretty one. The standard: "Factors that might cause the controls to fail (escalation factors) are added, together with controls for the escalation factors."

In other words: your barrier has its own failure modes. Multi-factor authentication is a control; "staff share tokens under deadline pressure" is an escalation factor that defeats it; and whatever you do about that pressure is a control on the escalation factor. A diagram showing only the barriers, and not what undermines them, is a picture of your intentions.

7. Show the management functions that hold the controls up

"Management functions which support controls (such as training and inspection) can be shown under the bow tie and linked to the respective control." A control is rarely self-sustaining. Training, inspection, maintenance and assurance are what keep it working, and drawing them makes it visible when a dozen barriers all rest on the same overstretched function.

Rating the risk

Beau-Tie plots up to three ratings on one matrix, and they answer different questions.

  • Residual is the risk as it stands with today's controls running. ISO 31073:2022 defines residual risk (3.3.38) as the "risk remaining after risk treatment", and adds a note worth carrying: residual risk "can contain unidentified risk". It is what is left after treating what you found, not a complete account of what is left. The standard also notes it "can also be known as retained risk", which is the more honest name, because somebody is carrying it.
  • Target is where you intend the residual to land once planned controls are live. Not a term either standard defines; it is common practice, and the distance between residual and target is your treatment plan's ambition stated as a number.
  • Appetite is the level above which the organisation will not tolerate the risk. ISO 31073:2022 3.3.27 defines risk appetite as the "amount and type of risk that an organization is willing to pursue or retain", and ISO 31000:2018 clause 5.2 puts establishing it with top management. It is not the analyst's to set, which is why it is optional in Beau-Tie: plenty of organisations have no stated appetite, and inventing one to fill the field would be worse than leaving it empty.

The mechanics of the matrix itself, and what a rating does and does not mean, are in Risk matrices and the residual / target / appetite triple.

Strengths and limitations

The standard states both at B.4.2.5, and it is more candid than most vendor material about this technique.

Strengths. It "is simple to understand and gives a clear pictorial representation of an event and its causes and consequences"; it "focuses attention on controls which are supposed to be in place and their effectiveness"; it "does not need a high level of expertise to use"; and, less well known, it "can be used for desirable consequences as well as undesirable ones". A bow tie for an opportunity is a legitimate use: causes you want to encourage, barriers you want to remove.

Limitations. Two, and the first is a hard structural limit:

  • "A bow tie cannot depict a situation where pathways from causes to the event are not independent (i.e. where there would be AND gates in a fault tree)." Every line on the left is an independent route to the event. If your risk needs two things to go wrong at once, a bow tie will quietly misrepresent it, and no amount of care with the drawing fixes that. Use fault tree analysis.
  • "It can over-simplify complex situations particularly where quantification is attempted." The standard allows some quantification, but only "where pathways are independent, the probability of a particular consequence or outcome is known and the probability that a control will fail can be estimated" — and notes that in practice "pathways and barriers are not independent, and controls may be procedural and their effectiveness uncertain".

Where Beau-Tie sits against the standard

Beau-Tie implements steps 1 to 5: one event per diagram, causes and consequences on their own lines, and typed, rated controls on each pathway. It rates residual, target and appetite on a configurable matrix, and exports to JSON, PNG, Excel (a risk register with one row per risk), PDF and PowerPoint.

It does not yet model steps 6 and 7. There is no way to record an escalation factor, or the control on one, and no way to show the management functions that support a control. Both are part of the technique as the standard describes it, so a bow tie built in Beau-Tie today is a complete diagram of pathways and barriers and an incomplete one of why the barriers might not hold. Worth knowing when you use it, and it is on our list rather than a deliberate omission.

Beau-Tie also has no cascading bow ties, where "the consequences of one event become the cause of the next". For now, that relationship lives in your head or in a second diagram.

Control types: an honest note on sourcing

Beau-Tie types controls four ways: preventive (reduces the likelihood of the event), detective (reduces time to discovery once an event is in motion), corrective (reduces consequence if the event occurs) and directive (shapes behaviour to support the other three).

This four-way split is widely used in internal-control and audit practice, but we have not been able to trace it to an authoritative standard, and an earlier version of this page wrongly credited it to ISO 22301, which contains nothing of the kind. AS/NZS IEC 31010:2020 makes a simpler cut in the bow-tie clause itself: controls that modify the likelihood of the event, and reactive controls that modify the consequences after it. If you know of a real source for the four-way version, we would genuinely like to hear about it.

See one built

For the quantitative counterpart, where a risk gets a distribution rather than a band, see single-event risk quantification. A bow tie and a quantified model of the same event are complementary: the bow tie says which pathways exist and what guards them, the simulation says what it could cost.