ISO 14971 is the international standard for applying risk management to medical devices, and it is a working method rather than a document you produce once. It requires you to identify hazards, estimate the risk each one presents, reduce that risk in a specific mandatory order — inherently safe design first, then protective measures, then information for safety last — and then evaluate what risk remains against the device's clinical benefit. FDA expects it, notified bodies audit against it, and the file it produces is the backbone of your submission's safety argument.

This article is educational only. Projects House is an engineering firm, not a regulatory consultancy; a qualified regulatory or quality professional should confirm how the standard applies to your device.

Not a Document — a Method

The most common failure is treating risk management as a deliverable produced near the end of development to satisfy a reviewer. Done that way it becomes a list of hazards someone brainstormed in an afternoon, with mitigations that describe the device that already exists rather than shaping it.

Applied properly, risk analysis runs before and during design and changes what gets designed. A hazard identified early becomes a design input — a mechanical interlock, a redundant sensor, a different material — and that is far cheaper and safer than a warning label added at the end. The connection into the formal development process is described in our guide to FDA design controls.

The Basic Structure

The process has a consistent shape, and each step produces a record:

  • A risk management plan, written first, defining the scope, the criteria for what counts as acceptable risk, who is responsible, and how the work will be reviewed. Setting acceptability criteria before you know the answers is deliberate — it keeps the criteria honest.
  • Hazard identification. Every way the device could cause harm: energy hazards, biological and chemical hazards, operational and use hazards, software failures, environmental factors, and problems arising from misuse that is reasonably foreseeable rather than merely conceivable.
  • Risk estimation. For each hazardous situation, the severity of the potential harm and the probability of it occurring. Severity is usually straightforward; probability is often genuinely uncertain, and where you cannot estimate it credibly the standard expects you to treat severity as governing.
  • Risk evaluation against your predefined criteria, deciding whether reduction is required.
  • Risk control, in the mandatory order described below, followed by verification that each control was implemented and is effective.
  • Residual risk evaluation, both per hazard and overall, weighed against the clinical benefit the device provides.
  • Production and post-production monitoring, feeding real field data back into the file.

The Order of Risk Control — the Rule You Cannot Skip

This is the part reviewers check first, and the part teams most often get backwards. The hierarchy is:

  1. Inherently safe design and manufacture. Eliminate the hazard. Remove the sharp edge, choose a material that cannot leach the harmful compound, limit the achievable output so an overdose is physically impossible, use a connector geometry that cannot be misconnected.
  2. Protective measures in the device or in manufacturing. If the hazard cannot be eliminated, contain it: guards, current limits, alarms, redundant sensing, watchdog timers, mechanical interlocks.
  3. Information for safety. Labels, warnings, instructions for use, and training — acceptable only after the first two options have been genuinely exhausted.

A risk file whose controls are mostly warnings in the manual will not pass scrutiny, and rightly so: a label is the weakest control because it depends entirely on a human reading and obeying it under real conditions. Reviewers will ask why the hazard was not designed out, and "we added a warning" is not an answer.

What Teams Tend to Miss

  • Use error as a hazard in its own right. Most harm in fielded devices comes from a user doing something reasonable that the design allowed. Human factors work belongs inside risk management, not beside it.
  • Single-fault conditions. What happens when one component fails, one wire opens, one sensor reads out of range? Systematic single-fault analysis catches problems that hazard brainstorming misses.
  • Software failure modes. Not just crashes but wrong outputs delivered confidently, stuck values, timing faults, and states after an unexpected restart.
  • Cleaning, reprocessing, and end of life. A device cleaned with a solvent that degrades a housing over months is a hazard with a long fuse.
  • Interoperability and accessories. Third-party power supplies, chargers, and connected apps are part of the hazard picture.
  • Cumulative residual risk. Many individually acceptable risks can add up to an overall risk that is not, and the standard requires that overall judgment explicitly.

How the Risk File Connects to Testing

Every risk control has to be verified, and that verification usually maps directly onto the standards testing your device needs anyway. Electrical hazards resolve through the electrical safety and EMC work described in IEC 60601 electrical safety testing. Material and patient-contact hazards resolve through the biological evaluation described in ISO 10993 biocompatibility testing. Mechanical hazards resolve through structural and durability testing. Reading the standards as sources of pre-defined risk controls, rather than as an unrelated compliance chore, saves a great deal of duplicated effort.

Managing Change

Any design change, component substitution, supplier change, or new intended use requires the risk file to be revisited — not rewritten, but reassessed for what the change touches. In practice this means the risk file lives in your change control process. Teams that update it quarterly instead of per change accumulate a file that no longer describes the device, which is both an audit finding and a genuine safety problem. The general mechanics are covered in the engineering change order process, and the quality system that holds it together in ISO 13485 requirements.

Identifying Hazards Without Missing Any

No single technique is sufficient, so effective teams layer several. Work through the standard's own annex of hazard categories as a checklist. Run a structured failure mode analysis on the design and on the manufacturing process. Walk the entire clinical workflow step by step with someone who has actually used devices like yours, asking what could go wrong at each step. Review complaint and recall history for comparable devices on the market. And revisit the list after every prototype build, because real hardware reveals hazards no analysis predicted. Where a device is still early, the prototyping approach in medical device prototyping is what generates those discoveries early enough to act on.

Value Beyond Compliance

The commercial argument for doing this well is not just approval. A thorough risk file reduces field failures, complaints, and recalls, all of which cost far more than the analysis would have. It gives you documented answers when a hospital's procurement or a strategic acquirer asks how you handled a specific hazard. And it protects the schedule: a hazard found during design review costs an afternoon, while the same hazard found during verification costs a redesign, and found in the field costs a recall. Budget context is in medical device development cost.

Projects House develops medical devices with risk analysis driving design decisions from the start — hazards identified before the architecture is fixed, controls designed into the hardware rather than written into the manual, and verification evidence tied to each control. If you are developing a device and want the risk work integrated into the engineering, get in touch through our contact form.