ISO 14971 Risk Files: Why an FMEA Is Never the Whole Story

Ask a device engineering team where their ISO 14971:2019 risk management file lives, and the answer is often a spreadsheet: a design FMEA, scored for severity and occurrence, sorted by RPN. It is thorough. It is also not a risk management file. ISO 14971:2019 asks for a documented plan, defined acceptability criteria, an evaluation of overall residual risk, and a production-and-post-production feedback loop — four things an FMEA was never designed to produce. Notified bodies and FDA reviewers keep finding the same gap, submission after submission, because it is the same gap.

What ISO 14971:2019 actually asks for

ISO 14971:2019 specifies a process, not a document template. A manufacturer establishes a risk management plan before analysis starts, so the criteria for what counts as an acceptable risk are set in advance rather than discovered on the way to a conclusion the team already wanted. Hazard identification covers both device failure and reasonably foreseeable misuse — the ways a device can hurt someone while working exactly as designed. Each risk is estimated and evaluated against the pre-defined criteria, controlled where necessary, and verified for effectiveness. Then comes the step an FMEA has no mechanism for at all: an evaluation of overall residual risk — the accumulated risk of the device as a whole, not a ranked list of individual line items. Finally, the file stays open: production and post-production information, including post-market surveillance data, feeds back in and can reopen a risk that was previously judged acceptable.

Where an FMEA stops short

An FMEA is a genuinely useful engineering tool, and ISO 14971:2019 does not ask anyone to stop running them. The trouble starts when the FMEA is treated as the risk management file rather than one input to it. An FMEA scores failure modes from a systems-performance view — severity, occurrence, sometimes detectability — and produces a priority order for engineering attention. It does not, on its own, ask whether the device's accumulated risk is acceptable, because it has no acceptability criteria to check against; RPN thresholds are a proxy, not a substitute. It rarely captures foreseeable misuse with the same rigor it applies to component failure. And it has no built-in path back to production or post-market data, because it was designed as a point-in-time engineering exercise, not a living file.

• A risk management plan, written before analysis begins, that defines the acceptability criteria the device will be judged against.
• Hazard identification across intended use and reasonably foreseeable misuse — not only the ways a device can fail.
• An evaluation of overall residual risk, weighing the accumulated risk of the whole device against the acceptability criteria — not a ranked list of individual risks.
• A closed loop to production and post-market surveillance data, so new information updates the file rather than sitting in a separate complaint log.

An FMEA tells you which failure mode is worst. It does not tell you whether the device, taken as a whole, is safe enough to ship. That judgment is the risk management file's job — and it is the judgment a reviewer is actually looking for. Why the distinction holds up in review

Why the gap keeps surfacing

Device engineering teams are, as a rule, good at FMEAs — the discipline is embedded in design verification and validation work long before a submission is drafted. The gap opens when "we have a risk file" quietly becomes shorthand for "we have an FMEA," and nobody revisits whether the plan, the acceptability criteria, and the overall residual risk evaluation were ever written down. Reviewers are trained to look for exactly that structure, and its absence reads as a real gap rather than a documentation preference. The stakes rose again with the QMSR-to-ISO 13485 gap: risk management is no longer a parallel expectation sitting alongside 21 CFR Part 820 — via ISO 13485:2016 clause 7.1, it is inside the same regulation FDA inspects against.

None of this asks a team to discard work it has already done well. It asks for the four pieces an FMEA was never built to supply, wrapped around the FMEA's genuinely useful output. Our risk management and ISO 13485 and ISO 14971 quality system work exists for exactly this gap — a delta assessment against the full ISO 14971:2019 structure, run before a notified body or FDA reviewer finds what the FMEA left out.