ISO 14971: The Risk Management File and Where Files Break

A notified body reviewer does not read a risk management file from the front. They pick a hazard — usually the worst one, or the one behind a complaint — and follow it: how was it identified, how was the risk estimated, what controls were chosen and why, where is the evidence they work, what risk remains, and does the instructions for use say so. That trace is what an ISO 14971 risk management file exists to survive.

Files that survive it are built for it. Files that do not are usually thorough in the wrong places. This guide covers what the standard actually requires, the four places files reliably break, and one widely repeated error about the European version of the standard.

What ISO 14971 is

ISO 14971:2019 specifies terminology, principles and a process for applying risk management to medical devices, including software as a medical device and in vitro diagnostic devices. It is the third edition, and ISO reviewed and confirmed it unchanged in 2025 — making it one of the more settled standards in this space.

It is not optional in practice. ISO 13485 clause 7.1 requires risk management throughout product realisation. EU MDR Annex I requires a risk management system, and Annex II requires the plan and results in the technical documentation. FDA recognises the standard. Almost every route to market assumes you have done this.

The ISO 14971 deliverable is a file, not a spreadsheet

Clause 4.5 requires a risk management file for each device, and requires it to provide traceability — for every identified hazardous situation — to the risk analysis, the risk evaluation, the implementation and verification of risk control measures, and the results of the residual risk evaluation.

Two consequences that decide whether a file works.

The file is per device. One shared hazard analysis maintained across a product portfolio cannot serve as evidence for any individual device in it. Where devices genuinely share intended use, technology and risk profile, a family file is legitimate — but that is a decision to justify, not a default.

The file may be distributed, but it must be findable. Records can live in the design history file, the requirements tool, the test system. What clause 4.5 requires is that a reviewer can follow one hazardous situation through all of them, which is what a traceability matrix is for. “The records exist somewhere” is not a defence.

Hazard, hazardous situation, harm

Three different things, and collapsing them is the most common structural error in this domain:

Why it matters: risk is estimated for the hazardous situation, not the hazard. “Electrical energy” has no probability. “User in contact with a live part during routine cleaning” does. A hazard table with no sequence-of-events column cannot support a defensible estimate, and improving that one column is usually the highest-value fix available on an inherited file.

Where ISO 14971 files actually break

1. Only one of the two required verifications

Clause 7.2 requires the implementation of each risk control measure to be verified, and the effectiveness of each measure to be verified. They answer different questions:

Files with only the first are the norm. “The alarm was implemented” says nothing about whether a nurse notices it in a real environment — and for an information-for-safety control, summative usability evidence is often the only credible demonstration there is.

2. Jumping to the bottom of the control hierarchy

Clause 7.1 sets a priority order: inherently safe design and manufacture first, then protective measures in the device or in manufacture, then information for safety. The order is not advisory, and the requirement is to record the analysis — including options considered and rejected — not just the control adopted.

Warnings are the weakest control because they depend on someone reading, understanding, remembering and complying, often under time pressure. “Not practicable” is a legitimate reason to move down the hierarchy; “it was late in the programme” is not, and where cost genuinely is the constraint, a recorded commercial decision is defensible where one disguised as a technical judgement is not.

3. Treating overall residual risk as the sum of the parts

Clause 8 requires the overall residual risk of the device to be evaluated after all controls are implemented and verified, using a method and criteria defined in advance. It is a separate judgement, and it is not the maximum, the average or the total of the individual residual risks.

A device can have thirty individually acceptable residual risks and be unacceptable as a whole. The dimensions that make the difference:

• Dependency — three controls that each look robust, all relying on the same sensor, are one control.
• Cumulative user burden — do the information-for-safety controls together demand more than is realistic in the intended environment?
• Alarm load — beyond a certain density alarms stop being a control and start being silenced.
• Uncertainty — how many estimates rest on assumptions or on probabilities that could not be estimated?
• State of the art — how does the residual profile compare with comparable devices now?

4. The file that stopped at launch

Clause 10 was expanded in the 2019 edition and requires the manufacturer to actively collect production and post-production information, review it for relevance to safety, and act on it. The review asks four specific questions: is a previously unrecognised hazard present, is an estimated risk no longer acceptable, is the assessment otherwise invalidated, and has the state of the art changed.

The failure mode is near-universal: a thorough file produced for launch and no entry after it. Any reviewer will check the date of the last change before they check anything else, and the single most convincing piece of evidence a file is alive is a risk estimate that moved because of field data.

Clause 10.4 also forces a question organisations reliably defer: what, if anything, must be done about devices already released. “No action” is a legitimate answer and requires the same justification as any other. What is not legitimate is not asking.

