ISO 14971: A Practical Risk Management Guide for Medical Devices

Why Most Risk Management Files Fail the NB Audit

The rejection rate in NB audits tied to Risk Management is consistently high — and the reason is rarely a technical gap. After reviewing hundreds of Risk Management Files over twenty-five years, the most common cause I see is definitional: the team does not correctly distinguish between three concepts that ISO 14971 defines with precision. The Deficiency Letter that follows costs months the project did not have.

Those three concepts are: Hazard, Hazardous Situation, and Harm. Let us start there.

The Core Distinction: Hazard, Hazardous Situation, Harm

ISO 14971:2019 defines them in §3 (Terms and Definitions):

• Hazard (§3.45): A potential source of harm — for example, high electrical voltage, an active biological material, laser energy.
• Hazardous Situation (§3.46): Circumstances in which people, property, or the environment are exposed to a hazard — for example, "a patient touching a conductive part of the device during an insulation fault."
• Harm (§3.49): Physical injury or damage to health, property, or the environment — for example, "an electric shock causing ventricular fibrillation."

The common error: teams write "Hazard: electric shock" — but that is Harm, not Hazard. Or "Hazard: software failure" — that is a Hazardous Situation. The NB looks for a complete, coherent chain: Hazard → Hazardous Situation → Sequence of Events → Harm. When the chain is incomplete, the Deficiency Letter arrives.

ISO 14971:2019 + Amendment 1 (2024): What Changed

ISO 14971 was revised in 2019. In 2024, Amendment 1 (ISO 14971:2019/Amd 1:2024) was published. The changes are not marginal:

• Benefit-Risk Analysis: The Amendment reinforces the requirement for explicit benefit-risk analysis — not as a checkbox at the end of the Risk Management File, but as a documented process directly linked to the MDR Annex I GSPR clauses. The NB will verify that the analysis is grounded in real clinical data, not a generic assessment.
• Post-Production Information: §10 of ISO 14971:2019 already required post-market information. The Amendment sharpens this: the Risk Management Process must include a formal feedback loop from PMCF and PMS — not just collecting information, but linking it to specific risks in the hazard table.
• Software as a Medical Device (SaMD): The Amendment clarifies that software risks — including cybersecurity risks — must be integrated into the main Risk Management File, not kept in a separate document referenced only by pointer. The NB will want to see genuine integration.
• Reasonably Foreseeable Misuse: The definition is expanded to include misuse arising from a non-intuitive user interface — relying on IEC 62366-1 integration.

Risk Management File Structure — As the NB Expects to See It

ISO 14971:2019 §4 defines the Risk Management Process but does not specify file structure. Here is the structure that has worked across the audits I have led:

1. Risk Management Plan (§4.4): A document defining scope, risk acceptability criteria, review frequency, and responsibilities. This is not a one-time document — it lives across the product lifecycle. The NB will check that the Plan is cross-referenced with your QMS SOP.
2. Intended Use + Intended Users + Use Environment: Not a general paragraph — a specific description of the patient, the user (physician? technician? home patient?), and the environment (ICU? home? clinic?). The NB will use this to verify that all identified Hazardous Situations are genuinely relevant to those specific circumstances.
3. Hazard Identification (§5.4): A complete risk table. Each Hazard → Hazardous Situation → Sequence of Events → Harm. Not "electricity — danger." Every chain complete, documented, and justified.
4. Risk Estimation (§5.5): Probability and Severity assessment for each Harm. The criterion for determining Probability must be defined in the Plan — not decided arbitrarily for each Harm.
5. Risk Evaluation (§6): Is the risk acceptable? Per the Risk Acceptability Matrix established in the Plan. This is where most teams go wrong: they use FMEA as their Risk Management — but FMEA is a tool for identifying failure modes, not for risk acceptability decisions. The NB will check that the Decision is based on a criterion defined upfront, not on ad hoc judgment.
6. Risk Control (§7): In priority order: inherently safe design → protective measures → information for safety (instructions for use). Every risk control measure must be verified as effective (§7.6) and verified as not having introduced a new risk (§7.7).
7. Residual Risk Evaluation (§8): Assessment of residual risk after controls. If residual risk still exceeds the acceptability threshold — an explicit benefit-risk analysis is required.
8. Overall Residual Risk + Benefit-Risk Analysis (§9): Comprehensive analysis. The link to the Clinical Evaluation Report (CER) is critical here — the CER provides the clinical benefit data that enables you to demonstrate that overall risk is acceptable in light of clinical benefit.
9. Risk Management Review (§4.5): Documentation of a pre-release review and documentation of ongoing reviews.
10. Production and Post-Production Information (§10): A formal procedure for collecting post-market information, analyzing it, and feeding it back into the Risk Management cycle. This is the feedback loop the Amendment reinforces.

