The bow tie is a controls technique, not a poster

Ask where the bow tie lives in the standard and you get an answer most practitioners find mildly surprising. IEC 31010, the risk assessment techniques standard, writes its entry for the technique in clause B.4, "Techniques for analysing controls", alongside HACCP and layers of protection analysis. The standard knows the diagram does two jobs, its process map also lists bow ties among the recording and reporting techniques next to the register and the heat map, but the home clause, the one that defines the method, is the controls one. The definition there is a diagram with a job: "a graphical depiction of pathways from the causes of an event to its consequences", showing "the controls that modify the likelihood of the event and those that modify the consequences if the event occurs".

That placement is the whole argument of this piece. The standard gives the bow tie two jobs, analysis and communication, and most organisations have kept only the second. A bow tie is a test you run on your controls. The picture is what the test leaves behind.

The wallpaper problem

Here is the version that actually gets produced in a lot of organisations. The risk assessment is done, the register rows exist, and someone draws a bow tie for the board pack because bow ties look rigorous. Causes on the left, consequences on the right, and a reassuring picket fence of barriers across every line.

You can recognise this version by what is missing. No control on the diagram carries an effectiveness judgement, so the picket fence reads as uniformly solid. Nothing distinguishes a control that exists from one that is planned, or half-implemented, or was last tested three years ago. And nothing changed because the diagram was drawn: no control owner got a question, no gap got a treatment, no rating moved. The diagram decorated a conclusion the team had already reached.

That is wallpaper. It is not worthless, because the picture genuinely is a good communication device, and the standard says so: it is "simple to understand and gives a clear pictorial representation of an event and its causes and consequences". But communication is the by-product. If the diagram never made anyone uncomfortable, the technique was not applied.

What the technique is actually for

The standard's use clause is blunt about the job. A bow tie "is used when assessing controls 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".

Read as a procedure rather than a description, that sentence generates the workshop. For every pathway on the left: what stops this cause reaching the event? Not "what have we written down", but which named controls, owned by whom, working how well. For every pathway on the right: once the event has happened, what limits this consequence? And for every control on either side: what would make this control fail, and is anything watching for that?

The last question is the one that earns the technique its keep, because it is the one a register row cannot hold. The standard's drawing steps include two elements that rarely survive into the wallpaper version: escalation factors, "factors that might cause the controls to fail", drawn with their own controls, and management functions "which support controls (such as training and inspection)", linked to the controls they support. A barrier diagram with escalation factors on it stops being a reassurance document. The training that lapsed, the inspection regime that quietly stopped, the single person who administers the critical system: they appear on the page, attached to the exact controls they undermine.

The honesty mechanism is effectiveness

The fastest way to turn a poster into an analysis is to force an effectiveness judgement onto every control, on a scale, in the room, with the control owner present.

The uncomfortable pattern that emerges is nearly always the same one: the pathways that matter most are anchored by the controls rated weakest. Awareness training rated partially effective. A patching process rated partially effective. A crisis comms plan nobody has exercised. The picket fence was never uniform, and rating it says so in a way everyone in the room has to look at. That, not the tidy final image, is the deliverable. The residual rating you carry out of the workshop should be arguable from the effectiveness spread on the page, and if it is not, one of them is wrong.

When the bow tie is the right tool

The standard gives it a specific slot, and the slot is worth quoting because it prevents both overuse and underuse. The 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". One line in a register: too simple to need it. A system safety case with interdependent failure logic: too complex for it. The wide middle band, one serious event with several credible causes and several consequences that matter: exactly it. The standard adds that it "is particularly used for analysing events with more serious consequences", which is where the investment of a workshop pays.

Two more properties from the use clause deserve more attention than they get. It works "proactively to consider potential events and also retrospectively to model events that have already occurred": a bow tie of an incident that actually happened, drawn against the bow tie you would have drawn beforehand, is a controls audit with nowhere to hide. And it can be used "for desirable consequences as well as undesirable ones", which almost nobody does and which the opportunity side of your register is quietly waiting for.

What it cannot do

The same clause that defines the technique limits it, and the limits are real. A bow tie "cannot depict a situation where pathways from causes to the event are not independent", the situations where a fault tree would carry AND gates: two things that must both happen. If your event needs combination logic, you need the fault tree.

And the standard is careful about numbers. Some quantification is possible "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", but "in many situations, pathways and barriers are not independent, and controls may be procedural and their effectiveness uncertain". In other words: the diagram is a map of mechanism, not a calculation. When you want the calculation, the standard points you at fault trees, event trees or LOPA, and for cost exposure you are better served by a Monte Carlo model of the event. The bow tie's honest output is the standard's stated one: the pathways, "the controls in place, and the factors that might lead to control failure".

Run it as a test

The practical version, next time a serious risk crosses your desk: one event, one workshop, the people who own the controls in the room. Draw the pathways, put every control where it acts, and rate every one of them for effectiveness before anyone is allowed to admire the picture. Then read the weakest ratings on the busiest pathways aloud. That list is your treatment plan, and it existed nowhere before the diagram forced it out.

If you want to try the method without procurement getting involved, Beau-Tie is a free browser-based bow tie editor built around exactly this discipline: typed controls, effectiveness ratings on a five-point scale, existing versus planned status, and residual, target and appetite ratings on a matrix, with the diagram exportable once it has done its real job. There are ten complete templates to start from, and the knowledge base has a fuller introduction to the technique with the ISO references attached.

The picture at the end will still look good in the pack. It will just have earned it.