Risk management for medical devices is a lifecycle process required by MDR Annex I General Safety and Performance Requirements 1 to 9. It identifies hazards, estimates and evaluates risks, implements controls in a strict hierarchy, and feeds post-market data back into the risk file. EN ISO 14971:2019+A11:2021 is the harmonised standard that shows how to do it. Four PowerPoint slides and an Excel sheet are not risk management.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Risk management is a legal obligation under MDR Annex I GSPR 1 to 9, not a best practice.
  • EN ISO 14971:2019+A11:2021 is the harmonised standard that turns the obligation into a process.
  • The process has six parts: planning, analysis, evaluation, control, residual risk review, and post-production feedback.
  • A spreadsheet of "tolerable or not tolerable" covers roughly five percent of what is actually required.
  • Startups that sit down for a real first pass consistently uncover hazards ad-hoc thinking never surfaces.
  • Controls follow a strict hierarchy: inherent safety by design, then protective measures, then safety by information. Labels and warnings are the last resort, not the first.
  • The risk file lives as long as the device does. Post-market data updates probabilities and severities on a defined cadence.

Why this matters (Hook)

Early in Tibor's auditing career, a company at the mid-stage of commercialisation handed over their "risk management system" during a surveillance audit. It was four PowerPoint slides. The instruction written on slide three read, in essence, "create an Excel sheet, list the risks, mark each one tolerable or not tolerable, done." Tibor's verdict then and now: those four slides represented maybe five percent of what ISO 14971 and MDR Annex I actually require. The worst part was not that it had slipped past previous auditors. The worst part was that the entire company, from engineering to top management, genuinely believed this was correct.

That gap between what founders think risk management is and what it actually is kills more startups than almost any other regulatory misunderstanding. The word "risk" is so ordinary that it does not signal how structured, continuous, and legally binding the process has to be. This post explains what risk management actually is under the MDR, why the spreadsheet approach fails, and what the first real pass looks like.

What MDR actually says (Surface)

The MDR does not contain a chapter called "risk management". The obligation is distributed across Annex I, the General Safety and Performance Requirements (GSPR). The relevant provisions for a startup reading this for the first time are GSPR 1 to 9, which together form the risk architecture of the regulation.

GSPR 1 establishes the overarching duty: devices must achieve intended performance and be safe during normal use, with risks acceptable when weighed against benefits.

GSPR 2 is the cornerstone for risk management. It requires manufacturers to establish, implement, document and maintain a risk management system across the full lifecycle of the device. The word "continuously" is doing heavy lifting. This is not a document you write once for the audit.

GSPR 3 sets out the six-part cycle: risk management plan, hazard identification, risk estimation and evaluation (for intended use and foreseeable misuse), risk control, evaluation of production and post-market feedback, and amendment of controls where necessary.

GSPR 4 introduces the binding hierarchy of risk control. In order: eliminate or reduce risks through safe design and manufacture; take protective measures; provide information for safety (warnings, labels, training). Founders do not get to jump to "we will warn the user in the IFU" when a design change would have removed the hazard.

GSPR 5 requires reduction of use-error risks, taking account of users' knowledge, training, environment, and conditions. GSPR 6 addresses lifetime: performance and safety must not degrade during the stated lifetime. GSPR 7 covers packaging and storage. GSPR 8 requires minimisation of all known and foreseeable risks, acceptable against evaluated benefits. GSPR 9 establishes the benefit-risk determination per intended purpose.

Read together, GSPR 1 to 9 describe a lifecycle system, a hierarchy of controls, a linkage to intended use and foreseeable misuse, a feedback loop, and a mandatory risk-benefit weighing. That is the statutory floor.

The harmonised standard that turns this statutory floor into a workable process is EN ISO 14971:2019+A11:2021. The Annex ZA of that standard maps every clause of ISO 14971 to the relevant GSPR in MDR Annex I, and it flags where the standard alone does not fully cover the regulation. That bridge, the Annex Z, is what makes the standard MDR-compliant when applied correctly. The trap is that ISO 14971 on its own does not always meet the MDR requirement. (Post 811 covers that trap in detail: see the ISO 14971 Annex Z trap.)

A worked example (Test)

Consider a small startup building a handheld device for home use: a reusable, battery-powered skin hydration meter intended for patients managing chronic dermatological conditions. Class IIa. Two engineers, one clinical advisor, a part-time regulatory lead.

The founders sit down for their first ISO 14971 pass. They plan a half-day workshop with engineering, the clinical advisor, a marketing representative, and an external regulatory consultant. Tibor has seen many versions of this workshop. The pattern is consistent: the cross-functional group surfaces hazards the engineers would never have written down alone.

In the session the team identifies, among others: mechanical hazards (device dropped and fragmenting), electrical hazards (battery short-circuit, thermal runaway), biocompatibility hazards (skin contact plus cleaning residue), hygienic hazards (device shared in a family, cross-contamination), use error (confusing LEDs), and foreseeable misuse (device used on broken skin).

The hygienic hazard is instructive. The instinct is to add a warning to the IFU, which is GSPR 4 level three, information for safety. But level one, inherent safety by design, would specify a disposable or easily-autoclavable tip. Level two, protective measures, might be a colour-coded single-patient indicator. The MDR hierarchy says the team must consider levels one and two first and document why they stopped at level three. "The user should read the IFU" is not a defendable answer at a notified body audit.

The biocompatibility hazard is similar. The team initially flags the risk as "acceptable" because the chosen polymer appears on an existing biocompatibility list. Tibor's experience: post-market feedback sometimes contradicts pre-market assessment. Declaring a risk acceptable on thin evidence puts the startup at the mercy of the first customer complaint about skin irritation. The fix is real testing or a documented, traceable justification a notified body auditor can follow without guesswork.

