Question Clearly sourced

Expert knowledge for digital decisions

What does ISO 14971 require for risk management in medical software?

Short answer

ISO 14971:2019 requires a documented risk management process throughout the entire product lifecycle: identify hazards, assess risks, implement controls, evaluate residual risks, and incorporate insights from production and market observation. The standard does not specify a universal risk threshold; the manufacturer must establish objective acceptance criteria.

An Ongoing Process Rather Than a One-Time FMEA

ISO 14971:2019 describes risk management from the initial product idea to decommissioning. For medical software, this means that risks are not only collected shortly before CE marking but are linked with requirements, architecture, testing, changes, cybersecurity, and market observation. Annex I number 3 of the MDR also requires a continuous, iterative risk management system for each product.

At the beginning is a risk management plan. It defines responsibilities, review steps, criteria for risk acceptance, methods for assessment, as well as the collection and evaluation of production and post-market data. The criteria must be defined before the assessment; the standard deliberately does not specify a universal acceptable numerical value.

From Hazard to Residual Risk

The core process according to ISO 14971:2019 includes:

  1. describe intended use and reasonably foreseeable misuse,
  2. identify safety-related characteristics and hazards,
  3. model hazardous situations and potential harms,
  4. assess and evaluate risks based on established criteria,
  5. select, implement, and verify the effectiveness of risk control measures,
  6. evaluate remaining individual risks and the overall residual risk,
  7. weigh benefits against residual risk if necessary,
  8. continuously evaluate production and post-market information.

The control hierarchy starts with inherently safe design. Only after that come protective measures and finally safety information. In software, this can mean, for example: architecturally preventing hazardous states, validating inputs, creating a safe fallback level, and clearly communicating remaining limitations. A warning notice does not replace a technically feasible risk reduction.

Traceability Makes the File Robust

Every control should be traceable to the affected hazard, a requirement, and a verification proof. New insights from support, security vulnerabilities, error reports, or clinical use can change the original assessment and must flow back into the risk file, testing, and, if applicable, clinical evaluation and user information.

In the EU, EN ISO 14971:2019 including A11:2021 is listed as a harmonized standard. Its application is voluntary; it can provide a presumption of conformity for covered MDR requirements. It does not replace the MDR or a product-specific assessment but offers the recognized process framework.

Example from practice

In a dosing software, not only "incorrect calculation" is noted. The cause, output value, clinical usage context, potential harm, risk control, and the test that demonstrates the effectiveness of this control are documented.

Key facts

Current Edition
ISO 14971:2019, 3rd Edition
EU Version
EN ISO 14971:2019/A11:2021
Duration of Validity
Entire product lifecycle
MDR Reference
Annex I number 3 MDR

Sources

All external claims are backed by traceable sources.
  1. 01
    ISO 14971:2019 – Application of risk management to medical devices International Organization for Standardization (ISO)
  2. 02
  3. 03

Ready for your next project?

Free initial consultation - no sales pressure, just clear answers.

Request consultation