Where probability cannot be estimated

Clause 5.5 addresses this directly, and honesty here is worth more than a fabricated number — an invented probability is treated as evidence by everyone downstream.

Where the probability of occurrence of harm cannot be estimated, record why, evaluate the risk on the consequences alone, and apply criteria set in advance for exactly this case. Clause 4.4 requires the risk management plan to include those criteria, and it is one of the plan elements most often missing. The situation then becomes a priority for post-production collection, because the field is the only place that number will ever come from.

The A11 amendment, correctly

Suppliers and consultants routinely write “ISO 14971:2019/A11:2021” as though ISO issued an amendment. ISO did not.

An A11 amendment in CEN practice changes annexes and the foreword, not technical content. The clauses are the same clauses. What A11 adds is Annex ZA, which maps the standard to the General Safety and Performance Requirements in MDR Annex I and is what confers presumption of conformity.

Two practical consequences. If you place devices on the EU market you need the EN version including A11 — a December 2019 European print without A11 does not contain Annex ZA. And presumption of conformity depends on the reference being cited in the Official Journal, a list that has been amended roughly twice a year since 2021. Cite the Implementing Decision and the date you checked; an undated conformity claim cannot be verified by anyone, including you.

Machine learning devices

ISO published ISO/TS 24971-2 in June 2026 — guidance on applying the ISO 14971 process to machine-learning enabled medical devices. It is the newest document in this area, and it sits alongside the long-standing ISO/TR 24971 general guidance, which is itself being restructured into a multi-part series.

The hazards that need prompting for are distinct: training data unrepresentative of the intended population, performance that is excellent in aggregate and poor in a subgroup, data and performance drift after deployment, automation bias, opacity that leaves a clinician with no basis to override, and behaviour on inputs outside the training distribution.

Two points matter more than the list. Put ML hazards in the same hazard analysis as everything else — a separate “AI risk assessment” produces a file that cannot be traced and an overall residual risk evaluation that omits half the device. And do not substitute validation-set performance for field probability; a metric measured on curated data is not a probability of harm in service. Organisations building AI governance more broadly will recognise the pattern from ISO 42001, but the device risk file is where it has to land.

How ISO 14971 fits with your other files

Risk management is not standalone, and the commonest mess is duplication. The rule worth adopting: one record, one home. Where a record lives in the quality system, the risk file references it.

Where to start

Three things come before any hazard is written down. Decide which devices are in scope and how they group. Issue the policy — clause 4.2 asks for a policy for establishing criteria for risk acceptability, not the criteria themselves. Then fix the criteria, in advance, because criteria written after the estimates describe the estimates and nothing ever fails them.

Our ISO 14971 Toolkit covers that sequence with 44 editable templates across eight sections — the policy and acceptability criteria, the per-device plan and file index, intended use and misuse, safety characteristics, hazard identification and estimation, the control hierarchy with option analysis, benefit-risk analysis, overall residual risk, the production and post-production loop, and the audit and evidence pack. It marks every document as written-once or per-device, and includes the EU Annex ZA supplement and the machine learning supplement.

For the quality system that clause 7.1 sits inside, see the ISO 13485 Toolkit.

Frequently asked questions

What is the current version of ISO 14971?

ISO 14971:2019, the third edition, published in December 2019. ISO reviewed and confirmed it in 2025, so it remains current with no revision in progress.

Is ISO 14971:2019/A11:2021 an ISO amendment?

No. ISO published no amendment. EN ISO 14971:2019/A11:2021 is a CEN amendment to the European adoption, adding the European foreword and Annex ZA — the mapping to EU MDR requirements. The technical requirements are unchanged.

Do I need ISO 14971 if I already have ISO 13485?

Yes. ISO 13485 clause 7.1 requires risk management throughout product realisation and points to ISO 14971 for how. The quality system does not contain the risk management file; it requires one.

What is the difference between residual risk and overall residual risk?

Residual risk is what remains for one hazardous situation after its controls. Overall residual risk is a separate evaluation of the device as a whole, against its own criteria, considering dependencies between controls, cumulative user burden and comparison with the state of the art. It is not the sum of the individual residual risks.

Does ISO 14971 apply to software and AI devices?

Yes, including software as a medical device. ISO/TS 24971-2:2026 provides guidance for machine-learning enabled devices, to be used in conjunction with ISO 14971 rather than instead of it.

How long must a risk management file be kept?

For the lifetime of the device and, in any case, for the period required by the markets you serve — commonly ten years after the last device is placed on the market, and longer for implantable devices. Record the applicable requirement rather than assuming the shortest.