Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Template: Risk Management Plan

At last, here is the Risk Management Plan Template.

The risk management plan was missing in my list of templates. Error repaired! It is tailor made for software medical devices. So you'll find some stuff specific to software, with references to IEC/TR 80002-1 and IEC 62304.


Basically, this template deals with ISO 14971 and sections about risk management of IEC 62304. Use it to answer to those requirements of these standards.

During design and after design

Risk assessment doesn't stop after design. I usually split risks in 3 categories:

  1. Risks linked to the device itself: its intended use, its characteristics affecting the safety,
  2. Risks linked to the design process,
  3. Risks linked to other processes after design.

These risks are essentially mitigated by the quality management system of the company.

Risks linked to the design process

Examples of risks are: wrong design, buggey tools used for design.
Procedures, like Design procedure and forms, aim at defining a structured design process.
This is the main goal of all templates I've published: to mitigate risks of having a bad design process.
However, even if the design process is correct, the tools used for design shall be verifed. This is a subset of risks in design process: the risks of having bad tools for design (imagine the consequences of a "buggey" bug repository). I will address these very specific risks in a further post.

Risks linked to the device itself

Procedures, forms (like the risk management plan and the Risk Analysis Report) aim at identifying and mitigating risks linked to the device.
I address these kind of risks in the first part of my risk management plan.

Risks linked to other processes after design

The second part of my risk management plan addresses the maintenance of the risk analysis report after design. This is classical in risk management, but this second part contains an additional section.
Procedures and forms, like Production, Delivery, CAPA, post-market surveillance, address risks after design.
However, you may have risks specific to a device or a family of devices, which may require mitigation actions after design. For example, You may sell a software with customer input data different from those required by your other software. These input data may require a verification step before selling the software.
This subset of risks after design are addressed by the last section of the second part of my risk management plan.


I'd like to add a last word about this template. Like any other templates of my own, this is a cooking recipe. And like any cooking recipe, the final result may not be as delicious as what is on the photo in the cook book. If you're specialized in software, don't try to fill this template without the help of someone who is experienced in risk assessment.
You, developer, know how it is easy to write ugly code without coding experience. That's the same for risk assessment!

Stay tuned, my list of templates is growing fast!

I gather all my templates on the templates page. You'll find them all there.

Please, fell free to give me feedback on my e-mail

I share this template with the conditions of CC-BY-NC-ND license.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed