---
title: Writing a Risk Management Plan Under MDR
description: The risk management plan MDR ISO 14971 requires: scope, acceptability criteria, verification, post-production activities. With a startup-sized template.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: risk management plan MDR ISO 14971
canonical_url: https://zechmeister-solutions.com/en/blog/risk-management-plan-iso-14971
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Writing a Risk Management Plan Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The risk management plan under MDR and EN ISO 14971:2019+A11:2021 Clause 4.4 must define scope, responsibilities, risk acceptability criteria, the activities for risk control verification, and the post-production activities. For a startup it is typically five to eight pages and it is the document the notified body reads first.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- EN ISO 14971:2019+A11:2021 Clause 4.4 lists the mandatory contents of the risk management plan.
- The plan must name the device and life-cycle phases in scope, assign responsibilities, define criteria for risk acceptability, describe verification of risk controls, and describe collection and review of production and post-production information.
- Acceptability criteria that do not reflect the MDR "as far as possible" rule fail audit on the first review.
- The plan is not the risk management file. It is the contract the team writes with itself before doing the analysis.
- A startup-sized plan is typically five to eight pages. Anything shorter is a placeholder. Anything over twenty pages is usually copied from a template nobody reads.

## Why this matters

Tibor has read hundreds of risk management plans. The ones that predict audit trouble share a pattern: they are long, they are generic, and they could belong to any device made by any company. The auditor flips the first page, reads the scope, and already knows the file underneath will also be generic.

The good plans are shorter, they name the device, they name the team members by role, and they make one specific promise: here is exactly how we will decide whether a risk is acceptable, and here is exactly what we will do when the field tells us we were wrong. That specificity is the plan's whole point. Felix calls it the contract the team writes with itself. The plan is a commitment, made before the hazards are visible, about how the team will behave when the hazards appear.

For a startup the risk management plan is also the first filter on scope creep. Once the plan says what is in and what is out, the hazard workshop cannot wander into features the device does not have. The plan subtracts the optional and ships the essential.

## What MDR actually says

MDR Annex I §3(a) requires the manufacturer to establish and document a risk management plan for each device. The plan is the formal starting point of the risk management system that §3 requires across the whole lifecycle.

EN ISO 14971:2019+A11:2021 Clause 4.4 is the concrete specification. The plan must include, at minimum: the scope of the risk management activities, identifying and describing the medical device and the life-cycle phases for which each element of the plan is applicable; the assignment of responsibilities and authorities; requirements for the review of risk management activities; criteria for risk acceptability, based on the manufacturer's policy for determining acceptable risk, including criteria for accepting risks when the probability of occurrence of harm cannot be estimated; a method to evaluate the overall residual risk and criteria for its acceptability; activities for verification of the implementation and effectiveness of risk control measures; and activities related to the collection and review of relevant production and post-production information.

Annex ZA of the A11:2021 amendment flags the MDR gaps in the base standard. Two matter for the plan. First, the acceptability criteria must reflect the MDR rule that risks are to be reduced as far as possible, not merely to an acceptable threshold. Second, the benefit-risk determination must apply the MDR framing from Annex I GSPR 1 and 8, not a free-standing ISO 14971 calculation.

## A worked example

Consider a Class IIa wearable that monitors heart rate variability and pushes data to a companion app. The founder's first-draft plan is three pages long and says "acceptable risk is defined as risk below the green line in the matrix". That is not a criterion. That is a reference to a colour on a chart nobody has drawn yet.

Tibor's rewrite gets specific. Scope: the wearable hardware, the firmware, the companion app, the charging dock, lifecycle from design through post-market. Responsibilities: PRRC owns sign-off, lead engineer owns hazard identification, clinical lead owns use scenarios, QA owns verification evidence. Acceptability criteria: every individual risk must be reduced to the lowest level achievable by inherent safety by design and protective measures before information for safety is considered; any residual risk where severity is catastrophic is acceptable only if the benefit is documented clinical benefit for the target indication and cannot be obtained by another means; probability estimates unreliable below 1 in 10,000 per use must default to the higher category. Verification: every implemented control must be traced to a design verification test, a manufacturing process validation, or a usability summative result. Post-production: complaints, software crash reports, battery field returns, and app analytics are triaged monthly against the hazard list, with any signal of probability or severity change triggering a formal risk file update within thirty days.

That plan is now four pages. It is also now a document the notified body can use to audit the rest of the file. Every section of the file can be checked against a promise the plan made.

## The Subtract to Ship playbook

Felix's template for a startup-sized risk management plan has eight sections. Nothing more, nothing less. Subtract the template boilerplate. Ship the eight promises.

**Section 1. Scope.** Name the device, the variants, the intended use, the lifecycle phases covered, and what is explicitly out of scope. If accessories are handled in a separate plan, say so. If the app is part of the same plan, say so.

