The MDR risk management process under ISO 14971 is a continuous lifecycle: plan it, identify hazards, estimate and evaluate risks, implement controls, evaluate residual risk, produce a risk management report, then feed post-production data back in. Every step lives inside Annex I GSPR 1-9 and is audited by the notified body as a whole, not as isolated documents.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I §3 requires a risk management system that runs across the whole device lifecycle, updated based on production and post-production data.
  • EN ISO 14971:2019+A11:2021 defines six linked activities: plan, analyse, evaluate, control, evaluate residual risk, report.
  • ISO 14971 Section 6 says "no further control" if initial risk is acceptable. Under MDR this is not compliant. MDR demands "as low as possible" regardless of initial acceptability.
  • The credible process is multidisciplinary brainstorming. Risk, top management, development, marketing, sales and regulatory affairs in one room.
  • Inherent safety by design comes first, protective measures second, information for safety last. Startups that jump straight to labels and warnings collect classic auditor findings.
  • AI-assisted hazard identification is emerging state of the art for finding risks human teams miss.

Why this matters

Tibor has seen this scene more than once. A founder pulls up a spreadsheet with thirty rows. Severity multiplied by probability. A traffic-light colour. A column marked "acceptable". The founder believes risk management is done. The first notified body audit then lasts three days longer than planned because the auditor can see, within ten minutes, that the spreadsheet is not a risk management process. It is the output of a risk management process that never happened.

Risk management is the hardest technical file section to fake and the easiest to under-resource. It is also the one that MDR cares about most. Every single General Safety and Performance Requirement in Annex I GSPR 1-9 traces back to risk management. If the risk file is shallow, every GSPR conclusion built on top of it is shallow. Felix has watched startups rebuild their entire technical documentation twice because the risk management process underneath it was a placeholder the first time.

The good news: the process is not mysterious. EN ISO 14971:2019+A11:2021 lays it out in clear clauses. The founder who treats it as a real engineering discipline, not a compliance chore, ends up with a device that is safer and a file that survives any audit.

What MDR actually says

MDR Annex I §3 is the anchor. It requires manufacturers to establish, implement, document and maintain a risk management system. That system must run across the entire lifecycle, be continually updated, and follow a defined process that includes: establishing and documenting a risk management plan; identifying and analysing known and foreseeable hazards; estimating and evaluating risks associated with intended use and reasonably foreseeable misuse; eliminating or controlling risks in accordance with a defined hierarchy; evaluating the impact of information from the production phase and post-market surveillance; and reviewing and updating the risk management process based on that information.

Annex I GSPR 1 then requires devices to achieve performance intended by the manufacturer and to be designed and manufactured such that, under normal conditions of use, they are suitable for their intended purpose. GSPR 2 to 9 walk through the concrete application of that principle to specific hazard families.

The harmonised standard is EN ISO 14971:2019+A11:2021. Annex ZA of the A11:2021 amendment maps the standard to MDR GSPRs and flags the gaps. There are gaps. The most important: ISO 14971 Section 6 states that if the initial risk is judged acceptable, no further risk control is required. MDR does not accept that position. MDR requires risk reduction as far as possible, period. Founders who copy ISO 14971 language into their QMS without reading Annex ZA silently inherit a non-compliance. Tibor has seen this finding surface in audits more times than he can count.

A worked example

Consider a handheld device for outpatient skin measurement. Plastic housing, display, small rechargeable battery, Bluetooth to a companion app. The development team plans a two hour risk workshop, calls it done, and moves on.

When Tibor walks the same team through a real multidisciplinary session, the hazards list triples in one afternoon. The mechanical engineer flags housing drop risk during patient handover. The biocompatibility reviewer raises prolonged skin contact. The clinical lead points out cross-contamination when the same device is handed between patients in a busy clinic. The regulatory lead adds the Annex I §14.2 electrical safety requirements. The sales representative, who actually watches clinicians use the prototype, mentions that staff routinely clean the device with alcohol wipes the materials were never tested against. The marketing lead adds a use case nobody had documented: the device sometimes lives in a patient's bag for days between visits.

Not one of those hazards was visible to a single engineer staring at a CAD file. Every one of them is real. Every one of them needs analysis, evaluation, controls and residual evaluation. This is Q5 from Tibor's own experience: the credible approach is a full team in a room, not one person with a checklist.

The spreadsheet version of risk management would have missed at least four of those hazards. The notified body would have found two of them. The market would have found the rest, and that is the expensive way.

The Subtract to Ship playbook

Felix coaches founders to run the ISO 14971 process as six linked activities, not six isolated documents. Subtract anything that does not serve the loop. Ship the loop itself.

1. Plan (Clause 4). Write a short risk management plan that defines scope, responsibilities, acceptability criteria, the methods to be used, verification activities, and how post-production information feeds back. For a startup this is typically five to eight pages. Long enough to be real, short enough that the team actually reads it.

