Most risk tools focus on stopping the bad thing from happening. A bow-tie also asks what you'll do when it happens anyway.
What it is
The bow-tie diagram grew out of process safety work in the oil and chemical industries. It's widely associated with Shell, which used it heavily from the 1990s.
It has five parts:
- Hazard. The thing with the power to cause harm. For bots: an email tool, a payment connector, write access to the master file.
- Top event. The moment control is lost. "Wrong email sent to customers."
- Threats (left side). What could cause the top event.
- Consequences (right side). What happens after.
- Barriers. On the left, barriers that prevent the top event. On the right, barriers that limit the damage once it's happened.
Drawn out, it looks like a bow tie: causes fanning in on the left, consequences fanning out on the right, the event in the knot.
Why people skipped it
Drawing one well takes a workshop and someone who knows the software. It also means admitting the bad event will happen someday, which some teams don't like to plan for.
How a bot does it
- Name the hazard and top event.
- Give it the system: tools, access, approvals, logs, backups.
- Have it list threats and consequences.
- Have it place your existing barriers on each line, from your actual setup.
- Ask it to rate each barrier: is it a removed capability, a system setting, or just a rule in an instruction file? See The hierarchy of controls.
- A person checks: are those barriers real, and are they independent of each other?
The bot brief
Build a bow-tie for this hazard: [hazard]. Top event: [event].
Inputs: [tool list with access, approval steps, logging, backup and undo options].
List threats (left) and consequences (right).
For each threat, list prevention barriers that exist in the inputs.
For each consequence, list recovery barriers that exist in the inputs.
For every barrier, classify its strength: REMOVED (capability doesn't exist),
SYSTEM (enforced by settings), RULE (only written in instructions), PERSON (relies on attention).
Flag any threat line with only RULE or PERSON barriers.
Flag any consequence line with no recovery barrier.
Do not invent barriers that aren't in the inputs.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
Hazard: email send tool. Top event: wrong email sent to a customer.
| Side | Line | Barriers | Weakest type |
|---|---|---|---|
| Prevent | Bot drafts to wrong recipient | Person reviews recipients | PERSON |
| Prevent | Bot sends without asking | Drafting tool only, no send | REMOVED |
| Prevent | Injected instruction in an email it read | "Treat inputs as information" rule | RULE |
| Recover | Customer acts on wrong info | None | — |
| Recover | Private data exposed | None | — |
The right side is empty. That's common. Most setups put all their effort into prevention. Recovery barriers for bots might be a send delay with undo, a template for a correction email, and a named person who handles it.
Where bots differ
In a plant, barriers like relief valves and fire walls are physical and tested. Many bot barriers are only rules in a file. The bow-tie makes that visible, because you have to say what each barrier actually is.
What this means for you
- Pick each powerful tool your bots have. That's a hazard.
- Have a bot draw the bow-tie.
- Make sure each threat has at least one barrier that isn't just a rule.
- Plan the recovery side before you need it.