“Human error” may explain what happened, but it often fails to explain why. Learn how to investigate the process, system, equipment, training, and organizational conditions behind quality failures.
An employee selects the wrong component. A technician records the wrong value. An operator skips a step. A reviewer misses an error. A required check is not completed.
The investigation opens. A few days later, the conclusion reads:
Root Cause: Human Error. Corrective Action: Retrain the employee. CAPA closed.
And six months later, something very similar happens again.
That pattern is one of the clearest signs that an investigation stopped at the event instead of finding the conditions that allowed the event to happen.
“Human error” can accurately describe what an individual did. But it often does not explain why the quality system allowed one ordinary mistake to become a product, process, data, or compliance failure.
A stronger investigation asks: Why was this mistake possible? Why wasn't it prevented? Why wasn't it detected earlier? Could the same conditions affect someone else tomorrow?
Those questions are where root cause analysis begins.
The person who made the final mistake may be the last link in the causal chain, not the first.
Consider a wrong-component event. The employee physically selected the wrong item. That is factual. But the investigation may also find that:
Saying “the operator selected the wrong part” identifies what happened. It does not explain why the process was designed so that one selection mistake could pass through every available control.
That distinction is the heart of effective root cause analysis.
In a May 27, 2026 warning letter to pharmaceutical manufacturer Pharmathen International S.A., FDA addressed recurring sterility and media-fill failures in which operator error had contributed significantly.[1]
FDA did not simply accept “operator error” as the end of the investigation. The agency stated that the firm's investigation:
“did not include in-depth analysis of the conditions that create the circumstances for human error.”
— U.S. Food and Drug Administration, Warning Letter to Pharmathen International S.A., May 27, 2026
FDA went on to state that an in-depth root-cause analysis was needed to identify effective CAPA, including consideration of design remediation. The agency also criticized the firm's proposed CAPAs because they lacked sufficient detail about how effectiveness would be evaluated.
This is an important distinction. The regulatory concern was not merely that employees had made errors. The concern was that the investigation had not adequately examined why those errors were recurring or what conditions within the operation made them possible.
Source: U.S. Food and Drug Administration, Pharmathen International S.A. — Warning Letter 320-26-80, May 27, 2026.
This warning letter concerns pharmaceutical CGMP requirements under 21 CFR Parts 210 and 211. It should not be read to mean that every statement in the letter establishes a universal requirement for ISO 9001, ISO/IEC 17025, medical-device, laboratory, or other QMS environments. It is cited here as a current FDA enforcement example demonstrating why investigations may need to look beyond the immediate human action.
When an investigation concludes “human error,” ask what would happen if the employee were replaced tomorrow. Would the next appropriately trained employee face:
If the answer is yes, then replacing or retraining the employee has not removed the condition that produced the failure.
That does not mean the employee bears no responsibility. It means accountability and causality are different questions. An organization can appropriately address individual performance while still investigating whether the quality system contributed to the event. Do not substitute one for the other.
This final level is where meaningful corrective-action opportunities often become visible.
If recurrence can move from one trained employee to another without the system changing, the system deserves investigation.
An investigator often hears the description of an event and immediately develops a theory. That is normal. The mistake is turning that theory into a conclusion before gathering evidence.
Start with facts. Ask: What actually happened? What should have happened? What evidence proves each statement? Where did expected performance first deviate? Which controls should have prevented the event? Which controls should have detected it? Did those controls exist? Did they function? Were they realistically designed?
Root cause analysis should be an evidence-building process, not a search for facts that support the first explanation.
FDA has also described root cause analysis as a structured analytical approach intended to understand why an incident occurred so that targeted interventions can help prevent similar events.[2] FDA's current food-safety RCA materials describe practices including defining the problem, gathering relevant information, analyzing data, considering multiple possible causes, using tools such as process maps and cause-and-effect diagrams, identifying root cause or causes, taking action, and verifying that actions worked.
Source: U.S. Food and Drug Administration, Strengthening Food Safety through Root Cause Analysis. This FDA resource concerns food safety and is cited for its general RCA methodology—not as a universal regulatory requirement for all industries.
Do not hide your presumed root cause inside the problem statement.
“Operator failed to follow the SOP due to lack of attention.” That statement already assumes the SOP was adequate, the operator's attention was the problem, and no other factors contributed. None of that may have been established yet.
“On August 12, an operator recorded lot 4826 on the batch record although lot 4286 was used during the operation.” Now the investigation has a factual starting point.
A strong problem statement generally establishes what occurred, what should have occurred, when, where, the product/process/system involved, how the issue was detected, the known scope, and the potential impact. Keep causation out of the statement until causation has been investigated.
Root cause analysis can take time. Risk may need to be controlled immediately. Possible containment or correction activities include stopping affected operations, placing product on hold, segregating materials, correcting a record appropriately, blocking a system configuration, removing defective equipment from service, increasing temporary verification, and notifying affected groups.
But do not confuse containment with corrective action.
| Action | Question it answers |
|---|---|
| Containment | How do we control the immediate risk? |
| Correction | How do we fix this specific occurrence? |
| Investigation | Why did this happen? |
| Corrective action | What should change because of what we learned? |
| Effectiveness check | Did the change actually work? |
Terminology differs between frameworks and organizations. Preserve that nuance.
Create a chronological sequence of events before debating causes. A useful timeline may include the procedure revision in effect, employee training status, work start, material selection, equipment state, software activity, hand-offs, environmental conditions, interruptions, inspections, alarm events, approvals, deviations from the expected sequence, and detection of the issue.
Timelines are powerful because they expose hidden dependencies. For example, the investigation begins with “Employee skipped the independent verification.” The timeline reveals:
The missed check is still real. But the investigation now has substantially more useful information.
Do not investigate only from behind a desk. A procedure may look perfectly clear to the person reading it in Quality. Go to the point of use.
Where appropriate, observe the task, look at the equipment, review the screen, compare the materials, follow the actual workflow, look at the physical space, evaluate hand-offs, and ask the employee to show how the process works. You may discover that:
A root cause investigation should study the process that exists in reality—not only the process described on paper.
Employee interviews are valuable sources of evidence. But the goal is to understand the event. Start with: “Walk me through what happened.”
Then explore: What did you expect to happen? What information were you using? What was different from normal? Was anything unclear? Were you interrupted? Was there time pressure? Have you encountered this situation before? Is there a workaround employees commonly use? What makes this task difficult? What would make this mistake harder to make?
Avoid beginning with “Why didn't you follow the SOP?” That question assumes the investigation has already established the cause. It can also discourage employees from telling you about process weaknesses that may matter more than the individual mistake.
For every meaningful failure, consider three layers:
What should have prevented this error?
If prevention failed, what should have detected it before impact?
Once detected, what should have limited the consequence?
Example — wrong material selected:
| Layer | Control that should have applied |
|---|---|
| Prevention | Physical segregation, barcode scanning, clear labeling |
| Detection | Independent verification before use |
| Response | In-process testing or reconciliation before release |
If all three layers fail, the investigation should not focus exclusively on the person who made the first mistake. The control architecture itself deserves attention.
If those questions have not been evaluated, “human error” is probably the beginning of the investigation—not the conclusion.
The 5 Whys is useful because it forces the investigator past the immediate event. But it is not magic.
Problem: Wrong label applied.
Now the investigation has found something the organization can change. But sometimes three Whys are sufficient, sometimes more than five are necessary, and sometimes several causal paths exist. The objective is not to reach exactly five boxes. The objective is to follow causality as far as the evidence supports.
For a complex event, use a cause-and-effect / Ishikawa approach to explore possible contributors.
| Category | Prompts to explore |
|---|---|
| People | Training, competency, experience, communication, workload, supervision |
| Process | Sequence, procedure clarity, hand-offs, verification, complexity, approval logic |
| Equipment / Technology | Equipment design, user interface, alarms, configuration, maintenance, calibration |
| Materials | Identification, similarity, storage, labeling, supplier variation |
| Measurement | Methods, sampling, acceptance criteria, instrument capability, data interpretation |
| Environment | Lighting, noise, layout, interruptions, temperature, material flow |
| Management / System | Staffing, scheduling, responsibilities, oversight, change control, risk management, resources |
A fishbone generates hypotheses. It does not generate root causes. Each suspected cause still needs evidence.
Retraining has its place. It is reasonable when the evidence demonstrates a genuine knowledge or competency gap—for example, the requirement was clear, the process was appropriately designed, the employee had not been trained, the employee misunderstood a defined requirement, and the issue was reasonably isolated.
But retraining does not fix confusing software, look-alike materials, an impractical procedure, excessive manual transcription, missing controls, poor workflow design, unclear responsibilities, inadequate equipment, or chronic understaffing.
If a perfectly trained new employee started tomorrow, would the process still make the same mistake reasonably easy to make?
If yes, training alone probably does not address the underlying weakness.
Event: Incorrect component installed.
Root Cause: Operator failed to follow the component-selection procedure.
CAPA: Retrain operator.
Effectiveness Check: Training completed.
What is missing? Why was the component confused? Could another operator make the same mistake? Did the process have preventive controls? Did detection controls function? Has this occurred before? Does training completion demonstrate effectiveness?
Event: Component 4826 installed instead of Component 4286.
Evidence:
Immediate cause: Incorrect component selected.
Contributing factors: Similarity, storage location, manual identification, inadequate verification.
Systemic cause: Material-control design relied primarily on manual visual differentiation of known look-alike components without sufficient error-prevention or detection controls.
Potential actions: Segregate look-alike materials, improve labeling, implement barcode verification, add risk-based verification, update material-location standards, review other similar components, and train employees on the revised controls.
Effectiveness measure: Confirm revised controls are consistently used and monitor applicable transactions and near-misses for a period or sample size capable of detecting recurrence.
Investigation B does not excuse the operator's mistake. It gives the organization something meaningful to improve.
Once a cause is identified, ask: Where else does this condition exist? This is one of the differences between correcting an event and improving a quality system.
The original event defines where the investigation started. It should not automatically define where the investigation ends.
Do not assume an event is isolated because no previous record has the same title. Search deviations, nonconformances, CAPAs, complaints, audit findings, OOS/OOT records where applicable, supplier issues, maintenance records, near-misses, and help-desk tickets where relevant.
A single systemic problem may previously have been categorized as operator error, documentation error, a training issue, incorrect selection, missed verification, or procedure deviation. Different labels can hide the same failure mode. Trending should look for patterns in causes and failure mechanisms, not only matching titles.
| Cause identified | Action may involve |
|---|---|
| Procedure unclear | Procedure redesign |
| Competency gap | Targeted training + competency verification |
| Similar materials | Segregation / visual differentiation / mistake-proofing |
| Manual transcription | Automation or independent verification |
| Poor interface | Software or equipment redesign |
| Missing control | Preventive or detective control |
| Supplier weakness | Supplier-control improvement |
| Workflow overload | Process or resource redesign |
| Software configuration | Configuration change + appropriate testing |
If you cannot draw a clear line from the cause to the corrective action, reconsider either the cause or the action.
Did we do what we said we would do? Example: all employees completed training.
Did the action actually reduce the problem? Example: no recurrence of the targeted error across an appropriate number of opportunities, and the new control was confirmed to be functioning as intended.
Training completion proves training occurred. It does not prove that the original problem was eliminated.
The effectiveness method should consider the frequency of the event, process volume, severity, detectability, the expected recurrence interval, the nature of the control, and the available data.
Do not automatically use an arbitrary 30-day effectiveness period. If the historical failure occurred once every 18 months, a 30-day review may tell you almost nothing.
Sometimes the evidence does not support certainty. Do not manufacture certainty to complete a CAPA form. A defensible investigation may conclude that the root cause is inconclusive.
In that situation: document what was evaluated, document the available evidence, identify potential causes considered, explain which were ruled out and why, identify remaining plausible causes, evaluate risk, implement appropriate controls where warranted, increase monitoring if justified, trend for recurrence, and reopen or expand the investigation if new evidence appears.
A well-supported inconclusive finding is better than an unsupported statement presented as fact. This is consistent with FDA's approach in the cited Pharmathen warning letter, where FDA specifically expected broader manufacturing review when a laboratory cause could not be conclusively established. Do not overgeneralize that pharmaceutical-specific expectation to every QMS framework.
There are cases where evidence may support an individual behavioral cause. For example, the investigation may establish that:
That can be a legitimate finding. The point is not “human error can never be the cause.” The point is that human error should be demonstrated through investigation, not selected as the default explanation because a person happened to be involved.
| Failure | What it usually means |
|---|---|
| Root cause = human error | Investigation may have stopped at the immediate action |
| Root cause = SOP not followed | Describes nonconformance, not necessarily cause |
| CAPA = retraining | May not address the identified system weakness |
| 5 Whys completed mechanically | Form completed without causal analysis |
| Only employee interviews used | Objective system evidence may be missing |
| No historical review | Recurrence may go undetected |
| No horizontal review | Same weakness may remain elsewhere |
| Effectiveness = action complete | Implementation confused with effectiveness |
| Predetermined conclusion | Investigation becomes confirmation bias |
| Endless analysis | Investigation effort exceeds what risk justifies |
“Why did the employee make the mistake?”
Ask“Why did our process allow one human mistake to become a quality failure?”
People will make mistakes. An effective QMS does not assume otherwise. It establishes processes that make important errors less likely, makes failures more detectable, limits their consequences, and learns when the controls are not enough.
That is why root cause analysis should not be an exercise in assigning blame. It should be an exercise in learning how the failure happened well enough to prevent it from happening again.
And if your CAPA repeatedly ends with Human error → Retrain → Close while similar problems continue to recur, the problem may no longer be the individual investigation. It may be the CAPA system itself.
Sometimes, but it should be supported by evidence rather than used as a default classification. Even when an individual's action directly caused an event, the investigation should consider whether process, system, procedural, equipment, environmental, or organizational factors contributed.
Retraining addresses knowledge or competency. It does not redesign confusing processes, eliminate look-alike materials, change poor interfaces, automate manual transcription, or add missing controls.
No. It is one tool. Depending on the event, organizations may use timelines, process mapping, cause-and-effect diagrams, fault-tree analysis, barrier analysis, or other methods.
An immediate cause is the condition or action directly associated with the event. Root or systemic causal analysis attempts to determine why that condition existed and what underlying weakness allowed it to result in the failure.
Yes. When the available evidence does not support a definitive cause, documenting uncertainty and the evidence evaluated is preferable to inventing an unsupported conclusion.
The effectiveness check should evaluate whether the action addressed the identified cause and achieved the intended result—not merely whether the action was completed.
Recurring deviations, repeated “human error” investigations, and CAPAs that close without demonstrating effectiveness can indicate a deeper quality-system problem. Athyrion helps organizations strengthen investigations, root cause analysis, CAPA, quality procedures, risk-based quality processes, QMS implementation, and digital quality workflows.
Athyrion does not guarantee regulatory, certification, or audit outcomes.
