Fault tree analysis: systematically analyzing and controlling risks

Today's systems consist of a multitude of networked components, software components are constantly increasing, and regulatory requirements are continuously rising. In this environment, it is no longer sufficient to consider individual causes of failures in isolation. It is crucial to understand how combinations of failures interact in real-world operations and can lead to critical system failures.

This is precisely where fault tree analysis (FTA) comes in. As a structured, deductive method of risk analysis, it helps companies identify potential causes of failure at an early stage, analyze them logically, and present them transparently. Instead of treating symptoms, FTA focuses on the underlying relationships—in a comprehensible, verifiable, and systematically documented manner.

Fault tree analysis has long been an integral part of risk management, especially in safety-critical industries. However, as product complexity increases, so do the requirements: analyses must be versioned, linked to actions, and kept up to date throughout the entire product lifecycle. Modern eQMS platforms provide the necessary structure for this – and turn an isolated analysis into an integrated control tool.    

What is FTA?

FTA (Fault Tree Analysis) is a deductive method for systematic risk analysis. The aim is to identify the causes of a defined system failure in a structured manner and to present their logical relationships transparently.  

The focus is on the so-called top event: an undesirable event such as a system failure, a security breach, or a critical malfunction. Starting from this top event, all possible causes that could lead to this failure, either individually or in combination, are analyzed step by step.

The FTA follows a clear top-down approach:

1. Definition of the critical event (top event)
2. Identification of direct causes
3. Further breakdown into basic events
4. Representation of logical links

The relationships between the causes are visualized using logical operators, e.g.:

• AND-Gate (AND link): The top event only occurs when several causes are present at the same time.
• OR-Gate (OR link): Even a single cause can trigger the top event.

This creates a tree-shaped diagram – the fault tree. It not only reveals individual faults, but also complex dependencies within a system.  

Qualitative, quantitative, and dynamic FTA

Fault tree analysis is not a rigid method. It can be designed differently depending on the objective and regulatory environment.

1. Qualitative FTA – Focus on structure

Qualitative FTA focuses on the logical structure of the fault tree. Probabilities of occurrence are not calculated; instead, the focus is on:

• Identification of relevant causes
• Analysis of logical dependencies
• Detection of critical cause chains
• Derivation of preventive actions

It is particularly suitable in early development phases for understanding system risks structurally.

2. Quantitative FTA – Calculating risks

Quantitative FTA supplements the structure with mathematical probabilities. Failure rates are defined for basic events in order to calculate the probability of the top event occurring.  

Typical objectives:

• Evaluation of system reliability
• Comparison of different design options
• Verification of safety requirements
• Compliance with regulatory requirements

Quantitative FTA is a central component of regulatory safety verification, particularly in industries such as medical technology, automotive, and aerospace.

3. Dynamic FTA – Taking temporal dependencies into account

In complex systems, static models are often insufficient. Dynamic FTA also takes the following into account:

• Temporal dependencies
• Event sequences
• State transitions
• Redundant or sequential system structures

It is often combined with advanced methods such as Markov analyses. These model temporal state transitions and dynamic system behavior, enabling the calculation of availability and failure probabilities under realistic operating conditions.

When is FTA the right method? Differentiation from other methods

Fault tree analysis is a key method of systematic risk analysis, but it complements other established quality management procedures. Its particular strength lies in the deductive consideration of specific system events—and this is precisely what distinguishes it from other methods.

FTA vs. FMEA

• Fault tree analysis (FTA) focuses on the behavior of a system during operation. It typically identifies combinations of causes that can collectively lead to a system failure
• Failure Mode and Effects Analysis (FMEA), on the other hand, starts earlier: it examines the design or manufacturing process of a system and evaluates individual potential causes of failure in terms of their impact, occurrence, and detectability—in other words, before the system is even put into use.

In practice, both methods are often used complementarily:
FMEA is used for preventive weak point analysis at the component level, while FTA is used in particular to investigate critical system events and complex cause-and-effect relationships.  

