This guide covers what goes into a risk management plan, how to structure it to satisfy ISO 14971:2019, and the most common mistakes that cause plans to fall short during notified body audits and FDA QMSR inspections.

What the risk management plan is and is not

The risk management plan is a planning document. It defines the scope, responsibilities, risk acceptability criteria, and activities you will carry out throughout the device lifecycle. It is not the risk analysis itself. The risk analysis, the hazard identification, probability and severity estimation, and risk control records all belong in the risk management file.

Think of the relationship this way: the risk management plan is the procedure. The risk management file is the execution record. ISO 14971 Clause 4.4 requires both. Companies that try to combine them into a single document usually end up with a document that does neither job well.

Scope of the risk management plan

Clause 4.4 of ISO 14971:2019 requires the risk management plan to define:

• The scope: which device, which intended use, what life cycle phases are covered
• Assignment of responsibilities and authorities for risk management activities
• Risk management activity requirements for each phase of the device lifecycle
• Criteria for risk acceptability, including acceptable risk levels for residual risks and for the overall residual risk
• The method for evaluating overall residual risk
• Activities to gather and review production and post-production information

Each of these elements must be explicitly documented. Plans that define scope but leave acceptability criteria vague, or that assign responsibilities without defining the activities those responsible parties must perform, are incomplete under the standard.

Defining the scope clearly

The scope section of the plan identifies what you are managing risk for. At minimum, this includes:

• The device name and model numbers or families covered
• The intended use as defined in your design input documentation
• The intended users (healthcare professionals, lay users, patients)
• The intended use environment (hospital, home, clinical lab)
• The device lifecycle phases covered: design and development, manufacturing, post-market

If the plan covers a device family, be explicit about which models are included and whether any models are excluded and why. A plan with a vague scope produces a vague risk analysis. Auditors will push on scope boundaries, asking whether specific use scenarios or user groups were considered.

Assigning responsibilities

ISO 14971 requires that top management assign responsibilities for risk management. The plan must document who is responsible for risk management activities and who has the authority to make risk acceptability decisions.

In practice, most companies designate a Risk Manager or Risk Management Lead (often a senior quality or regulatory engineer) and a cross-functional Risk Management Team that includes engineering, clinical, manufacturing, and quality representation. Top management typically approves the risk acceptability criteria and the overall risk acceptability decision before market release.

Document roles by job title, not by person name. Plans that name individuals require a plan revision every time personnel changes occur.

Risk acceptability criteria: the hardest section to get right

The risk acceptability criteria section is where most risk management plans fall short. ISO 14971 requires you to define, in advance of the risk analysis, what risk levels you consider acceptable, what requires risk control, and what is unacceptable regardless of benefits.

Clause 4.4 c) requires that acceptability criteria be based on current medical knowledge. The 2019 revision removed the “ALARP” (as low as reasonably practicable) language and replaced it with a requirement to use risk reduction measures to the extent practicable, even for risks already within the acceptable range. That change has implications for how companies write their criteria.

A practical approach to acceptability criteria:

• Use a probability-severity matrix that maps estimated probability of harm and severity of harm to a risk level (acceptable, ALARP, unacceptable)
• Define probability levels with specific quantitative descriptors where possible (e.g., “Frequent: likely to occur once per use” or probability greater than 10 to the negative 2)
• Define severity levels using a referenced classification (ISO 14971 Annex C provides a five-level severity classification)
• Define the overall residual risk acceptability criterion separately from individual risk acceptability

The criteria must be defensible. If an auditor asks why you chose a specific probability threshold, you need an answer grounded in clinical literature, regulatory guidance, or industry practice. “That’s what we’ve always used” is not an acceptable justification.

Lifecycle phases and required activities

The plan must identify what risk management activities are required in each lifecycle phase. A typical structure:

Design and development: Hazard identification, hazard situation analysis, risk estimation, risk evaluation, risk control selection and implementation, residual risk evaluation, risk-benefit analysis where required, overall residual risk evaluation.

Verification and validation: Confirmation that risk controls are effective and do not introduce new risks.

Manufacturing: Identification of manufacturing process hazards (if not already captured in design-phase analysis), supplier risk considerations, component and material risk inputs.

Post-production: Collection and review of post-market surveillance data, complaint trend analysis, field safety corrective action triggers, periodic review of the risk management file.

