Template: Risk Management Plan and Risk Acceptance Matrix

Template Download

This is a free template, provided by OpenRegulatory.

If you are a user of Formwork, our eQMS software, choose “QMS” on the top menu and “OpenRegulatory Templates” on the left menu, and then open the relevant folder to find this template ready to load into Formwork.

If, for some mysterious reason, you’re using a different QMS Software, you can also simply download this template – specifically, as Word (.docx), PDF, Google Docs or Markdown file. Scroll down for a preview!

The template license applies (don’t remove the copyright at the bottom).

Tired of copy-pasting? If you want to save time and edit these templates directly, you can use Formwork, our eQMS software. And if you’re looking for step-by-step instructions for filling them out, check out our Wizard 🙂

Don't Miss Updates to This Template
Subscribe to our newsletter and we'll keep you posted on which templates we've changed.

Questions? Still Lost in Regulation?

Good news! Our goal is to provide lots of stuff for free, but we also offer consulting if you need a more hands-on approach. We get stuff done really fast. Have a look!

Template preview

The Risk Management Plan contains the risk policy and defines the criteria for risk acceptance. It also references relevant processes and activities which will be conducted for product-specific risk management as part of the integrated software development process (SOP Integrated Software Development).

Mapping of Standard Requirements to Document Sections

ISO 14971:2019 SectionDocument Section
4.11
4.21.2, 3
4.3(Records of competence are kept as Part of QMS)
4.4(all)
4.5(all)
5.11.1
7.21.3
10.11.4

1. Relevant Processes

1.1 Risk Management Process and Activities

Risk Management Activities are integrated in the software development lifecycle as described in SOP Integrated Software Development.

1.2 Risk Policy and Risk Acceptability

The following policy establishes criteria for risk acceptability following ISO 14971:2019 and ISO/TR 24971:2020. It applies to all people and activities involved in the design, development and distribution process of the medical device, and intends to ensure highest levels of medical device safety consistent with stakeholder expectations.

The manufacturer defines framework criteria for risk acceptability in the form of estimated usage, severity of harm and probability of occurrence (para. 1.2.1 – 1.2.3). The criteria are initially defined as part of the early software development process and reviewed during every post-market surveillance cycle.

Estimated usage, categories of severity / probability and risk matrix acceptance are defined based on applicable regulatory requirements, relevant international norms and standards, as well as the generally acknowledged state of the art (e.g. accepted results of scientific research, reports published by authorities, established industry best practices).

Acceptability for individual risks always must be established based on both, the estimated severity and the estimated probability of a risk. The risk is deemed acceptable based on a combination of both, following the risk matrix defined in para. 1.2.4.

All identified risks must be reduced as far as possible (AFAP) without adversely affecting the benefit-risk-ratio. Risk control measures implemented to reduce the risks must be chosen in the following order:

  1. Inherent safety by design
  2. Protective measures
  3. Information for safety

Acceptability of the overall residual risk is established as part of the clinical evaluation process by weighing benefits from intended use against the overall residual risk. Benefits may be described by their magnitude or extent, the probability of experience within the intended patient population, the duration and frequency of the benefit. For example, the manufacturer may compare the device to similar medical devices available on the market: residual risks can be compared individually to corresponding risks of the similar device, considering differences in intended use. The overall evaluation of the benefit-risk-ratio should take into account knowledge of the intended medical indication, the generally acknowledged state of the art in technology and medicine, and the availability of alternative medical devices or treatments.

1.2.1 Estimates for Usage

Define estimates for how much you think your device is going to be used in the market.

UsageValues
Product life spanEnter number of years you expect the device to be in the market (from design conceptualization to decommissioning)
UsersEnter number of estimated users here
Usages / userEnter number of estimated times the device is used per user
Total usagesDo the math!

1.2.2 Severity of Harm

Define what can go wrong with your product here. Make the examples specific – chances are, your product can’t cause skin lacerations. In all likelihood it also doesn’t cause death. So, feel free to remove severity rows here. But most importantly, customize the definitions and examples so that they resemble the harms in your product.

SeverityDefinition and Examples
S1: NegligibleMinor, reversible damage, e.g. superficial skin irritation, delay of non-critical treatment
S2: MarginalMinor, reversible damage with required medical intervention, e.g. skin laceration requiring stitches
S3: CriticalMajor, irreversible damage with required medical intervention, e.g. irreversible deterioration of disease
S4: CatastrophicDeath

1.2.3 Probability of Occurrence

Define your probabilities. You can probably just use these definitions. The idea is that each probability row is 10^2 apart from adjacent ones.

Also, change the “Estimated Maximum Event Count”. That’s the usage number you estimate for your (not yet released product) during its entire lifecycle (which you need to define). So, if you assume that your product will be on the market for 4 years and that it’ll be used 100 times per day, that results in 146.100 usages (100 usages/day * 365.25 days/year * 4 years). The numbers in the lower columns of “Estimated Maximum Event Count” are simply the total usage number multiplied by the upper limit probability of the same row, e.g. you want to know “how often can probability P3 occur if the product is being used 100 times per day?”

ProbabilityUpper LimitLower LimitEstimated Maximum Event Count
P5: Certain110^-21000000 (change this)
P4: Likely10^-210^-410000
P3: Unlikely10^-410^-6100
P2: Rare10^-610^-81
P1: Unthinkable10^-800

1.2.4 Risk Acceptance Matrix

The most important part. You assess each severity-probability combination whether it’s acceptable for you as a company. There are no definitive rules on what’s deemed acceptable. It depends on your company’s risk policy and, more importantly, the benefits of your product which you show in your clinical evaluation. So, for example, if your product saves 10 lives per day, it might be acceptable to cause one death per day. If your product doesn’t save any lives, it might not be acceptable to cause any deaths. You get the idea, I hope.

ProbabilityS1: NegligibleS2: MarginalS3: CriticalS4: CatastrophicEstimated Maximum Event Count
P5: Certainacceptableunacceptableunacceptableunacceptable1000000
P4: Likelyacceptableunacceptableunacceptableunacceptable10000
P3: Unlikelyacceptableacceptableunacceptableunacceptable100
P2: Rareacceptableacceptableacceptableunacceptable1
P1: Unthinkableacceptableacceptableacceptableacceptable0

1.3 Verification of Risk Control Measures

Risk Control Measures are verified as described in the software development lifecycle as described in SOP Integrated Software Development.

1.4 Assessment of the overall residual risk

After determination of the Risk Control Measures any risk that could arise from the combination of the individual risks or mitigating measures is assessed. For this purpose, the probability and severity of the possible residual risk are estimated and evaluated using the existing risk matrix.

1.5 Collection and Review of Post-Production Information

Review and collection of Post-Production information is described in SOP Post-Market Surveillance.

2. Related Documents

  • SOP Integrated Software Development
  • Risk Acceptance Matrix
  • Risk Table
  • Risk Management Report

3. Roles

TitleName(s)
Risk Manager
Context / Subject Matter Expert, e.g. physician

Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

Template preview

Comments

Leave the first comment