By the end of the half-day session the team has roughly forty identified hazards, of which perhaps twelve require real design decisions. None of those twelve would have appeared on a four-slide PowerPoint.

The Subtract to Ship playbook (Ship)

Felix has coached forty-four startups through early-stage regulatory work. The pattern that works for risk management on a small team and a small budget has five rules.

Rule 1: treat the risk management plan as the first deliverable, not the risk file itself. The plan defines roles, responsibilities, review cycles, acceptability criteria, and the link between risk management and other processes (design control, PMS, CAPA). If the plan is weak, everything downstream is weak. Tibor has seen five-page plans that passed audit and forty-page plans that failed, because the forty pages contained contradictions. Write the plan to be usable by the team, not to impress auditors.

Rule 2: run the first analysis as a multidisciplinary workshop, not a solo task. Tibor's consistent observation: one person with one checklist will miss half the hazards. Development engineers are blind to field conditions. Marketing is blind to technical failure modes. Clinical advisors are blind to the manufacturing tolerances that cause drift. Put them in one room for one day. Felix uses a simple subtract-to-ship move here: identify everyone who holds a piece of the truth and require each voice to speak on every hazard line. The meeting is the control.

Rule 3: force the GSPR 4 hierarchy into the risk file template itself. If your risk control column can accept "IFU warning" as a first answer, the template is wrong. Build the form so that for every control measure the team must explicitly state whether inherent safety by design was considered, whether a protective measure was considered, and why the chosen level is justified. This small structural friction prevents the single most common notified body finding in startup risk files.

Rule 4: version and lock the risk file, but budget for updates. The risk file is not a snapshot. It updates when the design changes, when production data flags a trend, when post-market feedback modifies the probability or severity of a known hazard, when the state of the art moves, and on a defined calendar cadence. Felix's rule of thumb for early startups: minimum quarterly review of the risk file in the first year post-launch. Tibor has audited companies that updated their risk file once every two to three years. In every case, real probability and severity changes had gone unnoticed.

Rule 5: build the feedback loop on day one. PMS data, complaints, trend reports, vigilance signals, service notes, and even social media chatter feed back into the risk file. Wire the feedback channel before the first unit ships. Post PMS feedback into risk management covers the operational side.

Reality Check

Use these seven questions as a diagnostic. Answer honestly. Each "no" is a gap to close before the first notified body engagement.

  1. Does your risk management plan exist as a standalone document that references GSPR 1 to 9 by name and maps each obligation to a process step?
  2. Did your first hazard analysis involve at least three different disciplines in the same room, or was it written by one person?
  3. For every risk control measure in your risk file, can you show that the GSPR 4 hierarchy was considered in order (design, protective, information)?
  4. Is every "risk accepted" entry backed by traceable evidence a notified body auditor can follow without asking a question?
  5. Do you have a defined calendar cadence for updating the risk file, and has the most recent review actually happened?
  6. Is your post-market feedback wired to trigger updates of probabilities and severities, or does PMS data live in a parallel system that never touches the risk file?
  7. If a lead auditor arrived tomorrow and asked to see the link between a specific post-market complaint and a specific risk file entry, could you produce it in under an hour?

Frequently Asked Questions

Is risk management the same thing as ISO 14971? No. Risk management is the legal obligation under MDR Annex I GSPR 1 to 9. EN ISO 14971:2019+A11:2021 is the harmonised standard that, when applied with its Annex Z mappings, gives presumption of conformity with that obligation. The regulation is the requirement. The standard is one accepted path to meeting it.

Can a Class I startup skip ISO 14971? No. MDR Annex I GSPR 2 and 3 apply to every class, Class I included. A Class I device still needs a documented risk management system, a risk file, and a feedback loop. The depth scales with risk, but the obligation does not disappear. The MDR contains no class-based exemption from risk management.

How much does a proper first-pass risk management system cost a startup? Numbers vary, but the range Tibor sees most often for a small hardware-plus-software device is roughly four to eight weeks of internal effort plus a few days of external consulting for the first pass, with ongoing effort of a few days per month thereafter. The Excel-sheet-in-fifteen-minutes approach is cheaper on paper and far more expensive in rework, audit findings, and change control after certification.

Who signs off on the risk file? The manufacturer as a legal entity is responsible. In practice a named person, typically the quality manager or regulatory lead, is assigned as risk management file owner, and top management reviews and approves at defined milestones. For startups the Person Responsible for Regulatory Compliance under MDR Article 15 is often involved in the sign-off chain. The plan must state who.

Does AI change how hazards should be identified? Emerging practice in 2026 is to use large language models as a brainstorming partner for hazard discovery, then filter and validate with human experts. Tibor considers it a legitimate augmentation and nothing more: AI can surface hazards humans miss, but a generated list is not a risk analysis. The human multidisciplinary judgment and the GSPR 4 hierarchy still apply. See risk management for AI medical devices.

What is the single biggest mistake startups make? Treating risk management as a document produced for the audit rather than a process that runs the company. When the file is written to please an auditor, it reads like fiction. When the file is written to help the team make decisions, auditors find it credible without asking.

Sources

  1. Regulation (EU) 2017/745 on medical devices (MDR), consolidated text. Annex I, General Safety and Performance Requirements 1 to 9.
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices, including Annexes ZA, ZB and ZC mapping to EU regulations.
  3. Tibor Zechmeister, notified body lead auditor experience, more than fifty certifications across Class I to Class IIb devices.