Risk management in medical devices: applying ISO 14971

A reviewer from a notified body can usually tell within the first hour whether a manufacturer treats risk management as engineering or as paperwork. They open the risk management file, pick a single hazard, and follow the thread: where it was identified, what control was applied, whether that control was verified, what residual risk remained, and whether the clinical evidence still supports that the benefit outweighs it. If the thread holds for every hazard, the file is doing its job. If it breaks, no amount of tidy templates will rescue the submission.

ISO 14971 is the standard that keeps that thread intact, and applying it well is a different skill from reciting what it says. The clauses are short. The discipline they demand across a product lifecycle is not.

The risk management file is a system, not a document

ISO 14971:2019 does not ask for one risk document. It asks for a risk management file, the set of records that together show risk was identified, controlled and accepted across the lifecycle. That file indexes the risk management plan, the risk analysis records, the verification that each control was implemented and is effective, the overall residual risk evaluation, and the risk management report that concludes the file is complete before release. It is an index with traceability, not a binder assembled the week before an audit.

Most of the discipline lives in the plan. It sets the scope, the responsibilities, the criteria for risk acceptability, the method for judging overall residual risk, and how production and post-production information will feed back. Reviewers read the plan first, because everything else is judged against it. When the acceptability criteria appear nowhere in the plan but a generic five by five matrix turns up later in a spreadsheet, the message is obvious: the criteria were shaped after the fact to make the scores land in the green.

Build the analysis from hazards, not from a failure list

The most common structural mistake is to run a design FMEA, colour the cells, and call it risk management. An FMEA is a useful tool, but it begins from failure modes, so it misses every hazard that has nothing to do with a component failing. A device used correctly, by a trained user, with no fault present, can still cause harm through a sharp edge, a leachable substance in a material, or a confusing screen that invites the wrong dose. ISO 14971 is hazard driven. You start from the intended use and the characteristics related to safety, then identify hazards, the hazardous situations that expose people to them, and the harms that can follow.

Reasonably foreseeable misuse belongs in that analysis as a primary input, not a footnote. The 2019 revision made the point explicit because regulators see use error as a leading source of harm. This is where usability engineering under IEC 62366-1 and the risk file have to talk to each other. A use related hazard found in formative evaluation is a risk input, and any risk control that relies on the user reading a warning is precisely what usability testing should put under pressure.

When estimating probability, many teams find it clearer to split it the way ISO/TR 24971 sets out: P1, the probability that a hazardous situation occurs, and P2, the probability that the hazardous situation leads to harm. Separating the two ends the familiar stalemate where everyone agrees a fault is rare but no one has asked how often that fault actually injures someone.

The logic shifts by device type. For an in vitro diagnostic device the harm is almost always indirect, since the device rarely touches the patient but a wrong or late result drives a clinical decision that does. Building the risk file for diagnostics means tracing that indirect path, from an incorrect result to the misdiagnosis or delayed treatment that reaches the patient, which is exactly how the in vitro diagnostic framework expects risk to be argued.

Risk control follows the order the standard sets, not the order that is cheapest

ISO 14971 and the MDR both require risk control options in a fixed priority. First, inherently safe design and manufacture. Second, protective measures in the device or in the manufacturing process. Third, information for safety, meaning warnings, labelling and, where relevant, training. The order is not a preference. A reviewer will challenge a warning placed where a design change was feasible, because a label is the weakest control and the easiest to ignore. Teams that reach for the instructions for use whenever a redesign is inconvenient collect findings quickly.

Two checks get skipped more than any others. Every control has to be verified for both implementation and effectiveness, and every control has to be examined for new risks it introduces. A guard that prevents one injury but traps a finger has not reduced overall risk, it has relocated it. Once controls are in place you evaluate the residual risk of each hazardous situation, then the overall residual risk of the device, which is more than the sum of the individual rows.

One nuance separates the European route from older habits. The MDR requires risks to be reduced as far as possible without regard to cost, which is stricter than the as low as reasonably practicable thinking that some legacy files still carry. ISO 14971:2019 stays neutral on economics and leaves acceptability to your defined criteria, while ISO/TR 24971 explains how to reconcile the two. If you sell into Europe, write your criteria to the as far as possible standard and keep any cost argument out of the justification.

Benefit-risk analysis is where the file meets clinical evidence

Benefit-risk analysis is the part teams underbuild. In the 2019 revision it is a defined activity, and it is not triggered only when a residual risk looks high. You weigh the residual risks, individually and overall, against the clinical benefit of the device, and you record the reasoning. The benefit side does not come from engineering judgement. It comes from clinical data, which means the risk management file and the clinical evaluation report have to agree.

This is the link submissions most often get wrong. The hazards and harms listed in the risk file should be the same ones the clinical evaluation examines for frequency and severity in real use. If the clinical evaluation reports an adverse event the risk file never anticipated, the risk file is out of date. If the risk file claims a benefit the clinical data do not support, the benefit-risk conclusion falls apart. A reviewer reads both documents side by side, so they should be written to be read that way, cross referenced at the level of individual risks. For a manufacturer preparing a CE submission, that consistency between the risk file, the clinical evaluation and the quality system is what turns the medical device CE route from a document hunt into a single coherent argument.

The standard also requires that significant residual risks be disclosed to users. Disclosure is not a route to making an unacceptable risk acceptable. It is the final step once the benefit-risk analysis has concluded the benefit holds. Hiding a known residual risk to keep the instructions for use clean is both a safety failure and an audit failure.

Risk management does not end at launch

A risk file that stops on the date of CE marking is incomplete by design. ISO 14971 closes its loop with production and post-production activities. The manufacturer collects information from manufacturing, the market, complaints, vigilance and post-market clinical follow-up, then reviews whether any of it changes a risk estimate or the overall benefit-risk conclusion. The MDR formalises this through post-market surveillance and periodic safety update reporting, but the engine underneath is the same risk file.

In practice the file needs owners after launch, not only during development. A rise in one particular complaint is a signal that a probability estimate was optimistic. A competitor recall on shared technology is a reason to revisit your own hazards. A revised standard, a new understanding of the state of the art, a material reclassified as hazardous: each is an input. The risk management process is built into the quality system so these reviews happen on a schedule rather than after an incident. A mature ISO 13485 quality management system is what keeps the risk file alive between audits, tying design controls, purchasing and corrective action back to the hazards they touch.

Where teams actually lose time

The recurring problems are rarely about not knowing the clauses. They come from treating the file as a deliverable rather than a process: acceptability criteria written to fit the result, controls that lean on labelling, residual risk evaluated row by row but never as a whole, and a benefit-risk analysis with no clinical evidence beneath it. Each of these is visible to an experienced reviewer early.

Applying ISO 14971 well is mostly discipline. Define your criteria before you score anything, follow the control hierarchy even when redesign is the harder road, keep the risk file and the clinical evaluation telling one story, and keep both open after launch. To see how the formal risk assessment sits alongside conformity assessment and a certified quality system, our ISO 14971 risk management service sets out where it fits in the wider medical device picture.