ISO 14971 Risk Management Plan: A Clear Guide to Its Content

The ISO 14971 risk management plan is the document that decides how the rest of your
risk management will be judged — and it is written before the analysis, which is why so many teams
produce it as an afterthought and pay for it at audit.

What the ISO 14971 risk management plan is, and is not

The plan is a required deliverable of the risk management process, and it sits inside the
risk management file rather than alongside it. It is the up-front statement of how risk management
will be conducted for a specific device: who does it, against what criteria, and how you will know it
was done.

It is not the hazard analysis, and it is not the risk management report. Those come later and
record what happened. The plan records what you committed to before you started, which is exactly why
an auditor reads it first — everything else in the file is measured against it.

If your file is the thing that keeps failing rather than the plan, our guide to
the ISO 14971 risk management file covers where
files break.

ISO 14971:2019 is stable, which changes the calculus

ISO 14971:2019 is the third edition, published in December 2019, and ISO’s own record shows it was
last reviewed and confirmed in 2025 at stage 90.93. It replaced ISO 14971:2007 and it
is not currently being revised.

That matters when you are deciding how much to invest in the documentation. Unlike the ISO
management system standards currently moving through new editions, a plan written to ISO 14971:2019
today is not about to need a structural rewrite. The scope also explicitly covers software as a
medical device and in vitro diagnostic devices, so software-only manufacturers are in scope.

What the ISO 14971 risk management plan has to cover

The standard expects the plan to establish, for the device and lifecycle stage in question, the
following ground.

• Scope. Which device, which variants, and which lifecycle phases the plan covers.
  Vague scope is the most common reason a plan cannot be used as evidence.
• Responsibilities and authorities. Who performs each activity and who is
  authorised to accept residual risk. The second half is frequently missing.
• Competence requirements. What the people doing the work need to know, and how
  that is demonstrated.
• Review requirements. How risk management activities will be reviewed, and by
  whom.
• Risk acceptability criteria. The policy for deciding what is acceptable,
  including how you handle risks whose probability cannot be estimated.
• Verification activities. How you will confirm that risk controls were implemented
  and that they are effective — two separate verifications, often collapsed into one.
• Production and post-production information. The method for collecting and
  reviewing information once the device is on the market.

Risk acceptability criteria: the part that causes the trouble

This is the clause that separates a plan that works from one that generates findings for years.

The criteria must come from your risk management policy, and they must be set before you
analyse anything. Criteria written after the hazard analysis have a way of landing conveniently above
whatever the analysis produced, and reviewers recognise the pattern immediately.

Two further traps. First, the criteria have to handle the case where probability genuinely cannot
be estimated — for many device hazards it cannot, and a scheme that requires a probability value for
every row forces engineers to invent one. Second, “as low as reasonably practicable” language imported
from other sectors sits awkwardly here; the 2019 edition’s framing is about reducing risk as far as
possible and then judging the residual against your stated criteria and the benefit.

How the ISO 14971 risk management plan connects to the file

Every commitment in the plan creates an obligation to produce evidence somewhere else. That is the
whole design, and it is where traceability is won or lost.

1. The plan names the acceptability criteria; the risk evaluation applies them.
2. The plan names the verification approach; the traceability matrix demonstrates
   that each control was implemented and verified for effectiveness.
3. The plan defines review requirements; the risk management review and the
   risk management report discharge them.
4. The plan sets the post-production method; the post-production information records
   show it operating.

A useful self-check before release: take each commitment in the plan and name the document that
proves it happened. Anything you cannot name is a finding waiting to be written.

Each commitment, and the document that discharges it

The quickest way to test a plan is to lay its commitments beside the evidence they demand.

Run that table against a real ISO 14971 risk management plan and the gaps surface in minutes. It is
also close to the sequence an auditor follows, which is not a coincidence.

Where an ISO 14971 risk management plan usually fails

It is written once and never updated. An ISO 14971 risk management plan covers a lifecycle, and a device
that has changed materially since launch needs the plan revisited rather than preserved.

It describes a generic process rather than this device. A plan that would read
identically for any product in your portfolio is not really a plan for anything.

Acceptance authority is unnamed. Somebody has to sign for residual risk. If the
plan does not say who, the file will contain acceptances nobody is accountable for.

Benefit-risk is left out. Where residual risk is not acceptable against the
criteria, the standard provides for a benefit-risk analysis — but only if you planned to do one.

When to revisit the plan

The plan is a living document, and three events should send you back to it.

A design change that introduces a new hazard. If the change alters intended use or
adds a failure mode, the scope statement and possibly the acceptability criteria need review before
the analysis is updated.

Post-production information that contradicts an estimate. Field data showing a
harm occurring more often than the analysis assumed is a signal about the plan’s estimation approach,
not just about one row of the hazard analysis.

A change of standard or market. Entering a new jurisdiction can bring different
expectations about acceptability and about benefit-risk, and those live in the plan.

Record the revision history in the plan itself. An ISO 14971 risk management plan whose version
history stops at issue 1 for a device that has shipped three design changes tells a reviewer exactly
where to look next.

Frequently asked questions

Is an ISO 14971 risk management plan mandatory?
Yes. It is a required part of the risk management process and forms part of the risk management
file.

Can one plan cover a product family?
It can, provided the scope states which variants are covered and the hazards genuinely are common. If
variants differ in intended use or in their hazards, separate plans are safer.

What is the difference between the plan and the risk management report?
The plan states what you will do and how acceptability will be judged. The report, written at the
end, states what was done and concludes on overall residual risk.

Does ISO 14971:2019 need updating soon?
No. It is the third edition, published December 2019, and ISO confirmed it in 2025 following review.

Where does ISO 13485 fit?
ISO 13485 requires risk management across the quality system and points to ISO 14971 for the method.
See ISO 13485 risk management.

Where this leaves you

Write the ISO 14971 risk management plan first, make it specific to the device, and be honest in
the acceptability criteria — because you are committing to be judged against them before you know what
the analysis will find. That discomfort is the point of writing the plan up front.

Then treat the plan as a checklist for the file. Every commitment it makes should have a named
document behind it, and the ones that do not are the findings your next audit will produce.

References

• ISO 14971:2019 — the standard’s page at ISO, showing edition 3 and its 2025 confirmation.
• ISO/TR 24971:2020 — the guidance document on applying ISO 14971.
• ISO/TC 210 — the committee responsible for the standard.

More on medical device risk

• ISO 14971 risk management plan — you are here
• The ISO 14971 risk management file
• ISO 13485 risk management
• ISO 13485 risk assessment template
• MDR harmonised standards

The plan and its supporting procedures are in the ISO 14971 Toolkit, or start with the free ISO templates.