The post-production phase is one that many medical device companies underspecify in their risk management plans. The plan should define specifically how post-market data feeds back into the risk management file, who reviews it, at what frequency, and what triggers a revision to the risk analysis.

The risk management file

The risk management plan specifies that a risk management file must be maintained. The file is the collection of all risk management records for the device. Under ISO 14971 Clause 4.5, the file must include or reference:

• The risk management plan
• Hazard identification records
• Risk estimation and evaluation records
• Risk control measures and their justification
• Residual risk evaluation records
• Benefit-risk analysis records (where required)
• Overall residual risk evaluation
• Risk management report

The file is a living set of records, updated throughout the device lifecycle. It is referenced in the Design History File for devices that require one under FDA QMSR, and in the Technical File for EU MDR submissions.

Risk management report

ISO 14971 Clause 9 requires a risk management report to be prepared before a device is released. The report summarizes:

• The risk management plan and that it was followed
• The overall residual risk evaluation and the conclusion that it is acceptable
• The methods used for collecting and reviewing production and post-production information

This is not the same as the risk management file. The report is a summary conclusion document signed by authorized personnel before market release. It provides the formal determination that the device’s risk profile, after all controls, is acceptable for the intended use population.

Connecting ISO 14971 to FMEA

Design FMEA (DFMEA) and Process FMEA (PFMEA) are tools commonly used to support the hazard analysis and risk estimation required by ISO 14971. The standard does not require FMEA specifically, it requires hazard identification and risk estimation. FMEA is a widely used method for doing both.

Your risk management plan should specify which risk analysis tools and methods you will use. If you use FMEA, state that. If you use fault tree analysis for certain high-severity hazards, state that. The method selection should be proportionate to the complexity and risk level of the device.

The Risk Register in your QMS can serve as the living repository that aggregates risk items from FMEA, use error analysis, and other sources into a single tracked record.

Common mistakes in risk management plans

Auditors and notified bodies see the same mistakes repeatedly:

• Acceptability criteria that are copied from a template without adaptation to the specific device type or patient population
• Scope that covers the intended use but not reasonably foreseeable misuse
• No description of post-production information activities
• Responsibilities documented by name rather than role
• A plan written after the risk analysis was completed rather than before
• No link between the risk management plan and the risk management file (the plan must be traceable to the records it governs)

ISO 14971 and FDA QMSR

FDA’s QMSR (21 CFR Part 820), which became effective in February 2026, incorporates ISO 13485:2016 by reference. ISO 13485 in turn references ISO 14971 for risk management of devices. This means FDA now expects device manufacturers to maintain a risk management system consistent with ISO 14971, even if the standard is not cited explicitly in the regulation.

During FDA QMSR inspections, investigators may request your risk management documentation as part of design control review. The risk management plan and report should be readily retrievable from your quality system. If your risk management records live across multiple shared drives, spreadsheets, and standalone files, retrieval during an inspection becomes a liability.

Managing risk documentation in an eQMS

Risk management under ISO 14971 generates significant documentation: hazard analyses, risk control records, post-market review records, the risk management report. Managing these in a dedicated quality system with integrated risk management capabilities has several advantages over spreadsheet-based approaches:

• Traceability from hazard to risk control to verification record
• Automatic version control on all risk documents
• Configurable risk matrix aligned to your defined acceptability criteria
• Integration between post-market complaint data and risk file review triggers
• Electronic signature on risk management report for 21 CFR Part 11 compliance
• Full audit trail on every risk record

Cloudtheapp includes risk management and FMEA applications as part of its 60+ app eQMS platform, designed for medical device, pharma, and biotech companies. The platform supports configurable risk matrices, traceable risk control records, and integrated post-market data review, all within a pre-validated, FDA-compliant environment. Request a demo to see the risk management module.

Conclusion

A risk management plan is only as useful as the discipline behind it. The document itself is rarely what auditors find inadequate. What they find inadequate is the execution: acceptability criteria that were never applied consistently, post-market activities that were defined but never performed, and risk management files that stopped being updated after the device launched.

Write the plan before the analysis. Define your criteria with enough specificity that two different engineers applying them to the same hazard would reach the same conclusion. Then use the plan throughout the device lifecycle, updating the file as post-market data comes in and as design changes require reassessment. That is what ISO 14971 requires, and it is also what actually keeps patients safe.

This post created by and appeared first on Cloudtheapp

This post created by and appeared first on Cloudtheapp