Bow Tie Analysis for Cyber Risk: Mapping Threats, Controls and Consequences

Most cyber risk registers list a risk, a score and a handful of controls, but they cannot show which control stops which attack path, which controls only limit the damage, or what happens when one of them quietly fails. Bow tie analysis fixes that by drawing one central loss-of-control event with the threats that lead to it on the left, the consequences that follow on the right, and every barrier placed on the specific path it interrupts. The method comes from process safety, where it is a mature, well-documented technique, and it transfers to cyber risk with a few important adjustments for intelligent adversaries. This guide explains the terminology, how to build a cyber bow tie step by step, how to judge whether a control is a real barrier, how bow ties compare with fault trees and event trees, and how to use the result in reporting. It is for risk managers, security architects and CISOs who already run a risk process, such as one based on the ISO 31000 Risk Management Guide, and want a sharper view of their controls.

Key takeaways

• One event, two sides. A bow tie centres on a single top event, the moment control is lost, with prevention barriers on the threat side and mitigation barriers on the consequence side.
• Barriers must meet a test. The CCPS and Energy Institute approach treats a barrier as effective, independent and auditable; anything that only supports a barrier is a degradation control, not a barrier.
• Adversaries break independence. In cyber, two barriers that look separate can share an identity store, a management network or an admin account, so a single compromise can defeat both: check shared dependencies explicitly.
• Bow ties complement quantification. Bow ties are qualitative and show structure; fault trees, event trees and FAIR-style models add probability and loss figures where a decision needs them.
• The value is in the review. A bow tie earns its keep when each barrier has an owner, a test and a health status that feeds board reporting.

What a bow tie is and where it comes from

IEC 31010:2019, the international catalogue of risk assessment techniques that supports ISO 31000, describes the bow tie as a simple, diagrammatic way of describing and analysing the pathways of a risk. The shape gives it the name: causes fan in from the left to a central knot and consequences fan out to the right. The method is most developed in process safety. In 2018 the Center for Chemical Process Safety (CCPS) and the Energy Institute published Bow Ties in Risk Management: A Concept Book for Process Safety to set a common approach, after practitioners found inconsistent terminology, too many claimed barriers and over-complex scoring.

The cyber adjustment is in the starting point. A safety bow tie starts from a hazard and treats causes as random failures. A security bow tie starts from a threat, and the causes are deliberate acts by people who adapt when a barrier is in their way. Risktec (TÜV Rheinland) makes this distinction in its guidance on security bow ties and notes that bow ties can be built at several levels, from a national or sector view down to a single site, with each level linked to the one above and below. In cyber terms, that means an enterprise bow tie for "loss of control of the production identity plane" can link down to system bow ties for the identity provider and the privileged access tool.

The parts of a cyber bow tie

Consistent terms matter more than diagram style. The table uses the CCPS and Energy Institute vocabulary, as summarised in the IChemE Hazards 28 paper that introduced the book, with a cyber example for each element.

The top event is the hardest part to get right. If it is too early ("a phishing email arrives") the right side fills with every possible attack; if it is too late ("data is sold online") the left side fills with consequences pretending to be threats. A good cyber top event describes a loss of control over something specific: an identity, a system, a data set or a process.

Barrier quality: the test most cyber bow ties fail

The IChemE paper sets out three criteria for a barrier: it must be effective (able on its own to stop the threat or limit the consequence), independent (separate from the threat and from other barriers on the same line) and auditable (its performance can be checked). It also notes that an active barrier needs detect, decide and act elements, and that a single component is often not a complete barrier. In process safety, a valve alone is not a barrier; the sensor, logic and valve together are.

The cyber equivalents are direct:

• Detect, decide, act: an EDR alert is a detection element only. The barrier is the alert, the triage decision within a defined time and the containment action. If nobody acts out of hours, the barrier does not exist out of hours.
• Effective: "security awareness training" rarely stops a phishing threat on its own, so it is better recorded as a degradation control for the MFA barrier than as a barrier. Phishing-resistant MFA, by contrast, can stop credential phishing on its own (ATT&CK mitigation M1032 Multi-factor Authentication, D3FEND D3-MFA).
• Independent: two barriers that both depend on Active Directory are not independent against a threat that compromises Active Directory. A 2026 paper applying HAZOP and bow tie to hydropower control systems found exactly this: barriers that appear independent can share network infrastructure that a single attacker could compromise, which undermines the defence-in-depth assumption.
• Auditable: a barrier needs a test you can run and evidence you can show, such as a conditional access report, a restore test record or a configuration compliance export.

The same paper suggests typically one to five barriers per threat line on the prevention side and one to three on the mitigation side, with five as a practical maximum. A threat line with ten "barriers" usually mixes barriers, degradation controls and wishes.

Common shared dependencies to check

Non-human identities appear in almost every cyber bow tie as a degradation factor, because service accounts and API keys often bypass the MFA and conditional access barriers drawn for humans. See the Agentic AI Risk Assessment Template for assessing machine and agent identities in the same way.

Building a cyber bow tie step by step

1. Choose the scope and the hazard. Pick one asset, service or process that matters to the business, ideally a top risk already in the register. Start with a scenario from the Cyber Risk Scenario Library Guide if you have one.
2. Define one top event. Phrase it as a loss of control, for example "an unauthorised party gains administrative control of the payment platform".
3. List threats. Use threat intelligence and incident history. Express each as a distinct path and, where useful, map it to ATT&CK: T1566 Phishing, T1190 Exploit Public-Facing Application, T1078 Valid Accounts, T1133 External Remote Services, T1195 Supply Chain Compromise. Keep three to eight threats; merge near duplicates.
4. List consequences. Describe outcomes the business recognises: service outage, data theft (T1567 Exfiltration Over Web Service), encryption (T1486 Data Encrypted for Impact), destruction of recovery capability (T1490 Inhibit System Recovery), regulatory and contractual impact. Rank them by severity against your impact scale.
5. Place prevention barriers. For each threat line, list only controls that meet the barrier test, in the order an attacker would meet them.
6. Place mitigation barriers. For each consequence, list detection, containment and recovery barriers, again with detect, decide and act present.
7. Add degradation factors and controls. For each barrier, ask how it fails: exclusions, unpatched components, shared credentials, staff absence, vendor outage. Add the controls that keep it working.
8. Assign owners and evidence. Every barrier and degradation control gets an owner, a test frequency and a source of evidence.
9. Rate barrier health. Use a simple scale (for example, working, degraded, failed or untested) based on the latest evidence, not opinion.
10. Review in a workshop. Walk the diagram with system owners, operations and incident responders. Risktec stresses keeping the method simple so people across the organisation can contribute; that is where hidden dependencies surface.

A first bow tie for a well-understood risk takes one or two workshops. Resist the urge to draw the whole enterprise at once: five strong bow ties for top risks are more useful than fifty weak ones.

Worked example: ransomware against a core service

The table summarises a bow tie for a top event of "attacker gains domain administrator control of the production Windows estate". It is an illustration, not a complete control set.

The diagram makes one weakness obvious: the backup barrier and the prevention barriers all depend on the same domain. If the top event happens, the mitigation side shares the failure. That single insight is often worth more than the rest of the exercise, and it leads straight to an investment case for an isolated backup administration path.

Bow tie, fault tree and event tree compared

IEC 31010:2019 catalogues many techniques; the three most often confused with each other are below. In broad terms, the left side of a bow tie is a simplified fault tree and the right side a simplified event tree, without the Boolean logic or probabilities.

Choose a bow tie when the question is "are our controls on the right paths and are they working?" Choose a fault tree or attack tree when the question is "which combinations of failures get an attacker in?" Choose quantification when the question is "how much is this worth spending?" Many teams use the bow tie to agree the structure and then feed barrier health into a quantified model, as described in the FAIR Model and Open FAIR Standard Guide and the FAIR-CAM Controls Analytics Model Guide.