The Link to MDR Annex I — GSPR 1 Through 9

MDR 2017/745, Annex I defines the General Safety and Performance Requirements (GSPR). Clauses 1–9 deal specifically with risk management, and the NB will check for a direct cross-reference between the Risk Management File and each of them:

• GSPR 1: The device must be safe and achieve its intended performance. The Risk Management File must demonstrate this.
• GSPR 2: Known solutions for risk reduction must be applied (state of the art). If a harmonized standard applies (such as IEC 60601-1) — its application must be documented in the Risk Control section.
• GSPR 3: The manufacturer must establish risk acceptability criteria and adhere to them. This must be in the Risk Management Plan, with a justification for why the criterion was chosen.
• GSPR 4: Known and foreseeable risks — including Reasonably Foreseeable Misuse — must be identified.
• GSPR 6: If the overall residual risk is acceptable — this must be justified in the Overall Benefit-Risk Analysis cross-referenced with the CER.

The practical point: the NB does not look at the Risk Management File and the GSPR Checklist as separate documents. It expects your Technical Documentation to connect them. If your GSPR Checklist contains only Yes/No without a pointer to the Risk Management File, you will receive a Deficiency.

The Most Common Gaps NBs Flag

From my experience as Lead Auditor at BSI Group and the companies I advise today, these are the gaps that recur consistently:

1. Post-Production Information loop is not connected: The company runs sound PMS and PMCF, but there is no written procedure defining what happens when a new signal is found — how it is fed back into the Risk Management File and what triggers a Risk Management Review.
2. Benefit-Risk Analysis is hollow: "The benefits of the device outweigh its risks" — that is not a benefit-risk analysis. The NB expects a quantitative (or at minimum semi-quantitative) analysis citing specific clinical benefit (reduced mortality by X%, improved QoL) against the defined residual risk.
3. Software treated as a reference only: "Software risks — see Software Risk Management File." Not sufficient. The NB will want to see specific software risks (including cybersecurity threats per IEC 81001-5-1) integrated into the main Hazard table.
4. Risk Control Effectiveness Verification missing: Adding a Warning to the Instructions for Use is a Risk Control per §7. But §7.6 requires you to demonstrate it is effective — typically via usability testing per IEC 62366-1. Without this, the Risk Control is incomplete.
5. Risk Acceptability Matrix defined retrospectively: Companies that define the Matrix after the risks are already known create an obvious conflict of interest. The NB will verify that the Plan (written at the start of the project) defined the Matrix before the Hazard Identification began.

FMEA: A Useful Tool — But Not Your Risk Management

FMEA (Failure Mode and Effects Analysis) is an excellent tool for identifying failure modes and analyzing their effects. But I have seen too many companies submit FMEA under the heading "Risk Management File" — and the NB catches it immediately.

FMEA does not define Hazards in the chain ISO 14971 requires. It does not include Intended Use analysis, does not define risk acceptability criteria, and does not connect to the GSPR. It can be part of the Risk Management File — as a source for identifying Hazardous Situations — but it is not a replacement for one.

The Link to the Clinical Evaluation Report

The CER and the Risk Management File are two documents that must be written in dialogue with each other. The CER — required under MDR Annex XIV — needs to provide two things to the Risk Management process:

• Clinical benefit data that enables the Overall Benefit-Risk Analysis (§9 of ISO 14971)
• Post-market clinical evidence that feeds the Post-Production Information feedback loop (§10)

When the CER is written without reference to the Risk Management File, the NB will see it. Both documents must cite each other at the level of specific risk, not just in general terms.

Quick Checklist Before NB Submission

• Every Hazard is defined as a source of harm — not as the harm itself, not as a failure mode
• Every chain Hazard → Hazardous Situation → Sequence → Harm is complete and documented
• Risk Acceptability Matrix was established in the Risk Management Plan before Hazard Identification began
• Every Risk Control Measure includes documentation of Effectiveness Verification
• Software and cybersecurity risks are integrated into the main table, not referenced externally
• Overall Benefit-Risk Analysis references specific clinical data from the CER
• A documented feedback loop exists from PMS/PMCF back to the Risk Management File
• Full cross-reference between the Risk Management File and GSPR 1–9

ISO 14971 is not a document you fill in at the end of the project — it is a process that begins on day one of development. An NB that finds a Risk Management File written "in hindsight" will request a full rewrite. I have seen it happen — and it is a 6–12 month delay that is entirely preventable.