2. Analyse (Clause 5). Identify the intended use and reasonably foreseeable misuse. List known and foreseeable hazards. Trace each hazard to the sequences of events that could cause harm. Estimate the risk for each hazardous situation. This is where the multidisciplinary workshop belongs. Tibor's rule: if the hazard list does not make the team uncomfortable, it is not finished.

3. Evaluate (Clause 6). Compare each risk against the acceptability criteria from the plan. Remember the MDR ratchet. Do not stop at "acceptable" and skip controls. MDR demands reduction as far as possible, not just under the acceptable line.

4. Control (Clause 7). Apply controls in strict hierarchy. First, inherent safety by design. Can the hazard be designed out entirely? Second, protective measures in the device itself or the manufacturing process. Third, information for safety: labels, warnings, IFU instructions, training. The third option is a legitimate control but the weakest one. Tibor's audit experience: the single most common finding is a startup that reached for a warning label when an inherent design fix was available.

5. Evaluate residual risk (Clause 8). For every implemented control, re-estimate the risk. Document the remaining residual risk. Then evaluate the overall residual risk against the device's benefits. This feeds the benefit-risk statement that lives in the technical documentation.

6. Risk management report (Clause 9). The report is the signed-off summary that the risk management plan has been implemented, that risks are acceptable, and that post-production activities are in place. This is not busy-work. It is the document the notified body reviews first.

7. Production and post-production activities (Clause 10). Define how complaints, PMS data, service records and literature are triaged and fed back into the file. This is the loop. A risk file that is not updated from field data is dead documentation.

Two additions from Felix's coaching practice. First, book the multidisciplinary workshop as a recurring calendar event, not a one-time effort. Quarterly for active development, annually in stable operation. Second, experiment with AI as a creative hazard identification partner. Feed the intended use, the device description and the environment into a capable model and ask for foreseeable misuse scenarios. The value is not in the AI being right. The value is in the AI asking questions the human team did not think to ask. Tibor rates this as emerging state of the art.

Reality Check

  1. Can the team produce the risk management plan in under sixty seconds, and does it define acceptability criteria in concrete terms?
  2. Was the last hazard identification session multidisciplinary, or was it one engineer at a keyboard?
  3. Does the risk evaluation apply the MDR "as far as possible" ratchet, or does it stop at the ISO 14971 acceptability line?
  4. For every risk control in the file, can the team point to the level in the hierarchy (inherent, protective, information) and justify why a higher level was not possible?
  5. Is residual risk evaluated for every implemented control, and is overall residual risk tied back to the benefit-risk statement in the technical file?
  6. Is the risk management report signed, dated, and less than twelve months old?
  7. Is there a documented path by which PMS signals, complaints and field service data update the risk file, with evidence the path has actually been used?
  8. Has the team tried AI-assisted hazard identification, even once, as a check on their own blind spots?

Frequently Asked Questions

Is ISO 14971 mandatory under MDR? Not mandatory by name. MDR does not cite any standard directly. But EN ISO 14971:2019+A11:2021 is harmonised, which means following it gives presumption of conformity for the risk management GSPRs in Annex I. In practice every notified body expects to see ISO 14971 as the backbone of the risk file.

How is the MDR "as far as possible" rule different from ISO 14971 ALARP? ALARP means "as low as reasonably practicable" and allows cost-benefit trade-offs on risk reduction. MDR demands reduction as far as possible without requiring practicability balancing at the acceptability threshold. Annex ZA of EN ISO 14971:2019+A11:2021 flags this gap. Founders must follow the MDR wording, not the ISO 14971 wording, when the two diverge.

Who owns the risk management process in a small team? Typically the PRRC or a senior engineer with authority over design decisions. The owner runs the process but does not do it alone. The multidisciplinary workshop is the work itself. One person producing a risk file in isolation is the failure pattern Tibor sees most often.

How often should the risk file be updated? Whenever something changes: a design revision, a new use scenario, a complaint, a PMS signal, a literature update on a similar device, a new standard edition. In stable operation, at minimum annually as part of the management review. Files updated every two or three years are not MDR compliant.

Can a spreadsheet be the risk management file? A spreadsheet can be part of the file, typically the hazard table. It cannot be the whole file. The plan, the analysis rationale, the control justification, the residual risk evaluation and the report are narrative documents. Tibor's worst audit story in this area starts with four PowerPoint slides. It could equally start with one Excel sheet.

Does AI-assisted risk identification count as compliant? The standard does not prescribe the technique. It prescribes the outcome: known and foreseeable hazards identified, documented, evaluated and controlled. AI as a brainstorming partner is allowed and increasingly common. The human team still owns the decisions, the rationale and the sign-off.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3, GSPR 1-9, Annex II §5.
  2. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices, Clauses 4-10 and Annex ZA.
  3. MDCG guidance on Annex I GSPR and risk management practice, referenced via Annex ZA of EN ISO 14971:2019+A11:2021.