CAPA root cause evidence should show, with traceable records, how the team moved from the stated problem to a defensible root cause. It should include the relevant facts, the analysis method used, the evidence considered, causes that were ruled in or out, and why the selected cause is credible. It should not be a pile of screenshots, informal opinions, or a conclusion written after the corrective action was already chosen.
The evidence has to be strong enough for the risk and context. A recurring escape on a flight-critical part, a validated process deviation, or a customer complaint normally needs more disciplined evidence than a low-risk internal paperwork error. The exact standard is site-specific and may be shaped by the QMS, customer flowdowns, product risk, process validation status, and regulatory expectations. It does not guarantee audit acceptance by itself.
Common evidence to include
Useful CAPA root cause evidence usually includes:
- The problem statement and scope: what happened, where it happened, when it was detected, affected part numbers, lots, orders, equipment, operators, suppliers, or programs, and what is explicitly out of scope.
- Objective records: inspection results, nonconformance records, defect codes, rework history, process parameters, equipment logs, calibration status, maintenance records, training records, traveler history, material traceability, and relevant batch or serial records.
- Process evidence: approved work instructions, routings, control plans, inspection plans, setup sheets, tool lists, revision history, and evidence of what version was active at the time of the event.
- Analysis artifacts: 5 Whys, fishbone diagrams, fault trees, 8D analysis, statistical review, process capability checks, or other methods appropriate to the issue. The method matters less than whether the logic is complete and supported.
- Interviews and observations: operator, inspector, maintenance, engineering, quality, supplier, or planner input, clearly labeled as interview evidence and supported where possible by records or direct observation.
- Rejected causes: credible candidate causes that were tested or checked and ruled out, with the evidence used to rule them out.
- Link to corrective action: a clear connection between the verified cause and the proposed correction or corrective action. If the action does not address the cause, the CAPA is weak even if the documentation is long.
Evidence should be traceable, not excessive
Good evidence is traceable to controlled sources. If data comes from MES, ERP, PLM, QMS, LIMS, CMMS, inspection systems, spreadsheets, or supplier portals, the CAPA record should make clear which record, report, revision, timestamp, lot, serial number, or transaction was used. Screenshots may help, but they are usually weaker than controlled records with audit trails and retention controls.
More evidence is not automatically better. Large exports without context can make the CAPA harder to defend. The record should preserve the evidence needed to support the reasoning, not every available data point. Where the source system is not validated or not the system of record, that limitation should be stated rather than hidden.
What should not be treated as root cause evidence
Common weak evidence includes conclusions such as “operator error” without explaining why the process allowed the error, training records used as proof that training was effective, tribal knowledge with no supporting record, or a corrective action selected before the cause was verified. A missing signature, outdated work instruction, or failed inspection result may be evidence of the problem, but it is not automatically the root cause.
CAPA evidence also should not depend on undocumented system behavior. In brownfield plants, data may be split across legacy MES, ERP, PLM, QMS, maintenance, and inspection tools. If timestamps do not align, defect codes are inconsistent, or routings differ between systems, the investigation should document those constraints. Full system replacement is usually unrealistic as a CAPA response because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, change control, and long equipment lifecycles.
Verification matters
Root cause evidence is not complete just because a plausible cause was named. The CAPA file should show how the cause was verified or why the team accepted it as the most defensible cause given available evidence. For higher-risk issues, that may require repeatability checks, process trials, data trending, supplier evidence, maintenance confirmation, or engineering review.
The final record should allow an experienced reviewer to follow the logic without relying on memory. If the reasoning only makes sense when the investigator explains it verbally, the evidence package is probably incomplete.