Differences between Ishikawa and 5 Whys

Qualitative methods such as the Ishikawa diagram or the 5 Whys method also support root cause analysis, but differ in structure and depth:

• Ishikawa diagram: qualitatively structures possible influencing factors
• 5 Whys method: linear questioning technique for identifying a root cause

In comparison, FTA offers significantly greater structural depth. It enables the systematic mapping of complex logical links (AND/OR gates) and is particularly suitable for technically demanding or safety-critical systems.

FTA is the right choice when investigating a specific system failure, identifying dependencies, or calculating failure probabilities. In combination with other methods, this creates a holistic approach to risk management.

Integrated analysis tools: fault tree, event tree, and Markov analyses combined in a single platform

A single method is often insufficient for the systematic risk analysis of complex technical systems. Different questions - from cause analysis to consideration
Possible event sequences, including the modeling of time-dependent system states, require different, complementary analytical approaches.  

Fault tree analysis, event tree analysis, and Markov analysis pursue different but complementary perspectives:

• Fault tree analysis (FTA)
  Deductively analyzes a defined top event and identifies its logical cause structures. Ideal for the systematic investigation of combinatorial failures.
• Event tree analysis (ETA)
  Considers possible scenarios after a triggering event and evaluates different consequences. Particularly suitable for safety and escalation analyses.
• Markov analysis
  Models temporal state transitions and dynamic system behavior. Enables the calculation of availabilities and failure probabilities under realistic operating conditions.

The methodical interaction of these approaches results in a holistic understanding of risk that systematically links structural dependencies, possible scenarios, and temporal dynamics. This allows complex technical systems to be analyzed comprehensively and informed decisions to be made in risk management.

FTA in the product development process

Fault tree analysis has the greatest impact not only in the field, but also in the early stages of development.

Concept phase: Making risks visible

Even at the architecture and requirements level, FTA helps to analyze critical functions and structure possible failure scenarios - long before high change costs arise.

Development phase: Validating the design

In detailed development, FTA enables:

• Identification and evaluation of necessary redundant structures
• Analysis of safety-related functions
• Data-based design decisions
• Prioritization of actions

Verification and validation: Proof of risk control

Fault tree analysis provides a comprehensible argumentation structure for:

• Standard and audit verification
• Safety documentation
• Regulatory requirements

Series production: Continuous improvement

Even after the product launch, FTA remains relevant. Findings from complaints, CAPA processes, or field data can be integrated, and existing fault trees can be continuously developed.

How eQMS supports FTA

A modern eQMS elevates fault tree analysis from static documentation to the level of integrated risk management. Instead of isolated diagrams, a central, structured working environment is created in which fault trees can be consistently constructed, maintained, and further developed. A uniform database ensures that top events, intermediate events, and basic events are transparently mapped and remain logically linked. Version-secure management allows changes to be documented in a traceable manner, historical statuses to be reconstructed, and adjustments to be implemented efficiently – especially in the case of changing requirements or design adjustments.

The decisive added value comes from directly linking identified risks with concrete actions. Risks from the FTA can be directly linked to tasks, corrective or preventive actions. The implementation and effectiveness of these actions remains traceable at all times and is integrated into continuous improvement processes. In this way, fault tree analysis becomes an active part of quality management – not an isolated analysis artifact.

In addition, modern platforms enable the integration of further analysis methods such as event tree analysis (ETA) or Markov analyses. Combining fault tree, event tree, and state-based models in a common system environment creates a holistic risk architecture. Structural dependencies, possible scenarios, and temporal dynamics can be consistently mapped—and risks can be managed in a well-founded manner throughout the entire product life cycle.

Conclusion

Fault tree analysis is much more than a classic cause analysis. It is a structured, logical tool for managing complex system risks – from the early concept phase to series production. However, it only reaches its full potential when it is digitally integrated, documented in a version-secure manner, and linked to other quality and risk processes. This transforms a method into a strategic tool for preventive quality – throughout the entire product life cycle.