Fault Tree Analysis in GMP Investigations
Some GMP deviations cannot be explained by one straight causal chain.
An event may occur only when several conditions align: a process weakness, a control failure, a human action, a system gap, or a missed detection point. In those cases, a simple 5-Why may be too narrow, and a Fishbone diagram may organize possible causes but still not show how those causes connect.
Fault Tree Analysis helps the investigation team test the logic of how an event could have occurred.
In the broader lifecycle described in Pharmaceutical Investigations & CAPA, root cause analysis should support a clear and defensible conclusion. Fault Tree Analysis can help when the investigation needs to understand whether the event came from one pathway, several alternate pathways, or a combination of failures.
What Fault Tree Analysis Is
Fault Tree Analysis starts with the top event — the deviation or failure being investigated — and works backward to identify the conditions that could have caused it.
It asks:
What had to happen for this event to occur?
Could one condition alone explain it?
Did multiple conditions need to occur together?
Which controls should have prevented or detected it?
Which pathway is supported by evidence?
A fault tree is built around logic. It is not only a list of possible causes. It shows how causes, controls, and conditions relate to each other.
Two basic logic types are useful:
OR logic: Any one of several pathways could lead to the top event.
AND logic: Two or more conditions had to occur together for the top event to happen.
For example, if the top event is “wrong material charged to batch”, one possible pathway may require both conditions:
wrong material was available at point of use
and
verification failed to detect the mismatch
That is different from saying either condition alone fully explains the event.
Example Fault Tree Analysis showing how a GMP deviation may occur through combined conditions and alternate logical pathways.
How Fault Tree Differs From 5-Why and Fishbone
Each RCA tool has a different strength.
| Tool | Best Use |
|---|---|
| 5-Why Analysis | Following one reasonably clear causal path |
| Fishbone Diagram | Organizing several possible cause categories |
| Fault Tree Analysis | Testing logical pathways, combined failures, and control breakdowns |
As discussed in 5-Why Analysis in GMP Investigations, 5-Why works well when the causal path is relatively linear. As discussed in Fishbone Diagram in GMP Investigations, Fishbone is helpful when the team needs to organize multiple possible cause categories.
Fault Tree Analysis is most useful when the question is not only:
What might have caused this?
but:
What combination of conditions could have allowed this event to occur?
When Fault Tree Analysis Is Useful
Fault Tree Analysis is useful when the event involves control logic, multiple barriers, or more than one plausible pathway.
It may be appropriate for:
wrong material or component use
line clearance failure not detected before start-up
equipment alarm not escalated
environmental excursion with facility, cleaning, personnel, or material-flow factors
OOS or OOT event with both lab and process pathways
repeated deviation where prior CAPA did not prevent recurrence
late detection of a quality issue despite review or verification controls
product or process impact where the causal pathway must be clear
Fault Tree Analysis does not require the team to know the cause in advance. It helps the team test which pathways are plausible and which are supported by evidence.
When Fault Tree Analysis May Be Too Much
Fault Tree Analysis is not needed for every deviation.
It may be unnecessary when:
the event is narrow and low risk
the causal path is already clear
evidence supports a simple conclusion
no meaningful control-pathway questions exists
a focused 5-Why or documented rationale is enough
Fault Tree Analysis should clarify the investigation, not make a simple deviation look artificially complex.
A large fault tree with weak evidence is not stronger than a simple, well-supported causal explanation. This is one of the concerns discussed in When Root Cause Analysis Goes Wrong: RCA tools can look complete while the reasoning remains unsupported.
How to Build a Fault Tree
A practical Fault Tree process can follow these steps:
Define the top event clearly.
Identify immediate conditions that could lead to the top event.
Separate alternate pathways from combined conditions.
Use OR logic where any one pathway could cause the event.
Use AND logic where conditions must occur together.
Identify the controls that should prevent or detect each pathway.
Gather evidence for each pathway.
Rule out unsupported pathways with rationale.
Identify the supported cause or combination of causes.
Connect the conclusion to CAPA or no-CAPA rationale.
The top event should be factual.
Weak top event:
Operator selected wrong material.
Stronger top event:
Wrong material was charged to Batch A during dispensing.
The weak version already assumes the cause. The stronger version describes what happened and allows the investigation to test how it occurred.
Practical Example: Wrong Material Charged to Batch
Top event:
Wrong material was charged to Batch A during dispensing.
A simplified fault tree may show that the event could occur through several possible pathways.
| Fault-Tree Branch | Evidence to Check | What the Investigation Is Testing |
|---|---|---|
| Wrong material was available at point of use | Staging records, warehouse issue records, material movement logs, line clearance records | Whether the wrong material could physically reach the dispensing area |
| Material selection control failed | Batch record instructions, label similarity, barcode scan records, system restrictions, operator interview | Whether the process allowed the wrong material to be selected |
| Verification did not detect the mismatch | Second-person check record, verification timing, checklist design, reviewer role | Whether the verification control was capable and properly performed |
| System allowed incorrect selection | ERP/MES controls, material master, scanner logs, override records | Whether system controls permitted the wrong selection |
| Label or container design contributed | Label review, container similarity, storage layout, visual differentiation | Whether design conditions made selection error more likely |
The supported conclusion may be:
The event was not caused by material selection alone. The wrong material was available at point of use, and the verification control did not detect the mismatch before charge.
That conclusion is stronger than “operator selected wrong material” because it explains the combination of conditions that allowed the event. It also points to better CAPA logic.
Possible CAPA direction may include:
strengthening material staging controls
improving barcode or system restrictions
revising verification timing or independence
improving label differentiation
reviewing similar materials or dispensing steps
The CAPA should address the pathway supported by the evidence, not only the final person action.
AND vs OR Logic in Plain Language
Fault Tree Analysis is useful because it separates alternate pathways from combined conditions.
OR logic means the top event could happen through any one of several paths.
Example:
A wrong material could be charged if the material was mislabeled, or if the wrong material was selected, or if the system allowed an incorrect substitution.
Each pathway could potentially explain the top event.
AND logic means the top event required more than one condition together.
Example:
The wrong material was charged because the wrong material was available at point of use and the verification control failed to detect the mismatch.
Both conditions matter.
This distinction is important. If the investigation uses OR logic when conditions actually had to occur together, the conclusion may be too broad. If it uses AND logic without evidence that both conditions were necessary, the conclusion may overstate the case.
The logic should match the evidence.
Mini Example: Environmental Monitoring Excursion
Top event:
Grade C room exceeded the viable count action level.
A fault tree may test several possible pathways:
true room contamination occurred
sampling or handling error affected the result
cleaning or disinfection control was ineffective
HVAC or pressure cascade condition contributed
personnel or material movement introduced contamination
recent maintenance or intervention changed room conditions
Some of these may be alternate pathways. Others may combine.
For example, a true room contamination event may require:
contamination source present
and
cleaning or airflow control did not adequately control the source
and
monitoring result reflects actual room condition rather than sampling error
The investigation would then look for evidence such as organism identification, cleaning records, HVAC data, pressure trends, personnel flow, intervention history, sample handling records, and historical EM trends.
The fault tree helps the team avoid assuming that the result is either “sampling error” or “room contamination” too early. It creates a structure for testing each pathway.
Common Fault Tree Mistakes
Fault Tree Analysis can also be misused.
Common mistakes include:
defining the top event too vaguely
using the tree to confirm an already selected cause
listing possible causes without testing them
using AND and OR logic incorrectly
failing to include prevention or detection controls
creating a diagram too complex for the event
not explaining why pathways were ruled out
choosing CAPA for one branch while the evidence supports a different pathway
failing to update the tree when new evidence changes the causal logic
The most important mistake is treating the diagram as proof. The diagram is only useful if each pathway is tested against evidence.
QA Stress Test for Fault Tree Analysis
A Fault Tree should be able to stand up to QA review.
| QA Review Question | What the Fault Tree Should Show |
|---|---|
| Is the top event factual and specific? | The event is clearly defined without assuming the cause. |
| Are the pathways logical? | Each branch could reasonably lead to the top event. |
| Is AND/OR logic used correctly? | Combined conditions and alternate pathways are not confused. |
| Is each branch tested with evidence? | Records, data, interviews, logs, trends, or observations support or rule out each path. |
| Are controls included? | Prevention, detection, verification, alarms, or reviews are considered where relevant. |
| Are unsupported pathways ruled out? | The record explains why certain paths were excluded. |
| Does the conclusion match the supported pathway? | The root cause reflects the evidence-supported logic. |
| Does CAPA address the pathway? | CAPA addresses the condition or control failure that allowed the event. |
If the tree cannot answer these questions, the investigation may need more evidence, clearer logic, or a simpler method.
When to Combine Fault Tree with Other RCA Tools
Fault Tree Analysis can be used with other RCA tools.
A Fishbone diagram may help identify possible cause categories first. The fault tree can then test how those categories could logically connect to the top event.
A 5-Why can be used inside one branch of the fault tree. For example, if the fault tree shows that verification failed, a 5-Why can explore why the verification step did not detect the issue.
This combined approach is useful when the investigation starts broad and then needs deeper analysis of a specific pathway.
QA Review Perspective
Fault Tree Analysis is useful when causal logic matters.
It helps the investigation show whether the event resulted from one failure, several alternate pathways, or a combination of conditions. It is especially useful when controls, verification steps, alarms, systems, or detection points are central to the event.
A strong Fault Tree does not make the investigation more complicated. It makes the causal logic more visible.
The value lies in whether the investigation can show how the event occurred, which pathway is supported by evidence, and what condition or control needs to change to reduce recurrence risk.
Explore more on Investigations & CAPA Excellence
Browse VerethiQ resources on deviation handling, root cause analysis, investigation quality, CAPA design, effectiveness checks, recurrence prevention, and investigation governance.
