Taktly
All articles
Quality|7 min read

Why every CAPA needs an FMEA on the corrective action itself (not just on the original failure mode)

An FMEA on a process failure is table-stakes. Every CI / QA team does it. What almost nobody does is FMEA the corrective action they're about to roll out — which is itself a change to the system. Changes have failure modes. Failure modes have severity, occurrence, and detection. The CAPA is not exempt.

The shape of the problem

A deviation happens. You investigate. You find a root cause. You design a corrective action. You roll it out. Six months later, a new deviation happens — caused by the corrective action itself. The first deviation got an FMEA. The corrective action did not. Now you have two deviations to investigate. This is the most common way CAPAs introduce new problems: by changing one variable in the system without analyzing what else that change touches.

What 'FMEA on the corrective action' actually means

Score the corrective action on three dimensions, exactly like a process FMEA:

  • Severity (S, 1-10): If the corrective action FAILS to deliver the intended result, how bad is the impact?
  • Occurrence (O, 1-10): How likely is the action itself to fail in execution? (New SOP not read, alarm not heard, software override allowed.)
  • Detection (D, 1-10): How likely are we to catch the failure before it propagates? Higher D = harder to catch. (D=10 means the failure ships to the customer.)

Two examples — a 'low' and a 'critical'

Why this isn't just academic

ISO 9001:2015 clause 6.1.2 requires action plans to address risks AND opportunities. 21 CFR 820.30(g) requires risk analysis on design changes. IATF 16949 clause 8.5.6.1.1 requires change-management FMEAs. AS9100D clause 8.5.6 same. The standards all require this — but the work item ('FMEA the corrective action') is almost never on the CAPA template. Which means most CAPA forms drive practitioners to skip it.

The pre-flight checklist

  • Did we FMEA the corrective action itself? S × O × D scored.
  • If RPN ≥ 120: is there a mitigation plan? (Monitoring, rollback, second-operator check, alarm.)
  • If RPN ≥ 200: is there a pilot with a defined stop trigger? (Sample size, threshold, time-box.)
  • Have we cross-checked the action against any related design or process FMEAs that should be updated?
  • Is the FMEA score visible on the CAPA record (audit trail)?

How Taktly does this for you

Every countermeasure card in a Taktly project has S × O × D inputs with full AIAG-VDA guidance text. RPN computes automatically. At ≥ 120 the mitigation textarea becomes required. At ≥ 200 the workspace flags the action as pilot-mandatory. The entire FMEA is part of the CAPA record by default — not an afterthought, not an optional tab.

Related guides