MDR Annex I Section 3 · ISO 14971 · lifecycle control
Medical device risk management plan
The plan decides how risk will be managed before the team starts filling a risk table.
It fixes the device scope, acceptance criteria, methods, responsibilities, review gates, control verification and post-market feedback. This guide shows what to write and what evidence each section must produce.
Build the plan ↓- 01ScopeDevice · variants · lifecycleFIXED
- 02CriteriaIndividual · overall residual riskAPPROVED
- 03ActivitiesAnalyse · control · verifyOWNED
- 04FeedbackProduction · PMS · PMCFACTIVE
Every planned activity has an owner, output, criterion and review point
The direct answer
One plan must govern the risk work for each device
MDR Annex I Section 3 makes risk management a continuous, iterative lifecycle process and requires a documented plan for each device. ISO 14971 provides the process framework and expects the plan to be tailored to the product.
How the work will be done
- The device, variants and lifecycle phases within scope
- Who performs, reviews and approves each activity
- Which methods and risk acceptability criteria apply
- How controls and their effectiveness will be verified
- How production and post-market data return to the file
The completed risk analysis
- Not a list of hazards and estimated risk values
- Not the complete risk management file
- Not the final risk management review report
- Not one generic SOP copied into every technical file
- Not a static document retired when the device is released
Keep the process in the QMS and the decisions in the device plan
The corporate procedure can define the common method, terminology, risk policy and record controls. The device plan should identify the exact scope, criteria, activities, evidence, responsibilities, milestones and feedback arrangements that apply to this device.
Eight plan elements
Write a decision for every required topic
A heading without a device-specific answer is not enough. Each section should name the activity, accountable owner, planned output, applicable criterion and point of review.
- 01SCOPE
Define the device and lifecycle
Name the intended purpose, model and software versions, accessories, variants, sites, development stage and lifecycle phases covered. Explain whether one plan covers a family.
PLAN OUTPUTUnambiguous product baseline and boundaries
- 02RESPONSIBILITY
Assign authority and competence
Name the risk lead, contributors, reviewers and approvers. Include clinical, usability, software, cybersecurity, biological, production and post-market expertise when relevant.
PLAN OUTPUTNamed roles with decision authority
- 03REVIEW
Set review gates
Define reviews before evaluation begins, after major design decisions, before verification closure, before release and after important post-market information or change.
PLAN OUTPUTMilestones, reviewers and pass conditions
- 04ACCEPTABILITY
Approve objective criteria
Define severity and probability categories, individual-risk acceptance rules, treatment of non-quantifiable probability and the method for evaluating overall residual risk.
PLAN OUTPUTDecision rules approved before scoring
- 05METHODS
Choose analyses that find the hazards
Plan the methods needed for normal use, foreseeable misuse, failures and lifecycle processes. FMEA alone rarely covers every source of harm.
PLAN OUTPUTMethods, inputs, interfaces and records
- 06CONTROLS
Plan implementation and verification
State how each control will be implemented, traced and verified. Separate verification of implementation from evidence that the control actually reduces risk.
PLAN OUTPUTControl evidence and effectiveness checks
- 07RESIDUAL RISK
Plan the final evaluations
Define when benefit-risk analysis is required, how side effects and residual risks enter labelling, and how overall residual risk will be reviewed before release.
PLAN OUTPUTIndividual and overall conclusions
- 08FEEDBACK
Keep the process alive
Name production and post-production sources, review frequency, signal thresholds, escalation rules and the records that must be updated when new information changes risk.
PLAN OUTPUTPMS-to-risk feedback loop and triggers
Risk acceptability that can survive review
A coloured matrix is not the decision
ISO 14971 does not prescribe universal acceptable risk levels. The manufacturer establishes objective criteria based on its risk policy, applicable requirements, generally acknowledged state of the art and the device’s benefit-risk context.
Make categories reproducible
Describe severity using consequences of harm and probability using defined ranges or defensible qualitative categories. State how multiple event probabilities are combined.
Apply the approved rule
Determine whether the estimated risk meets the criterion. When probability cannot be estimated, use the pre-approved qualitative decision method rather than inventing a convenient number.
Start with safer design
Apply inherently safe design and manufacture first, then protective measures, then information for safety and training. A warning does not replace a practicable design control.
Check new hazards and the whole profile
Verify implementation and effectiveness, evaluate risks introduced by controls, assess individual residual risks and make a separate overall residual-risk conclusion.
Adjust depth to the actual device
The framework stays stable while the activities change
Select a profile to see what should be added to the common plan. These examples are prompts, not exhaustive requirements or substitutes for device-specific analysis.
Start from intended use and reasonably foreseeable misuse
Plan hazard identification across transport, storage, installation, use, maintenance and disposal as applicable. Include design, production, usability, clinical, labelling and post-market inputs.
- ANALYSE
Hazards, sequences of events, hazardous situations and harms
- VERIFY
Implementation and effectiveness of every risk control
- MONITOR
Complaints, incidents, trends, literature and production data
Connect risk to architecture, lifecycle and cybersecurity
Cover incorrect output, delayed or missing information, data integrity, interoperability, user interface, updates and security threats. Plan risk-control traceability into requirements, architecture and tests.
- ANALYSE
Software contribution to hazardous situations, including normal use
- VERIFY
Unit, integration, system, usability and security control evidence
- MONITOR
Vulnerabilities, anomalies, field versions and update impact
Plan specialist analyses and process controls
Address sterility, packaging integrity, transport, shelf life, electrical and mechanical safety, energy delivery, alarms, maintenance and essential performance as relevant to the design.
- ANALYSE
Process, energy, contamination, degradation and use-related hazards
- VERIFY
Validation, essential performance and protective measures
- MONITOR
Bioburden, process deviations, service data and alarm events
Strengthen clinical and overall residual-risk review
Plan robust links to clinical evaluation, biological safety, lifetime performance, PMCF and benefit-risk endpoints. Define management review and escalation for serious residual risks.
- ANALYSE
Long-term harms, failure consequences and clinical uncertainties
- VERIFY
Pre-clinical, clinical, lifetime and worst-case evidence
- MONITOR
PMCF, registries, PSUR signals and long-term outcomes
Convert the plan into records
Every planned statement needs a closure record
The plan is useful only when the resulting evidence can be traced. Use the matrix below as a minimum cross-check between planned work and the records that close it.
Responsibility model
Risk management is coordinated by one owner and performed by a team
Use names or controlled role titles. “Cross-functional team” is not enough unless the plan shows who supplies each input, who accepts each output and who has authority to stop release.
Risk management owner
Maintains the plan and file, facilitates analysis, tracks actions and prepares the review report.
Engineering and software
Define risk controls in requirements and architecture, implement them and provide verification evidence.
Clinical and medical
Confirm harms, severity, benefits, state of the art, side effects and clinical acceptability.
Usability and training
Analyse use scenarios and foreseeable misuse, validate user-interface controls and safety information.
Quality, production and supply
Control process, supplier, inspection, packaging, storage and transport risks and production feedback.
PMS, vigilance and service
Collect and assess complaints, incidents, trends, literature, PMCF and service or cybersecurity signals.
Regulatory, PRRC and management
Verify legal alignment, resources and escalation. Approve decisions at the authority level defined by the QMS.
Lifecycle updates
Do not wait for the annual review
Set scheduled reviews, but also define events that immediately return the plan or risk file for impact assessment.
New user, indication or claim
Population, environment, intended benefit, contraindication, duration or reasonably foreseeable misuse
Product or software change
Material, component, architecture, algorithm, interface, accessory, packaging, shelf life or version
Site, supplier or production change
Critical supplier, outsourced process, sterilisation, inspection, transport, maintenance or service
New state of the art
Regulation, standard, common specification, guidance, clinical practice or alternative technology
New safety or performance signal
Complaint, incident, trend, CAPA, recall, literature, PMCF, registry or cybersecurity vulnerability
Changed benefit-risk profile
New benefit evidence, side effect, severity, frequency, uncertainty or overall residual-risk concern
- 01DetectCapture the event
- 02AssessIdentify affected risks
- 03ActChange controls if needed
- 04VerifyConfirm effectiveness
- 05ReconcileUpdate linked records
Seven common plan failures
Correct the method before evaluating the risks
These weaknesses create inconsistent scoring, missing evidence and late rework. They are easier to correct in the plan than after verification or market release.
A generic scope
Name the exact device baseline, variants, lifecycle phases and family rationale.
Undefined matrix terms
Define probability ranges, severity consequences, boundaries and decision rules.
FMEA as the only method
Add methods for hazards in normal use, use error, clinical use and relevant technologies.
Warnings chosen first
Document why safer design and protective measures are not sufficient or practicable.
No effectiveness check
Plan evidence that the implemented control reduces risk, not merely that it exists.
No overall conclusion
Evaluate the combined residual-risk profile separately from individual risk rows.
No route back from PMS
Define sources, thresholds, owners, review frequency and affected record updates.
A usable document structure
Twelve sections for a lean risk management plan
The order can follow your QMS. What matters is that the approved plan answers these questions before the corresponding work is performed.
- 01
Document control
Identifier, revision, effective date, authors, reviewers, approvers and change history
- 02
Device scope
Purpose, models, variants, accessories, configurations, sites and lifecycle coverage
- 03
References and terminology
Applicable procedures, regulations, standards, guidance and defined terms
- 04
Team and authority
Roles, competence, responsibilities, escalation and approval limits
- 05
Activities and methods
Analyses, inputs, interfaces, tools, records and traceability approach
- 06
Risk acceptability
Individual criteria, qualitative rules, benefit-risk method and overall residual-risk method
- 07
Risk-control planning
Control hierarchy, implementation, verification and new-risk assessment
- 08
Clinical and usability interfaces
Benefits, side effects, state of the art, use-related risk and information for safety
- 09
Review milestones
Gate dates, required inputs, reviewers, acceptance conditions and action closure
- 10
Production and post-production
Data sources, review frequency, indicators, thresholds and escalation paths
- 11
Change and update rules
Scheduled reviews, event triggers, impact assessment and linked-document updates
- 12
Final review and report
Plan completion, overall residual risk, production feedback arrangements and release approval
Practical questions
Risk management plan FAQ
Open the question that affects the scope, criteria, method, ownership or maintenance of your plan.
Does every medical device need a risk management plan?+
Yes. MDR Annex I Section 3 requires a documented risk management plan for each device. A single controlled plan may cover a defensible device family when the intended purpose, technology, hazards, controls and lifecycle activities are genuinely common, but the scope and any device-specific differences must be explicit.
Does a Class I device need the same plan as a Class III device?+
Both need a plan, but the depth should be proportionate to the device. A low-risk non-active Class I device may need fewer specialist analyses and review gates. An implantable, active, sterile or software device usually needs more disciplines, more specific verification activities and stronger links to clinical evaluation and post-market data.
Is a risk matrix mandatory under ISO 14971?+
No particular matrix is mandated. The manufacturer must define objective risk acceptability criteria based on its risk policy. A matrix is one possible tool, but its severity and probability categories, boundaries and decision rules must be defined and consistently applied.
Is FMEA enough for medical device risk management?+
Usually not. FMEA is useful for failure modes, but risk analysis must also cover hazards arising from normal use, foreseeable misuse, usability, biological and clinical characteristics, software and cybersecurity, production, transport, maintenance and disposal where applicable. Use the combination of methods needed for the actual device.
What is the difference between the plan, the file and the report?+
The plan states how risk management will be performed for the device. The risk management file is the organised set of records and references generated by that work. The risk management report records the final review confirming that the plan was executed, overall residual risk is acceptable and production and post-production methods are in place.
Can the team change risk acceptability criteria during development?+
Criteria should be approved before individual risks are evaluated. If new knowledge makes a change necessary, treat it as a controlled change, document the rationale, approve it at the appropriate authority level and reassess affected risks. Criteria must not be relaxed simply to make an unfavourable result pass.
When should the risk management plan be updated?+
Update it when its scope, methods, responsibilities, criteria, review gates or feedback arrangements change. Device changes, new hazards, new standards or state of the art, supplier or process changes, complaints, incidents, trends, PMCF results and new clinical evidence should at least trigger an impact assessment.
Who should approve the risk management plan?+
The manufacturer should define approval authority in its QMS. In practice, the risk management lead prepares the plan, relevant technical and clinical owners confirm their activities, quality or regulatory verifies compliance, and management approves the risk policy, resources and decisions that exceed project authority. The PRRC is not automatically the sole owner.
Primary sources
Check the current legal and technical basis
The plan must match the specific device and current requirements. ISO standards are copyrighted documents and should be obtained from ISO or an authorised national standards body.
Turn the plan into a working control system
Need a device-specific risk management plan?
MDRC can define the scope, methods and objective criteria, facilitate cross-functional risk analysis, connect controls to verification and clinical evidence, and build the production and post-market feedback loop.
