If your bow-tie workshops produce tidy diagrams but few useful actions, check the event definition, evidence and people in the room. A good session exposes uncertain assumptions and gives control owners something specific to verify.
Bow-tie workshop mistakes in how the session is set up (1-4)
- The focal event is too broad. "Cyber incident" or "security breach" as a focal event produces a diagram with causes and consequences from a dozen unrelated scenarios tangled together, none of them examined properly. A focal event should be specific enough that everyone in the room pictures the same moment: "ransomware executes on a finance department workstation," not "cyber incident."
- The wrong people are in the room. A bow-tie built by a risk manager alone, or by managers without the people who actually operate the controls, produces barriers that look plausible on paper and fall apart on contact with reality. The person who actually checks the hot work permits, not just the person who wrote the policy, needs to be at the table.
- No time boundary, so the session sprawls. Without a fixed time allocation per focal event, workshops either run out of time before the consequence side is properly examined, or spend an hour arguing over wording on the cause side. Set a time budget per focal event before the session starts and hold to it, even if it means parking a good debate for a follow-up.
- One focal event tries to do the work of five. Sometimes the focal event is specific enough, but the group keeps trying to also capture a related-but-different scenario within the same diagram because it feels efficient. It is not. A second focal event that shares some causes with the first is still a second bow-tie.
Mistakes in how the analysis is done (5-8)
- Barriers are policies, not practices. "We have an access control policy" is not a barrier. A barrier is the specific, observable thing that happens: "the card reader denies entry outside rostered hours, and security reviews the denied-attempt log weekly." If a barrier cannot be described as something a named person or system actually does, it is not ready to go on the diagram.
- Causes are too vague to attach a barrier to. "Human error" or "poor security culture" as a cause cannot have a specific barrier drawn against it, because it is not a specific thing. Push for the actual failure mode: tailgating through a controlled door, a misconfigured firewall rule, a shared password. A vague cause produces a vague, unfalsifiable barrier.
- Escalation factors are skipped. Every barrier has a condition that weakens it — inexperienced staff, a maintenance backlog, a busy period when procedures get shortcut. Skipping escalation factors leaves every barrier looking equally solid on the page, which is never true in practice, and hides exactly the information the exercise exists to surface.
- Shared weaknesses go unnoticed. Two barriers that look independent can share a single point of failure. If your after-hours access control and your visitor sign-in process both rely on the same untrained night-shift guard noticing something is wrong, you have one barrier drawn twice, not two layers of defence. A workshop that does not ask "what do these barriers have in common" will miss this every time.
Mistakes in how the room behaves and what happens after (9-12)
- Nobody challenges a stated barrier. The most common way a workshop wastes its own time is politeness. Someone states a barrier, everyone nods, and the session moves on without anyone asking "does that actually happen, every time, or did it happen once during the audit?" A facilitator's job includes asking that question out loud, deliberately, for every barrier that sounds too clean.
- The session runs as a lecture, not a workshop. If one person is drawing the diagram and everyone else is watching, you have a presentation, not a bow-tie workshop. The value comes from live disagreement about whether a barrier really works — that only happens if participants are actively contributing, not confirming.
- The workshop stops at the diagram. A finished bow-tie is a record of a conversation at one point in time, not a control. If nobody is assigned to check that the stated barriers still exist and still work six months later, the diagram quietly goes stale while still being treated as current assurance.
- The output is never reviewed by anyone outside the room. A bow-tie produced entirely inside one team, and never checked by someone with no stake in defending the existing controls, tends to reflect what the team wants to believe about its own controls rather than what is actually true. This matters as much for reviewing a bow-tie submitted by a contractor or partner as for your own — a diagram that reads well is not the same as one that was pressure-tested.
Worked example: a contractor's bow-tie submission
A fictional three-site logistics firm, Coastal Freight Logistics, receives a bow-tie diagram from a security contractor bidding for a site access control upgrade. The diagram lists "24/7 monitored CCTV" as a barrier against "unauthorised after-hours entry." On review, the reviewer asks three questions that a proper checklist would prompt automatically: Who monitors it, and during what hours? What is the documented response time when an alert fires? Has that response actually been tested, or only installed?
The contractor's answer reveals the monitoring is unmonitored outside business hours, with recorded footage reviewed only after an incident is reported by someone else. The barrier as originally stated — "24/7 monitored CCTV" — was not false exactly, but it described the equipment, not the control. That distinction is the entire reason a structured review checklist exists rather than trusting the diagram to speak for itself.
Common mistakes when reviewing someone else's bow-tie
- Accepting equipment as a control. A camera, a fence or a firewall is not a barrier by itself. The barrier is what happens because of it.
- Not asking for evidence of last testing. A barrier that has never been tested is an assumption, not a control.
- Reviewing the diagram in isolation from the site. A bow-tie that looks internally consistent can still misdescribe how the site actually operates if nobody checks it against reality.
- Accepting vague causes from a submitter. If a contractor's diagram lists "external threat" as a cause, push back for specifics before accepting any barrier that claims to address it.
- Treating a polished diagram as a proxy for a well-run workshop. Formatting quality and analytical rigour are unrelated.
Facilitate and review with the right kit
The Bow-Tie Field Kit is a facilitator's guide covering these twelve failure modes in more depth, session logistics, facilitation notes and a 26-point review checklist for assessing submissions from contractors, partners or regulators. For getting the room and materials right before the session starts, see Free Security Risk Management Wall Chart for Your Project Room. If scope disputes are part of why your workshops sprawl, Security Risk Assessment Scope Creep: Five Clauses That Prevent It addresses that directly, and where a bow-tie submission comes from a supplier, pair the review checklist with Secure Supply Chain Policy Template (Free).
Download The Bow-Tie Field Kit and run your next workshop, or your next contractor review, against a checklist instead of a hunch.