Using bow ties in the risk process

• Risk register: link each top risk entry to its bow tie, and record the number of barriers per line and their health in the register. See the Risk Register Template.
• Risk assessment: the bow tie provides the threat event and control analysis that NIST SP 800-30 Rev. 1 style assessments need, and makes the likelihood judgement traceable to specific barriers. See the NIST SP 800-30 Risk Assessment Guide.
• Control assurance: plan audits and control tests from the barrier list, starting with barriers that protect against the most severe consequences.
• Incident learning: after an incident, mark which barriers failed and why. Recurring degradation factors show where to invest.
• OT and safety: in industrial sites, a cyber bow tie can link to the existing safety bow ties, which makes cyber causes of safety events visible. See the IEC 62443-3-2 OT Risk Assessment Guide.

Small organisations can draw a bow tie on a whiteboard for their two or three most serious risks and use it to decide where the next control spend goes. Large organisations benefit from a standard template, a barrier library with consistent names and dedicated software, so that barrier health can be rolled up across many bow ties.

Measuring whether it works

A bow tie is only as good as the barrier evidence behind it. Track:

• Barrier test coverage: percentage of barriers on top-risk bow ties with a test performed in the last review period.
• Barrier health: number of barriers rated degraded or failed, and the age of each finding.
• Single-barrier lines: threat or consequence lines protected by one barrier only, especially for severe consequences.
• Shared dependency count: lines where all barriers depend on one system or identity.
• Incident barrier analysis: share of incidents and near misses where the failing barrier was already rated degraded.

Common failure patterns

• Too many barriers. Policies, training and "monitoring" listed as barriers inflate confidence. Apply the effective, independent and auditable test and move the rest to degradation controls.
• Top event in the wrong place. Choosing a top event that is really a threat or a consequence makes the diagram unbalanced and hard to use.
• Ignoring shared dependencies. Barriers that rely on the same directory, network or vendor are drawn as independent. In the Caesars Entertainment breach, social engineering of an IT support provider opened a path that went round controls designed for direct attacks on users, which is the kind of line a bow tie should draw explicitly.
• Machine identities left off. Service accounts and API keys appear as threat paths that bypass human-focused barriers but are rarely drawn.
• Drawn once, never updated. Bow ties built for an audit and then shelved show barriers that no longer exist. Tie the review to the risk register cycle.
• Scoring complexity. Elaborate barrier scoring schemes create debate about numbers instead of fixes; keep health ratings simple and evidence based.

Framework mapping

Practitioner checklist

• Pick three to five top risks and build one bow tie each before expanding.
• Write every top event as a specific loss of control, not an attack step or an outcome.
• Apply the effective, independent and auditable test to every claimed barrier.
• Confirm each active barrier has detect, decide and act elements, including out of hours.
• List shared dependencies for each line and fix lines where all barriers share one.
• Include non-human identities as threat paths and degradation factors.
• Give every barrier an owner, a test and a health rating from evidence.
• Link bow ties to the risk register and review them on the same cycle.
• Feed barrier health into quantification where investment decisions need figures.

Standards and references

• ISO and IEC: IEC 31010:2019 Risk management, Risk assessment techniques
• CCPS and Energy Institute: Bow Ties in Risk Management, A Concept Book for Process Safety
• IChemE Hazards 28: Bow Ties in Risk Management, a common approach
• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• MITRE: ATT&CK Enterprise Matrix
• Risktec (TÜV Rheinland): Security risk analysis using bowties
• arXiv: Assessing Cyber Risks in Hydropower Systems Through HAZOP and Bow-Tie Analysis

Related NHI Mgmt Group resources: ISO 31000 Risk Management Guide · Cyber Risk Quantification Guide · Cyber Risk Scenario Library Guide · Risk Register Template