**Section 2. References.** Cite the MDR articles and annexes that apply (at minimum Annex I §3, GSPR 1-9, and any device-specific GSPRs such as §14 for active devices or §17 for software). Cite EN ISO 14971:2019+A11:2021. Cite supporting standards: EN 62304 for software, EN 62366-1 for usability, EN ISO 10993-1 for biological evaluation where relevant. Cite internal QMS procedures.

**Section 3. Responsibilities.** Name the roles, not the people, for process ownership: PRRC, risk process owner, hazard workshop facilitator, verification evidence owner, post-production triage owner, sign-off authority. Point to the QMS organisation chart for the name-to-role mapping.

**Section 4. Risk management activities and review.** State when the risk file will be reviewed: at each design change, at each complaint triggering a CAPA, at each PMS review cycle, and at management review at a defined minimum frequency. Tibor's rule of thumb: annual at the absolute minimum, quarterly during active development.

**Section 5. Criteria for risk acceptability.** This is the most-audited section. Be specific. State the severity categories, the probability categories, and the policy that defines acceptable. State the MDR ratchet explicitly: individual risks are reduced as far as possible using the control hierarchy, regardless of initial acceptability. State how overall residual risk is evaluated against benefit. State what the team does when probability cannot be reliably estimated.

**Section 6. Verification of risk controls.** Define how the team will prove each control works. Traceability is the answer. Every control is linked to a verification test, a validation result, or a production process control. Without this section, the risk file and the design verification plan drift apart and the notified body finds the gap.

**Section 7. Production and post-production activities.** Define the feedback loop. Which data sources feed the risk file: complaints, vigilance reports, service data, app telemetry, literature on the device type, competitor field actions, PMS survey data. Define the triage cadence. Define the threshold for updating the file. Define who signs off updates.

**Section 8. Sign-off.** Dated signature of the PRRC and, where the QMS requires it, the top management authority.

Felix adds one coaching note. The plan is written before the hazard analysis starts. It is not a summary of what the team already did. If the plan is backfilled after the analysis, the criteria always look exactly like the criteria that produced the result the team wanted. Auditors can smell backfilled plans from three pages away.

## Reality Check

1. Is the risk management plan written and signed before the first hazard workshop, or is it backfilled afterwards?
2. Does the scope section name the device, the variants, and what is out of scope in plain language?
3. Does the acceptability criteria section make the MDR "as far as possible" rule explicit, rather than deferring to ISO 14971 wording?
4. Are responsibilities tied to QMS roles, with named authority for sign-off?
5. Does the verification section connect every planned risk control type to a traceable verification activity?
6. Does the post-production section name the data sources and the triage cadence, not just state that post-market data will be "considered"?
7. Is the plan short enough that the whole team has actually read it?
8. Has the plan been reviewed and re-signed within the last twelve months?

## Frequently Asked Questions

**Does every device need its own risk management plan?**
Each device or device family needs its own scope-defined plan. A platform product with variants can share one plan if the plan names each variant and any variant-specific criteria. A clearly different device needs a clearly different plan.

**How long should the plan be?**
For a startup with a single device, typically five to eight pages. Shorter than that and the mandatory contents of Clause 4.4 are almost certainly missing. Much longer and the team is probably pasting from a generic template.

**Can the risk management plan live inside the QMS procedure?**
The QMS has a risk management procedure that defines how risk management is done organisation-wide. The risk management plan is device-specific and lives in the device's technical documentation or risk file. They are two different documents.

**What happens at audit if the plan does not reflect the MDR "as far as possible" rule?**
Expect a non-conformity. Annex ZA of EN ISO 14971:2019+A11:2021 is explicit about this gap. Notified body auditors are trained to find it. Tibor has raised this finding more times than any other in the risk management domain.

**Is the benefit-risk analysis part of the plan?**
The plan defines the method and the criteria for evaluating overall residual risk against benefit. The actual benefit-risk conclusion lives in the risk management report at the end of the process and in the clinical evaluation. The plan sets the rules. The report records the result.

**Does the plan need to be updated when the device changes?**
If the change affects scope, acceptability criteria, verification approach or post-production activities, update the plan. A minor design change that does not touch those elements does not require a plan update, only a risk file update. When in doubt, update and re-sign.

## Related reading
- [The MDR Risk Management Process: Using ISO 14971](/blog/mdr-risk-management-process-iso-14971). the full six-step lifecycle the plan launches.
- [The Risk Management File: What It Contains and How to Organize It](/blog/risk-management-file-contents). the living artifact the plan anchors.
- [MDR Annex I GSPR Explained](/blog/mdr-annex-i-gspr). the requirements the acceptability criteria must satisfy.
- [The ISO 14971 Annex Z Trap](/blog/iso-14971-annex-z-trap). why copying ISO 14971 wording into the plan is a non-conformity.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3 and GSPR 1-9.
2. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices, Clause 4.4 and Annex ZA.

---

*This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*