Root Cause Analysis: 5 Whys and Fishbone Diagrams in Food Safety

Fixing the Symptom Is Not Fixing the Problem

A customer complaint lands: plastic fragment in a cereal bar. The plant responds fast — retrains the packing operators, issues a memo, closes the complaint file. Three weeks later, another fragment, same line. The “corrective action” treated the symptom. The cause — a cracked nylon guard on the depositor that nobody inspected because the guard isn’t on the preventive maintenance list — kept producing plastic.

Root cause analysis is the discipline of not stopping at the first plausible answer. Both ISO 22000:2018 and FSMA’s preventive controls rules require it: 21 CFR 117.150(a)(2)(ii) demands corrective actions that include a root cause analysis when a preventive control fails, and the corrective action must reduce the likelihood the problem recurs. “Retrained the operator” is not root cause analysis. It’s a sentence that looks like one.

Two tools dominate food industry practice: the 5 Whys and the fishbone (Ishikawa) diagram. Neither is magic. Both work because they force a team to keep asking until the cause is something you can actually fix — a physical thing, a process step, a system gap — instead of a vague human error that will happen again tomorrow.

The 5 Whys: Simple, Powerful, and Easy to Get Wrong

The 5 Whys technique comes from Toyota’s production system: start with the problem statement and ask “why” repeatedly until you reach a cause you can act on. Five is a rule of thumb, not a law — stop when you’ve found an actionable root cause, whether that takes three whys or eight.

Here’s a real-feeling example. Problem: finished product tested positive for Listeria monocytogenes on a food contact surface.

• Why 1: Why was Listeria on the contact surface? → Because the sanitation procedure didn’t eliminate it.
• Why 2: Why didn’t the procedure eliminate it? → Because the equipment wasn’t fully disassembled before cleaning.
• Why 3: Why wasn’t it disassembled? → Because the disassembly instructions are missing from the SSOP — they exist only in the equipment manual, which sanitation staff don’t have.
• Why 4: Why are the instructions missing from the SSOP? → Because the SSOP was written for the previous equipment model and never updated when the line was replaced last year.

The actionable root cause: the SSOP revision process doesn’t trigger when equipment changes. The fix: revise the SSOP with model-specific disassembly steps and link equipment changes to SSOP review in your change-control procedure. Compare that to “retrain the sanitation crew,” which fixes nothing and insults everyone.

The common failure mode: stopping at “human error.” If your fifth why is “because the operator made a mistake,” you haven’t found a root cause — you’ve found a symptom wearing a root cause costume. Ask why the error was possible: was the procedure unclear, the training incomplete, the workload excessive, the equipment unforgiving? Systems cause errors; blaming people just guarantees the next one.

Building a Fishbone Diagram That Actually Finds Causes

When the problem has multiple possible causes — most real problems do — the fishbone (Ishikawa) diagram organizes them. The head of the fish is the problem statement. The main bones are cause categories. For food manufacturing, these work well:

1. Man: training, competency, staffing levels, fatigue, turnover.
2. Machine: equipment condition, maintenance frequency, design flaws, calibration.
3. Method: procedures, work instructions, sequence of operations.
4. Material: raw materials, packaging, chemicals, supplier variation.
5. Measurement: monitoring methods, test accuracy, sampling plans.
6. Environment: facility condition, condensation, pest pressure, temperature control.

Run the session with the people who do the work — operators, maintenance, sanitation — not just the QA office. For each bone, brainstorm specific possible causes, then gather evidence for each one. A fishbone session without evidence is a guessing session; the diagram organizes hypotheses, but swab results, maintenance logs, and trend data eliminate them.

Once evidence points to a cause category, use the 5 Whys to drill into it. The two tools are a team: the fishbone spreads wide to find candidates, the 5 Whys digs deep into the real one.

Making Corrective Actions Stick

Root cause analysis fails at the end more often than at the beginning. The team finds a genuine root cause, writes a beautiful fishbone, and then the corrective action is “update the procedure” — with no effectiveness check. ISO 22000 clause 10.2 requires corrective actions to include reviewing effectiveness. An action without a follow-up measurement is a hope, not a fix.

Every corrective action needs three things: an owner, a deadline, and an effectiveness check with a date. For the Listeria example above: owner = sanitation supervisor, deadline = revised SSOP approved and trained within 30 days, effectiveness check = 90 days of environmental monitoring data showing no recurrence on that line, plus a change-control linkage verified at the next management review.

Document it all. Auditors don’t grade your fishbone artistry — they check that the corrective action addressed the identified cause, that it was implemented on time, and that evidence shows it worked. A one-page corrective action report beats a ten-page diagram that led nowhere.

Finally, escalate the pattern. One root cause analysis fixes one incident. When your complaint and nonconformance data show the same category of cause appearing across lines or shifts, that’s a management review input (ISO 22000 clause 9.3) and possibly a system-level preventive action. The plants with the fewest repeats are the ones that treat root cause analysis as a routine discipline, not an emergency tool.

One more habit separates good programs from great ones: time-box the investigation. Root cause analysis that drags on for six weeks loses momentum and evidence — people forget details, product moves, the trail goes cold. Set a standard timeline: initial containment within 24 hours, root cause identified within 5 working days, corrective action implemented within 30 days, effectiveness check scheduled for 60 to 90 days out. Complex investigations (a pathogen positive, a suspected tampering incident) get extensions with documented justification, not by default. Speed matters because every day of delay is another day the root cause keeps producing defects, and because regulators and customers judge your response by the clock as well as by the quality.

Monday morning: pull your last three corrective action reports. For each one, find the effectiveness check. If it’s missing or says “retraining completed,” you’ve found your first three root cause analyses to redo — properly this time.