The Risk Management Plan and File

The Risk Management Plan and File: From Recipe to Product Safety Evidence

1. Introduction — From System Rules to Product Execution

In the earlier article, we explored why the Quality Management System sets up the foundation for effective risk management. The QMS defines governance, responsibilities, and consistency. It answers how risk management is performed across an organization.

The next step is where many organizations begin to struggle.

Regulators do not assess safety at the system level alone. They assess how risk is managed for a specific product. That assessment is based on two closely related artifacts: the Risk Management Plan and the Risk Management File.

The Risk Management Plan defines intent.
The Risk Management File shows execution.

Together, they form the bridge between policy and product reality.

2. The Risk Management Plan as the Recipe

The Risk Management Plan is best understood as a recipe. It defines how risk management will be performed for a specific product before the work begins.

Just as a recipe specifies ingredients, steps, and sequencing, the Risk Management Plan defines:

• The scope of the product and lifecycle phases covered.

• The risk acceptability criteria

• The risk management techniques that will be used

• When and why those techniques are applied.

• How risk information will be reviewed, updated, and maintained

ISO 14971 places explicit responsibility on the manufacturer to select and justify risk management techniques. The Plan is where that justification lives. It explains why certain techniques are right for this product and why others are not.

A weak Plan leads to inconsistent execution. A strong Plan creates alignment before analysis begins.

3. What the Risk Management File Really Is (and Is Not)

If the Risk Management Plan is the recipe, the Risk Management File is the prepared meal.

The Risk Management File is not a single document. It is a structured collection of records that show how the Plan was executed for one product across its entire lifecycle. It includes hazard identification, risk analyses, risk control decisions, verification evidence, residual risk evaluations, and post-market feedback.

The File is always product-specific. Copying a Risk Management File from another product, even a similar one, breaks the fundamental link between risk ownership and product reality.

Equally important is what the File is not. It is not frozen at design transfer. It is not interchangeable with the Risk Management Plan. And it is not a static compliance artifact. It is living evidence that risk is actively managed.

4. How the Plan Drives the File

The most common audit weakness related to risk management is misalignment between the Plan and the File.

The Risk Management Plan answers questions such as:

• Which risk management techniques will be used and when?

• How hazards will be found early

• How high-severity risks will be analyzed differently from low-risk items.

• How post-market data will be fed back into risk decisions.

The Risk Management File must then show clear evidence that these commitments were followed.

If the Plan states that top-down analysis will be used for high-severity hazards, the File should contain those analyses. If the Plan states that post-market trending will trigger reassessment, the File should reflect those updates.

When auditors question a Risk Management File, they are often testing whether the File looks accidental or intentional. Alignment with the Plan is what proves intent.

5. The Risk Management File Across the Product Lifecycle

The Risk Management Plan is created early and evolves as needed, but the Risk Management File grows continuously.

During concept and feasibility, the File is driven by early hazard identification and high-level assumptions defined in the Plan. At this stage, incompleteness is expected and acceptable.

During design and development, the File expands to include detailed analyses, risk control selections, and verification evidence. The Plan guides which techniques are appropriate as design maturity increases.

At production release, the File reflects a stable design and documented residual risks that have been reviewed and accepted according to the criteria defined in the Plan.

Once the product is commercialized, the Plan continues to drive how new information is evaluated, while the File captures the results of that evaluation.

6. Risk Management Techniques by Lifecycle Phase

One of the most important roles of the Risk Management Plan is technique choice.

Different lifecycle phases require different types of risk insight. Early phases prioritize completeness. Later phases require confirmation and evidence.

The Plan defines which techniques are right at each phase and why. The File then documents their application. Together, they prevent over-reliance on a single method such as FMEA and encourage intentional layering of techniques.

A structured overview of technique choice across the lifecycle is captured in the Master Risk Technique Matrix, which serves as a navigation tool rather than a checklist. Its purpose is to support thoughtful choice, not mechanical compliance.

7. Traceability as the Spine of the RMF

Traceability is where the Risk Management Plan and File truly converge.

The Plan defines what must be traceable.
The File shows that traceability exists.

A strong RMF allows a reviewer to follow a clear path from hazards to hazardous situations, from risk controls to verification, and from residual risk decisions back to defined acceptability criteria.

This traceability is not about tables or tools. It is about supporting a coherent risk narrative that stays intact as the product evolves.

8. Post-Market Surveillance as Plan Execution

Post-market surveillance is where the Risk Management Plan is tested against reality.

The Plan defines how post-market information will be evaluated, what thresholds trigger reassessment, and who is responsible. The Risk Management File then records how those rules were applied to actual data.

Complaints, trending, and CAPAs do not live outside the RMF. They confirm or challenge assumptions made earlier in the lifecycle. A mature organization treats post-market surveillance as evidence that strengthens the File over time, not as a separate quality obligation.

9. Risk Management at Product Retirement

The Risk Management Plan does not expire when a product is discontinued. It defines how risk responsibility continues if devices are still in the field.

The Risk Management File at retirement documents how remaining risks are monitored, how service obligations are managed, and how safety communication is handled. Regulators expect to see that risk ownership was supported intentionally through end of life, not abandoned at last shipment.

10. Common Plan and File Failures Seen in Audits

Audit findings often trace back to one of three issues:

• The Plan is generic and disconnected from the product.

• The File does not follow the Plan.

• Post-market data exists but never feeds back into risk decisions.

These are not documentation problems. They are planning and intent problems.

11. Summary — Recipe, Execution, and Evidence

The Risk Management Plan and Risk Management File serve different but inseparable roles.

The Plan is the recipe. It defines how risk will be managed, which techniques will be used, and how decisions will be made.

The File is the execution. It proves that the recipe was followed and adjusted intelligently as new information appeared.

Strong risk management does not come from templates.
It comes from intentional planning and disciplined execution, showed clearly at the product level across the entire lifecycle.

The QMS sets the rules.
The Risk Management Plan defines the recipe.
The Risk Management File tells the product’s safety story.

Here is a bonus link:

NoioMed’s Master Risk Technique Matrix