Why your 2007-era risk file will fail EU MDR review
ISO 14971:2019 was published in December 2019 and is harmonised under EU MDR. The 2007 version is not. This distinction matters — see also our IEC 62304 guide which must align with your risk file: a technical file demonstrating conformity with a non-harmonised standard does not automatically satisfy MDR requirements.
In our documentation audits, approximately 60% of legacy risk management files we review are built on ISO 14971:2007 structure and terminology. Every one of them generates at least one major non-conformity when reviewed by an NB against the 2019 version. The good news: updating a 2007 risk file to 2019 is entirely manageable if you know what needs to change.
The five key changes in ISO 14971:2019
1. Terminology: benefit-risk analysis replaces risk/benefit analysis
The 2019 version introduces the term "benefit-risk analysis" and, crucially, makes the benefit-risk conclusion explicit: you must demonstrate that the benefits of your intended use outweigh the residual risks — not just that risks are acceptable in isolation. This shifts the required conclusion from "risks are acceptable" to "benefits outweigh residual risks."
In practical terms, your risk management report must include a section that explicitly states what clinical benefits the device provides, what residual risks remain after all controls, and a conclusion that the benefits outweigh the risks for the intended use and patient population. This conclusion must be substantiated — cross-referencing your clinical evaluation is the typical approach.
2. Explicit risk acceptability criteria — established before analysis begins
ISO 14971:2019 requires that risk acceptability criteria (the risk evaluation matrix or ALARP policy) be established and documented in the risk management plan before you begin your risk analysis. This was implied in the 2007 version but is now explicit.
Practically, this means your risk management plan must define: the probability and severity scales you will use, the risk matrix or criteria that define what constitutes acceptable and unacceptable risk, and the ALARP (As Low As Reasonably Practicable) policy for residual risks that are in the ALARP region. These criteria must be defined independently of any specific device risk — you cannot set your criteria after seeing your risk analysis results.
3. Stronger information from production and post-production requirements
The 2019 version significantly strengthens the requirements for feeding post-market data back into risk management. Your risk management process must have a defined mechanism for collecting and reviewing information from production and post-production — complaint data, vigilance reports, literature surveillance, post-market performance data — and evaluating this information for its implications on risk estimates and risk controls.
This requirement directly connects your risk management file to your post-market surveillance process. Your QMS must have a documented procedure that links PMS data review to risk management file updates.
4. Overall residual risk evaluation
Beyond evaluating individual risks, the 2019 version explicitly requires an overall residual risk evaluation — an assessment of the aggregate residual risk from all identified hazards, combinations of residual risks, and the overall benefit-risk conclusion. This is different from evaluating each risk individually and must be documented separately in the risk management report.
5. Clearer risk management report requirements
The risk management report is the culminating document — it summarises the entire risk management process, confirms that all risks have been addressed, and presents the overall benefit-risk conclusion. ISO 14971:2019 has clearer and more explicit requirements for what this report must contain, including: confirmation that the risk management plan was implemented, the overall residual risk evaluation, the benefit-risk analysis conclusion, and verification that risk controls were effective.
Software-specific risk considerations under ISO 14971:2019
For SaMD, ISO 14971 risk management must address software-specific hazards that are not present in hardware devices. The companion document ISO 80002-1 (Guidance on the application of ISO 14971 to medical device software) provides specific guidance for software risk management, including:
- Algorithmic errors: Errors in the software's logic or processing that produce incorrect outputs — incorrect diagnoses, false positives or negatives, inaccurate calculations. For AI software, this includes model prediction errors, distribution shift, and edge case failures.
- Interface hazards: Risks arising from software-hardware interfaces (for embedded software), software-user interfaces (use errors driven by poor UX), and software-software interfaces (integration errors with other clinical systems, APIs, databases).
- SOUP hazards: Risks introduced by third-party software components — library failures, known vulnerabilities in open-source dependencies, version incompatibilities.
- Cybersecurity risks: Vulnerabilities that could compromise the software's integrity, leading to incorrect clinical outputs or denial of service. ISO 14971:2019 requires cybersecurity to be part of the risk management process — MDCG 2019-16 provides more specific guidance on this for EU MDR.
- Change-related risks: Risks introduced by software updates — including unintended regression effects on previously validated functionality and performance degradation in production environments.
