Learn how to apply Bow Tie in engineering to connect threats, the top event, consequences, preventive and mitigating barriers, and degradation factors.
Check it out!
Bow Tie is a risk analysis technique that represents, in a single visual structure, how specific threats can lead to loss of control over a hazard and what consequences may occur if that critical event materializes. The method connects threats, the top event, consequences, and barriers, making it possible to assess not only “how critical” a risk is, but primarily which controls must prevent its occurrence and which controls must limit its effects.
In engineering projects, Bow Tie is particularly useful when a risk requires clarity regarding technical, administrative, and operational barriers. It does not replace HAZOP, FMEA, FTA, risk matrices, or quantitative analysis. Its strength lies in making the causal logic and control architecture of a critical scenario explicit, supporting design decisions, safeguard verification, assignment of responsibilities, commissioning, and residual-risk monitoring.
What Is Bow Tie Analysis
The name Bow Tie comes from the shape of the diagram. On the left are the threats that may lead to the critical event; at the center is the top event; and on the right are the possible consequences. Preventive barriers are placed between threats and the top event. Mitigating barriers appear between the top event and the consequences.
Correct use of the method requires separating concepts that are often mixed together. The hazard is the source, situation, or condition with the potential to cause harm. The top event represents loss of control over that hazard. Threats are conditions or events capable of causing that loss of control. Consequences are the plausible effects that may develop after the top event.
This distinction prevents vague diagrams. If the center of the Bow Tie contains wording such as “high electrical risk” or “major failure,” the analysis loses precision. The top event should describe an observable change of state, for example: loss of insulation in an energized circuit, loss of redundant power supply, equipment overpressure, loss of containment, unavailability of a critical system, or uncontrolled release of energy.
When risk depends on multiple barriers and disciplines, the value lies in turning the Bow Tie into governance: scenario, controls, owners, evidence, and residual risk must remain connected to project management.
Threat → Top Event → Consequence Logic
The Bow Tie structure combines two different questions. On the left, the team investigates what can cause loss of control. On the right, it investigates what can happen after control has been lost. This separation is valuable because prevention and mitigation are not the same thing.
A preventive barrier seeks to interrupt the causal chain before the top event. A mitigating barrier acts after the top event, reducing the probability, severity, or propagation of specific consequences.
This sequence improves risk-treatment quality because it prevents the team from confusing preventive action with contingency response. It also helps identify cases in which many controls exist on the left side but there is almost no capacity to limit consequences if prevention fails — or the reverse.
What Should Be at the Center of a Bow Tie
The top event is the pivotal point of the method. It should not be so broad that it combines scenarios with no causal relationship, nor so specific that the diagram becomes an operational sequence that is impossible to manage.
A good top event describes a relevant loss of control over a hazard. In electrical systems, it may be unintended energization of a part that should be de-energized. In Data Centers, it may be the simultaneous loss of the sources supporting a given critical load. In pressurized systems, it may be loss of containment. In telecommunications infrastructure, it may be loss of backbone connectivity with no available alternative path.
The team should be able to answer four questions about the top event:
- what prior condition must exist for the scenario to be relevant;
- which threats can cause the loss of control;
- which barriers prevent each threat from reaching the top event;
- which consequences may develop if the top event occurs.
When these answers are unclear, the problem is usually in the scenario formulation rather than in the tool.
Threats: Causes That Can Lead to the Top Event
A threat is not synonymous with a root cause. In a Bow Tie, a threat is an event, condition, or mechanism that can initiate the sequence leading to the top event. A threat may itself have underlying causes that need to be investigated through RCA, 5 Whys, FTA, or another technique.
In a scenario involving loss of power supply to a critical system, threats may include failure of the normal supply, automatic-transfer failure, generator unavailability, simultaneous maintenance on redundant elements, configuration error, improper protection operation, or a common-cause failure affecting two apparently independent paths.
The value of Bow Tie becomes evident when the team goes beyond listing threats and asks: what barrier exists against each of them, and how do we know that this barrier is available and effective?
Preventive Barriers
Preventive barriers act before the top event. They reduce the probability that a threat will progress to loss of control. In engineering, they may take different forms:
- design barriers: redundancy, physical segregation, sizing, interlocks, protection, fail-safe design, and material selection;
- instrumented barriers: detection, control logic, permissives, trips, and protection systems;
- physical barriers: containment, separation, isolation, and mechanical protection;
- procedural barriers: work permits, checklists, operating sequences, lockout and tagout;
- organizational barriers: segregation of duties, independent double-checks, technical authority, and approval levels;
- assurance barriers: inspection, testing, FAT, SAT, commissioning, audits, and independent verification.
A list of controls alone does not demonstrate that effective barriers exist. The analysis should verify whether the control is specific to the threat, has been implemented, has adequate performance, is sufficiently independent from other relevant safeguards, and can be tested or evidenced.
Mitigating Barriers
Mitigating barriers act after the top event. Their purpose is to prevent the situation from developing into specific consequences or to reduce the magnitude of the effects.
Examples include detection and alarm systems, secondary containment, fire protection, alternative routes, emergency shutdown, recovery redundancy, response procedures, contingency plans, isolation capability, strategic spare-parts inventory, and data recovery.
A mitigating barrier should not be counted as prevention if it only acts after the top event has already occurred. This distinction is especially important in availability and continuity analyses, where an architecture may appear “redundant” while relying on mechanisms that only reduce recovery time rather than the probability of unavailability.
Barrier Performance: Existence Is Not Effectiveness
One of the most common mistakes in Bow Tie analysis is assuming that the mere presence of a control in the design means the barrier is reliable. In risk management, a barrier must be treated as a function that needs to be available when demanded.
The analysis should therefore seek evidence of performance. Depending on the case, this may involve criteria such as:
- clearly defined function;
- measurable performance requirement;
- sufficient independence from common-cause failures;
- operational availability;
- testability;
- defined maintenance and inspection;
- responsibility for barrier integrity;
- commissioning and acceptance evidence;
- degradation monitoring;
- management of bypass, inhibition, or temporary unavailability.
This approach connects Bow Tie with asset management, reliability, QA/QC, and commissioning. The barrier ceases to be merely a rectangle in the diagram and becomes a function with associated requirements and evidence.
Critical barriers are defensible only when requirements, acceptance criteria, tests, and evidence demonstrate that the intended function was actually implemented and remains verifiable throughout the life cycle.
Barrier Degradation Factors
A barrier may exist and still fail when called upon. Bow Tie can be deepened by identifying degradation factors, that is, conditions that reduce barrier effectiveness.
Consider a barrier based on periodic inspection. Its effectiveness may be degraded by an inadequate procedure, insufficient frequency, uncalibrated instruments, an unqualified team, incomplete records, or failure to address identified anomalies. Specific degradation controls may exist for each relevant factor.
This level of analysis is useful for distinguishing a “designed barrier” from an “assured barrier.” In complex projects, much residual risk results less from the absence of safeguards than from the progressive loss of their integrity throughout the life cycle.
How to Build a Bow Tie Step by Step
Construction should start with the scenario, not with the diagramming tool.
1. Define the Scope and Objectives
Determine which system, phase, process, or decision will be analyzed. A construction Bow Tie may have different controls from an operations Bow Tie. The affected objectives should also be clear: safety, availability, schedule, cost, performance, environment, continuity, or compliance.
2. Identify the Hazard and Formulate the Top Event
Describe the source of risk and the loss of control that will be placed at the center. Test the wording by asking whether the top event occurs before the consequences the team intends to analyze.
3. Identify Plausible Threats
List mechanisms capable of leading to the top event. Avoid duplicating the same threat under different wording and do not turn missing controls into threats. “Lack of maintenance” may be a cause of barrier degradation, while “equipment failure due to undetected degradation” may be a more appropriate threat for the scenario.
4. Identify Preventive Barriers
For each threat, determine what actually interrupts the sequence. Record real controls rather than generic intentions such as “team attention.”
5. Identify Consequences
Assess different effects. The same top event may produce safety consequences, unavailability, asset damage, financial loss, and contractual impact. Consequences, however, must remain causally plausible.
6. Identify Mitigating Barriers
Associate controls that act after the top event and before each consequence. Verify whether the main escalation paths are covered.
7. Analyze Barrier Degradation and Assurance
Determine how the organization confirms the integrity of each barrier and which factors may reduce its effectiveness.
8. Define Responsibilities and Actions
The diagram should produce decisions. Critical barriers without an owner, evidence, or verification plan should generate traceable actions in the risk register, action plan, inspection and test plan, or corresponding management system.
Example: Loss of Power to a Critical Load
Consider a system in which a particular load must remain energized. The hazard may be the dependence on electrical power to sustain an essential function. The top event may be defined as loss of power to the critical load beyond the allowable autonomy time of the immediately available stage.
Possible threats include failure of the normal feeder, ATS failure, generator-start failure, simultaneous source unavailability during maintenance, and a common-cause failure associated with a shared switchboard.
Preventive barriers may include redundant architecture, independent supply paths, selective protection, interlocks, N+1 redundancy, condition-based maintenance, periodic testing, and control of simultaneous interventions.
After the top event, mitigating barriers may include UPS capacity with available autonomy, transfer to an alternative path, controlled load shedding, a contingency plan, prioritized recovery, and emergency operating procedures.
Consequences may include system unavailability, data loss, process interruption, SLA breach, operational damage, and the need for a safe shutdown.
The example shows why Bow Tie should not be treated as a “pretty matrix.” It forces the team to demonstrate how each risk path is controlled.
Bow Tie vs. Risk Matrix
The matrix classifies and prioritizes. Bow Tie explains the scenario and its barriers. The two techniques can be complementary.
A matrix may indicate that “loss of critical power” is a high-level risk. Bow Tie shows which threats contribute to that event, which barriers exist, which may fail, and which consequences remain possible. Once additional controls are defined, residual risk can be reassessed in the matrix.
This integration improves traceability between classification and treatment. Instead of lowering a score simply because “actions were planned,” the team can identify which barriers were actually implemented and verified.
Bow Tie vs. HAZOP
HAZOP is a structured technique for studying deviations, traditionally performed by a multidisciplinary team using guide words and systematic documentation. Bow Tie is a scenario- and barrier-oriented representation.
A HAZOP may identify a relevant deviation, its causes, consequences, and safeguards. Selected critical scenarios identified through HAZOP can then be developed into Bow Ties to deepen the barrier architecture, degradation factors, responsibilities, and assurance.
There is no need to turn every HAZOP row into a Bow Tie. Use should be selective, prioritizing events that require clear communication and ongoing control management.
Bow Tie vs. FMEA and FMECA
FMEA starts from failure modes of components, functions, or processes and analyzes their effects and causes. FMECA adds criticality treatment. Bow Tie starts from a top event and organizes threats, consequences, and barriers.
FMEA tends to be effective for exploring how elements may fail. Bow Tie is effective for demonstrating how different mechanisms converge on a critical event and how the organization controls the sequences before and after that event.
In complex systems, FMEA can provide threats and barrier failures for a Bow Tie. The reverse is also useful: Bow Tie can show which barriers deserve a more detailed FMEA because they are critical to controlling the scenario.
Bow Tie vs. FTA
FTA, or Fault Tree Analysis, uses deductive logic to decompose combinations of events that lead to a top event. It is particularly useful when the objective is to understand AND/OR relationships, combined failures and, when adequate data are available, quantify probabilities.
The left side of a Bow Tie may resemble a causal tree, but it does not replace the formal logical structure of an FTA. When a top event depends on complex combinations, FTA can deepen causality while Bow Tie retains the broader view of barriers and consequences.
Bow Tie vs. Contingency Plan
A contingency plan addresses the organized response to previously analyzed scenarios. In a Bow Tie, several contingency measures appear on the right side as mitigating barriers or recovery mechanisms.
The integration is direct: critical consequences and escalation conditions identified in the Bow Tie help define triggers, resources, roles, communication, and recovery criteria for the contingency plan.
How to Connect Bow Tie to the Risk Register
Bow Tie should not exist in isolation. For each relevant scenario, the risk register can store a reference to the diagram, risk owner, inherent and residual classification, critical barriers, open actions, deadlines, indicators, and verification evidence.
The risk register remains the governance instrument for the risk portfolio, while Bow Tie deepens selected scenarios. This separation prevents the risk register from becoming excessively detailed while also preventing the diagram from being left without an owner or follow-up.
Bow Tie During Design, Construction, and Commissioning
The technique can shift focus throughout the life cycle.
Design
During design, Bow Tie helps test whether requirements and architectural decisions actually create adequate barriers. It is useful for discussing redundancy, segregation, interlocks, fail-safe criteria, protection, and independence.
Procurement
When procuring equipment and systems, barriers may depend on performance requirements, documentation, factory testing, inspection, supplier qualification, and support capability. The diagram helps show which contractual requirements sustain critical controls.
Construction
During implementation, the focus shifts to temporary barriers and transition risks: partial energization, simultaneous work, interfaces, temporary bypasses, field changes, and provisional conditions.
Commissioning
During commissioning, Bow Tie can guide barrier verification. Interlocks, alarms, redundancies, failover, protection, control logic, and response procedures can be tested against the scenarios that justified their existence.
Operations
In operations, the analysis depends on integrity management, inspection, maintenance, alarms, training, management of change, and response to anomalies.
Indicators for Critical Barriers
Some scenarios require the organization to monitor barrier health. Possible indicators include availability of protection systems, percentage of tests completed on time, number of active bypasses, failures on demand, outstanding critical-maintenance items, overdue inspections, inhibited alarms, and overdue risk actions.
The objective is not to create dozens of indicators, but to identify signals that reveal degradation before the risk materializes. For critical barriers, a leading indicator is often more valuable than merely recording incidents after they occur.
When Bow Tie reveals fragile dependencies, barriers without evidence, or high residual risks, the discussion must move from the diagram into the technical decision: revise architecture, requirements, tests, responsibilities, or the treatment strategy.
Support critical decisions with Engineering Technical Consulting →
Common Mistakes When Applying Bow Tie
Putting the Consequence at the Center
If the top event is “fire with total loss,” threats and barriers become mixed together. The center should represent the loss of control that precedes the final consequence.
Treating Generic Procedures as Robust Barriers
“Trained team” or “follow procedure” do not, by themselves, demonstrate barrier function, independence, and effectiveness. It is necessary to understand how the control interrupts the sequence and how its integrity is verified.
Counting the Same Control Multiple Times
A single function dependent on the same sensor, logic, power source, or person should not be treated as multiple independent barriers simply because it appears in different documents.
Ignoring Common-Cause Failures
Apparent redundancy may share power, communications, environment, software, maintenance, or procedures. Bow Tie should expose dependencies capable of degrading several barriers simultaneously.
Not Reviewing the Diagram After Changes
Changes to design, supplier, logic, operations, procedures, or architecture may invalidate assumptions. Bow Tie should follow management of change and the risk register.
When Bow Tie Is Worth Using
Bow Tie tends to generate the most value when the risk is significant enough to require understanding of barriers and communication across disciplines. It is especially appropriate for scenarios with multiple threats, different consequences, a need to demonstrate controls, and clear responsibility for safeguards.
For simple, low-exposure risks, a matrix and action plan may be sufficient. For scenarios that depend on complex logical combinations or require quantification, FTA, Event Tree, Monte Carlo, or other techniques may be more appropriate.
Selection should start from the decision question, not from preference for a particular tool.
Final Considerations
Bow Tie turns the discussion of risk into a discussion of demonstrable control. The technique organizes threats, loss of control, consequences, preventive barriers, and mitigating barriers, making it possible to visualize where the protection architecture is strong, where it depends on fragile controls, and where relevant residual risk remains.
In engineering, the greatest value is not in the drawing itself, but in connecting the diagram to requirements, responsibilities, inspections, testing, commissioning, maintenance, and governance. When each critical barrier has a function, owner, evidence, and monitoring mechanism, Bow Tie ceases to be only a representation and becomes part of the real risk-management system.
Technical References
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 31010:2019 — Risk management — Risk assessment techniques. Geneva: IEC, 2019. Available at: https://webstore.iec.ch/en/publication/59809.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018. Available at: https://committee.iso.org/sites/tc262/home/projects/published/iso-31000-2018-risk-management.html.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. Dependability standards: risk assessment support. Geneva: IEC TC 56. Available at: https://tc56.iec.ch/dependability-standards/.
Frequently Asked Questions
It is a technique that organizes threats, the top event, consequences, and preventive and mitigating barriers in a scenario-oriented visual structure.
A matrix classifies and prioritizes exposures; Bow Tie deepens the causal logic and shows which barriers control the scenario before and after the top event.
No. HAZOP is a structured deviation-study technique. Bow Tie can deepen critical scenarios identified through HAZOP and make barriers and degradation factors explicit.
It is a relevant loss of control over a hazard, positioned between the threats that may cause it and the consequences that may develop afterward.
A preventive barrier acts before the top event to prevent its occurrence; a mitigating barrier acts after the top event to reduce propagation, severity, or the probability of consequences.
Yes. It is useful in design, procurement, construction, commissioning, and operations when relevant risks depend on technical, administrative, or operational barriers that must be demonstrated and monitored.
Supplementary Technical Materials
Related Solutions
- Project, Program, and Portfolio Governance
- Requirements, Evidence, and Acceptance Criteria Management
Related Services
Core Content on the Topic
- Risk Management in Engineering Projects
- Risk Matrix in Engineering Projects
- Risk Analysis in Engineering Projects
- Risk Mitigation in Engineering Projects
