This is a ready-to-use fault tree analysis (FTA) worksheet. It goes deeper than a general RCA toolkit’s fault-tree section: it separates the tree construction from the minimal cut set derivation and the common-cause analysis, because those are the two steps investigators most often skip, leaving an elaborate diagram that never actually says which barrier to fix first. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This worksheet is qualitative (present/absent/unknown, AND/OR logic); it does not require or assume quantitative failure-rate data. Verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Fault Tree Analysis for GxP Investigations |
| Document number | <<FILL: FORM-ID, e.g. FRM-QA-052>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Head of Quality Assurance>> |
| Applies to | <<FILL: sites / departments in scope>> |
| Governing procedure | <<FILL: deviation/investigation SOP-ID this worksheet attaches to>> |
1. Purpose
This worksheet gives investigators a consistent way to build a fault tree for a serious, complex, or repeat GxP event, read out the minimal cut sets, and identify common-cause failures, so the corrective action is aimed at the combinations of barrier failures that actually produced the event rather than at the first cause noticed.
2. Scope
This worksheet applies to events serious or complex enough to justify fault tree analysis under the governing investigation procedure: typically sterility assurance failures, repeat critical deviations, serious data integrity breaches, and events where multiple independent controls had to fail together. It is not intended for a simple, single-cause event; use a 5-Whys or fishbone for those, per the risk-based tool selection in the governing procedure. This worksheet supports, and does not replace, the structured investigation report required by that procedure.
3. Responsibilities
| Role | Responsibility |
|---|---|
| Investigation owner | Builds the tree, drives the analysis, completes the worksheet, proposes CAPA against the cut sets |
| Technical SME(s) | Confirm the tree’s logic (gate choice, decomposition) is mechanistically correct for the system or process involved |
| Quality Assurance | Challenges the gate logic, confirms basic events are truly basic (not still vague), approves the completed worksheet |
| Reliability / engineering SME (where available) | Supports gate selection and common-cause identification for equipment- or system-heavy trees |
4. Definitions
- Top event: the single, specific undesired outcome the tree analyzes. Not a category of problems, one defined event.
- Gate: the logical relationship between an event and the events that produce it. This worksheet uses two: AND (all children required) and OR (any one child sufficient).
- Intermediate event: an event that is itself broken down further into child events through another gate.
- Basic event: an event that will not be decomposed further, verifiable directly against a record, log, or observation.
- Minimal cut set: the smallest combination of basic events that, together, are sufficient to cause the top event. A cut set of one basic event is a single point of failure.
- Common cause: one underlying condition that defeats two or more nominally independent basic events at the same time (for example, one untrained shift defeats both a performer check and a verifier check).
5. Gate legend and construction rules
| Symbol used in this worksheet | Meaning | Construction rule |
|---|---|---|
| AND | All child events must occur together for the parent to occur | Use when the parent represents a control that required multiple simultaneous failures to be defeated (defense in depth) |
| OR | Any one child event alone is sufficient for the parent to occur | Use when the parent has multiple independent, alternative causes |
Rules to hold the tree to:
- Define the top event precisely, in the past tense, as something that happened, not a category.
- At each level, ask “what is the immediate, necessary, and sufficient set of causes for this event?” before choosing a gate.
- Do not stop decomposing until a basic event is directly verifiable against a specific record, log, interview, or physical check. “Equipment failure” is not basic; “differential pressure sensor DP-114 read below alarm threshold for 6 minutes, confirmed by BMS trend log” is basic.
- Mark every basic event’s status as it is investigated: confirmed present, confirmed absent, or unknown/unchecked. Do not leave a tree with unpopulated boxes and call it complete.
6. Tree worksheet
Add rows as needed. Use the “Parent” column to show which event this row feeds into, so the tree structure is traceable in table form.
Top event: <<FILL: precise, singular, past-tense top event>>
| Level | Event ID | Parent event ID | Event description | Gate feeding this event’s parent | Basic event? (Y/N) | Status | Evidence |
|---|---|---|---|---|---|---|---|
| 0 | T | n/a | <<FILL: top event>> | n/a | N | <<FILL>> | <<FILL>> |
| 1 | <<FILL: A>> | T | <<FILL>> | <<FILL: AND/OR>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 1 | <<FILL: B>> | T | <<FILL>> | <<FILL: AND/OR>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL: A or B>> | <<FILL>> | <<FILL: AND/OR>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL: A or B>> | <<FILL>> | <<FILL: AND/OR>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | <<FILL>> | <<FILL>> | <<FILL: basic event>> | n/a | Y | <<FILL>> | <<FILL>> |
7. Minimal cut set derivation
List each path from the top event down to a complete set of basic events sufficient, on their own, to produce the top event. An AND-gated branch contributes all of its children to the same cut set; an OR-gated branch produces a separate cut set for each child.
| Cut set # | Basic events in this set | Single point of failure? (Y if set size = 1) | Confirmed present, absent, or unknown |
|---|---|---|---|
| 1 | <<FILL>> | <<FILL>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | <<FILL>> | <<FILL>> | <<FILL>> |
Priority rule: a cut set of size one (a single basic event, confirmed present, sufficient by itself) is always the highest CAPA priority. Among larger cut sets, prioritize any basic event that repeats across multiple cut sets, since fixing it degrades every cut set it appears in at once.
8. Common-cause analysis
For each basic event confirmed present, ask whether the same underlying condition could also explain another basic event in a different branch.
| Basic event | Nominally independent of… | Shared underlying condition, if any | Common-cause confirmed? |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL: Y/N>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL: Y/N>> |
A confirmed common cause is a priority finding: it means barriers presented as independent in the design were not independent in practice, which is a more serious system gap than any single basic event.
9. CAPA linkage
| Cut set / basic event addressed | Action | Corrective / Preventive | Owner | Due date | Effectiveness check |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
10. Acceptance criteria
A completed fault tree is acceptable when all of the following are true:
- The top event is specific, singular, and stated as something that happened.
- Every gate choice (AND/OR) is justified by how the system or process actually works, confirmed by a technical SME.
- Every basic event is directly verifiable and has a recorded status (present, absent, or unknown), not left blank.
- The minimal cut sets are derived and listed, not just implied by the diagram.
- Single-point-of-failure cut sets and confirmed common causes are explicitly called out and prioritized in the CAPA.
- A reviewer who was not involved in building the tree can follow the logic from the top event down to the cut sets from the worksheet alone.
11. References
21 CFR 211.192 (investigation of discrepancies and failures). ICH Q9(R1), Quality Risk Management, for risk-based tool selection and recognized risk management methods. IEC 61025, Fault Tree Analysis (FTA), for the underlying method.
Confirm the current version and clause numbers of each reference before issue.
12. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
13. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (Technical SME) | <<FILL>> | ||
| Approver (Quality Head) | <<FILL>> |
Filled specimen
The following shows the worksheet completed for an example event: an expired raw material charged into a batch despite multiple controls intended to prevent it. The company, system, and numbers are illustrative; replace them with your own.
Top event: An expired lot of raw material was charged into Batch RM-2216 during manufacturing.
Tree worksheet:
| Level | Event ID | Parent | Event description | Gate | Basic event? | Status | Evidence |
|---|---|---|---|---|---|---|---|
| 0 | T | n/a | Expired raw material charged into Batch RM-2216 | n/a | N | Confirmed | Batch record; material lot traced to an expired CoA |
| 1 | A | T | Expired material remained accessible for dispensing (not physically or systemically blocked) | AND | N | Confirmed | Warehouse location log |
| 1 | B | T | Material passed at least one dispensing control undetected | AND | N | Confirmed | Dispensing batch record review |
| 2 | A1 | A | Material was not moved to a blocked/quarantine location before its expiry date | OR | Y | Confirmed present | Warehouse task log shows quarantine move task open, not completed, at time of expiry |
| 2 | A2 | A | Warehouse management system status flag did not physically or systemically prevent picking | OR | Y | Confirmed present | WMS configuration record: expired-lot pick block was configured to warn, not hard-stop |
| 2 | B1 | B | Dispensing operator’s visual expiry check did not catch the expired date | AND | Y | Confirmed present | Interview and dispensing record; label expiry date was in small print on a secondary label |
| 2 | B2 | B | Second-person verification did not catch the expired date | AND | Y | Confirmed present | Verifier signed the dispensing record without an independent date check being a required, discrete step |
Minimal cut set derivation:
| Cut set # | Basic events in this set | Single point of failure? | Status |
|---|---|---|---|
| 1 | {A1, B1, B2} | No (size 3) | All confirmed present |
| 2 | {A2, B1, B2} | No (size 3) | All confirmed present |
Both cut sets are confirmed present simultaneously in this event: the quarantine move was overdue (A1) and the WMS block was a soft warning rather than a hard stop (A2), so branch A was doubly compromised, and both the operator check and the verifier check (B1, B2) missed the same expired date.
Common-cause analysis:
| Basic event | Nominally independent of… | Shared underlying condition | Common-cause confirmed? |
|---|---|---|---|
| B1 (operator visual check missed) | B2 (verifier check missed) | Both checks relied on reading a small-print date on a secondary label with no barcode scan step; neither check was a distinct, forcing action in the record | Y |
| A1 (quarantine move overdue) | A2 (WMS soft block) | Independent, different systems (manual task queue vs. WMS configuration); no shared condition found | N |
Reading the tree: branch B is the common-cause priority, since the operator and verifier checks failed for the identical reason (a hard-to-read date and no forcing function), meaning the “two-person” control was never truly independent. Branch A shows two coincidental but unrelated weaknesses, both worth fixing but not a shared root cause.
CAPA (extract):
| Cut set / basic event addressed | Action | C/P | Effectiveness check |
|---|---|---|---|
| B1, B2 (common cause: no forcing function on expiry check) | Add a mandatory barcode scan of the material lot at dispensing that hard-stops on an expired lot, replacing the visual-only check for both operator and verifier | Preventive | Review next 20 dispensing events for scan-block trigger rate and zero expired-lot pass-throughs |
| A2 (WMS soft block) | Reconfigure WMS expired-lot flag from warn to hard-stop | Corrective | Confirm configuration change in next periodic review; test pick attempt against a deliberately expired test lot in a validated test environment |
| A1 (quarantine move overdue) | Add an automated overdue-task escalation to the warehouse task queue | Preventive | Monitor overdue-quarantine-task metric for 90 days |
In this example, fixing only the operator’s visual check (the first, most visible finding) would have left the WMS soft-block, the overdue-quarantine gap, and the verifier’s identical blind spot all live. The minimal cut set analysis is what surfaced that both cut sets shared branch B, making the barcode scan the single highest-value action.
Common inspection findings this worksheet prevents
- A fault tree diagram exists but no minimal cut sets are ever read out, so it is unclear which combination of failures the investigation is actually treating as the priority.
- Basic events left vague (“equipment issue”, “procedural gap”) with no record-level evidence attached.
- A common-cause failure across two “independent” barriers is missed, so the CAPA fixes one barrier and leaves the shared underlying condition live in the other.
- AND and OR gates used inconsistently or reversed partway through the tree, inverting the logic without anyone noticing.
- CAPA aimed at the first basic event discussed rather than at the cut set(s) that actually explain the event.
How to adapt this worksheet
- Set your document number, owner, and effective date in the header, and point the governing-procedure field at your real investigation SOP.
- Use section 5’s construction rules as a short briefing for anyone new to fault tree analysis before their first session; the gate discipline is the part most often gotten wrong.
- For a very large tree, keep section 6 as a working table and render the final diagram separately if your document system supports it; the table format in this worksheet is what carries the traceable evidence, not the picture.
- Wire section 9 to your CAPA system so each cut set and its effectiveness check are tracked to closure.
- Confirm every regulation in section 11 against the current published version before issue.