ISO 14971 Risk Management — A Warning in the Manual Is the Last Resort

Key takeaway — Risk management is not a document type but a process running through the whole of development. The point that most often goes wrong in practice is the priority order for risk control: (1) inherent safety by design → (2) protective measures → (3) information for safety. Substituting a warning in the manual for something design could have solved skips the order, and that alone is a finding. Current as of September 2026.

A risk management file is not a folder of documents

Ask for risk management material in practice and the reply is often "we have the risk analysis table."

The table is only part of the output. What ISO 14971 asks for is a process, roughly this one:

1. Risk management plan — decide first what will be judged, and against what criteria
2. Intended use and safety-related characteristics — what the device does and in what conditions
3. Hazard identification — what can go wrong
4. Risk estimation and evaluation — how often, how severely
5. Risk control — what is done to reduce it (priority below)
6. Residual risk evaluation — what remains after control
7. Overall residual risk acceptability
8. Production and post-production information — feeding what comes back from the market into risk management again

Step 8 is the one that gets forgotten. Risk management does not end at approval; it re-enters the loop every time post-market information arrives.

The priority order for risk control — the core of this guide

There is a fixed order for reducing risk.

Priority	Method	Examples
1	Inherent safety by design	Remove the hazardous arrangement altogether — connector geometry that cannot be mis-mated, circuitry where a dangerous output is physically impossible
2	Protective measures in the device or in manufacturing	Interlocks, alarms, redundant safety devices, in-process inspection
3	Information for safety	Warnings in the instructions, caution markings on the label, training

What the order means in practice is one thing: 3 is what you use when 1 and 2 cannot solve it.

So a risk analysis table whose control column is filled entirely with "warning added to the instructions for use" is itself a signal. The reviewer's question is "why could this not be prevented by design," and without an answer that becomes a deficiency.

Knowing the order also changes the language of design meetings. Before "let us add a warning" comes "can we prevent it structurally" — and the record of that consideration is exactly what the risk management file needs as evidence.

Three common misconceptions

1. "Risk has to be reduced to zero." It does not. Risk management is not an activity that eliminates risk but one that judges and records it. Where risk remains, what is required is a documented judgment that it is acceptable, with the basis for that judgment.

2. "A good risk analysis table is enough." The table is an output; what review examines is the connection. Which control followed from which identified hazard, and what evidence shows that the control actually works — break that chain and the density of the table does not matter.

3. "We will compile it once development is finished." A retrospectively assembled file is recognisable, because the causality runs backwards. Risk consideration should have changed the design; in a retrospective document, risk entries are arranged to fit a design that was already fixed.

Other files converge here

Risk management is not a standalone document but the point where other files join.

• Usability — risk arising from use error. The results only carry weight when connected to the risk management file (usability guide)
• Biological safety — risk arising from materials. ISO 10993-1 itself requires "evaluation within a risk management process" (ISO 10993 guide)
• Software — risk created by software failure, and its control
• Performance and electrical safety testing — the verification data showing that controls actually work

In other words, however good the individual files are, they float free unless risk management assembles them into one picture. How to build that connection inside the technical file is covered in writing the technical file; terminology is set out on the risk management glossary page.

A note on applying it in Korea

Risk management is required both through the Korean standards and through the quality management system. Remember, though, that what actually applies in Korea is the edition and the requirements fixed by the notice. A newer international revision does not automatically become the Korean requirement, so checking the text of the applicable standard and quality requirements at the time of application is the safer course.

The structure is the same as for ISO 10993: know the international standard, confirm the Korean requirement in the notice.

Common deficiency findings

• Risk controls consisting mostly of "warning added to the instructions," with no record of design consideration
• Traceability broken between identified hazards, controls and verification data
• Usability and biological safety results not reflected in the risk management file
• Residual risk acceptability asserted without a basis
• No procedure for feeding post-market information back in
• Risk management file not updated after a design change

Before you start

• Write the risk management plan — set the acceptability criteria first
• Define intended use, users and use environment (same values as the usability file)
• Identify hazards — including reasonably foreseeable misuse, not only normal use
• Consider controls in the order 1 design → 2 protective measures → 3 information, and record that order
• Link verification data to each control (which test demonstrates that it works)
• Bring usability, biological safety and software results into the file
• Document the basis for residual and overall residual risk acceptability
• Establish procedures for updating the file after design changes and for post-market feedback

---

Risk management becomes a design tool when it starts early and paperwork when it starts late. Send the intended use and an outline of the device, and we will identify which hazards to look at first and which files need to converge here — see free preliminary review.