Medical device risk management
A practical guide to identifying hazards, understanding how exposure can occur, estimating and evaluating risk, selecting and verifying controls, evaluating residual risk, and keeping the risk file current after release.
About this guide
ISO 14971 establishes a medical-device risk-management process across the product lifecycle, including medical-device software, software as a medical device (SaMD), and in vitro diagnostic devices. It does not prescribe universal acceptable-risk levels; the manufacturer establishes objective criteria appropriate to its devices, policy, and applicable requirements.
The essential distinction
The intermediate reasoning explains how people or the environment become exposed and what harm can occur. It also reveals where inherent design, protective measures, information, and monitoring can interrupt the chain.
A potential source of harm.
Events or conditions that lead toward exposure.
The circumstance in which a person, property, or environment is exposed to one or more hazards.
The injury or damage that can occur.
The combination of the probability of occurrence of harm and the severity of that harm.
Electrical example
Electrical energy → accessible hazardous voltage → patient exposure → electrical injury.
Diagnostic example
Incorrect diagnostic information → false negative relied upon → delayed treatment → disease progression or other clinical injury.
Worked teaching scenario
This example shows how a complete risk record differs from “Hazard: robot moves incorrectly; mitigation: software testing.”
Hazard
The energy is the potential source of harm. The software failure belongs in the causal sequence.
Foreseeable sequence
Hazardous situation and harm
Possible harm includes tissue injury, with severity and probability evaluated using the approved method and evidence.
Controls and evidence
Circular lifecycle
Interactive practitioner reference
Search the guide, then open a clause area to review its practical meaning, actions, examples, evidence, and software-assurance connection.
Primary referenceISO standard record
Showing 20 of 20 requirement areas.
Plain-language interpretation
Establish a controlled process that connects risk planning, analysis, evaluation, control, residual-risk decisions, review, and production and post-production information. The process should continue through development, verification, validation, manufacturing, distribution, installation, service, change, post-market surveillance, and end of life as applicable.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Management establishes the organizational basis for risk management: adequate resources, competent people, defined authority, a risk-acceptability policy, and periodic review of process suitability and effectiveness.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Risk management is multidisciplinary. The expertise needed depends on the device and can include systems, software, clinical, medical, human factors, cybersecurity, manufacturing, service, Quality, Regulatory, reliability, and other subject-matter knowledge.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Plan the scope, lifecycle phases, responsibilities, methods, acceptability criteria, risk-control verification, overall residual-risk evaluation, production and post-production review, and formal risk-management review.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
The risk management file is the controlled body of linked records that demonstrates the process. It need not be one large document, but it should provide navigable traceability from planning through hazards, controls, verification, residual-risk decisions, review, and post-market updates.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Risk analysis defines intended use and reasonably foreseeable misuse, identifies characteristics related to safety, hazards, foreseeable sequences of events, hazardous situations, harms, and estimates the associated risks.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Describe the medical purpose, patient population, intended user, use environment, anatomical location, duration, operating principle, and important clinical assumptions. Then identify incorrect uses that are reasonably foreseeable even though they are not intended.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Identify characteristics of the device, users, environment, data, energy, materials, interfaces, and performance that can influence safety.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
A hazard is a potential source of harm. A foreseeable sequence describes how exposure can occur. A hazardous situation is the circumstance of exposure, and harm is the resulting injury or damage. Keeping these concepts distinct reveals where controls can act.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Estimate risk from the probability of occurrence of harm and the severity of that harm. Probability can include the chance that a sequence creates a hazardous situation and the chance that exposure results in harm. Methods should match available information and uncertainty.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Compare each estimated risk with the manufacturer’s established risk-acceptability criteria. Acceptability should not be improvised or achieved by changing the matrix after the team sees an uncomfortable result.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Consider reducing risk through inherent safety by design, protective measures in the device or process, and information for safety. Do not jump directly to warnings when design or protective control is feasible.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Selecting a control is only a decision. It must be expressed in requirements, allocated to architecture, implemented through hardware, software, configuration, process, or information, and controlled through change.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Implementation verification asks whether the control exists as designed. Effectiveness verification asks whether it actually interrupts or reduces the hazardous sequence under relevant conditions. Both questions need objective evidence.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Re-estimate and evaluate the risk that remains after verified controls. Avoid a conclusion that only says “residual risk acceptable”; identify the controls, evidence, revised estimate, criteria, uncertainty, and accountable decision.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
When further practical risk reduction is not feasible and the approved process permits it, evaluate whether the expected medical benefit outweighs residual risk. A generic statement that the device helps patients is not enough.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
A risk control can create or increase another risk. Evaluate the control’s effects on usability, performance, reliability, cybersecurity, workflow, and other hazards, then confirm all selected controls have been implemented and verified.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Look across individual residual risks and determine whether their combined effect is acceptable in relation to the benefits of intended use. Individually acceptable items can collectively create excessive warning burden, alarm overload, usability difficulty, or operational complexity.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Before commercial release, review whether the risk management plan was appropriately performed, overall residual risk is acceptable, required activities are complete, and suitable methods exist to collect production and post-production information.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Plain-language interpretation
Collect and review complaints, service, corrective and preventive action, nonconformance, production failure, supplier, literature, regulatory, cybersecurity, field-action, trend, and state-of-the-art information. Determine whether it changes the known hazards, sequences, estimates, controls, or overall conclusion.
Applied examples
Example status: Generalized learning examples; not records from a specific organization or project.
Management policy
The manufacturer establishes objective risk-acceptability criteria appropriate to its policy, devices, and applicable regulatory requirements. A claim such as “ISO 14971 says a score below six is acceptable” is not supportable.
Weak practice
Teams lower probability without evidence, redefine categories after seeing results, or cite an invented universal threshold.
Better practice
Approve the policy and method, use reliable evidence, make uncertainty visible, document the result, and select additional control when the criteria are not met.
Clause 7 in practice
Eliminate the hazard or reduce risk through the product’s design or architecture where feasible.
Detect, interrupt, contain, monitor, or prevent exposure through device or process controls.
Communicate remaining risk through warnings, instructions, or training where appropriate.
Implementation verification
Use design review, code review, inspection, configuration review, or testing to show that the selected control exists in the approved implementation.
Effectiveness verification
Challenge the control under normal, boundary, invalid-input, sensor-failure, communication-failure, fault, integration, and system conditions as applicable.
Living risk management
Complaints, service, corrective and preventive action, nonconformance, production failure, supplier issues, literature, regulation, cybersecurity vulnerabilities, field actions, trends, and new state-of-the-art information can change the risk conclusion.
Integrated lifecycle
| Reference | Primary contribution | Practical connection |
|---|---|---|
| ISO 14971 | Medical-device risk-management process across the lifecycle. | Defines the device hazard, sequence, hazardous situation, harm, risk, controls, residual risk, and feedback. |
| IEC 62304 | Medical-device software lifecycle processes. | Translates software-related risk controls into requirements, architecture, implementation, verification, release, maintenance, and problem resolution. |
| IEC 82304-1 | Safety and product lifecycle for health software products. | Addresses the complete standalone health software product and product validation context. |
| ISO 13485 | Medical-device quality management system. | Provides the organizational processes, records, design, production, supplier, complaint, corrective-action, and improvement context. |
Unintended robotic motion → independent motion-monitor control → system safety requirement → software comparison requirement → independent architectural component → unit, integration, and system verification → evidence linked to the ISO 14971 risk record.
FDA’s recognition information notes that ISO 14971’s probabilistic risk model does not apply to cybersecurity in the same way; FDA’s cybersecurity framework uses exploitability considerations. Security and safety risk processes should exchange relevant information without forcing one calculation onto both.
Review FDA recognition detailsRisk-file review
Use complementary methods and preserve the chain from intended use and hazard through exposure, harm, controls, evidence, residual risk, and post-market review.
Identify the underlying potential source of harm and place the software failure in the sequence of events.
Describe the foreseeable sequence, hazardous situation, harm, risk estimate, and control opportunity.
Use the manufacturer’s approved objective acceptability criteria; ISO 14971 does not set universal acceptable-risk levels.
Use justified qualitative categories when reliable probabilities are unavailable and make uncertainty visible.
Evaluate inherent safety by design and protective measures before relying on information for safety.
Also show that the control reduces risk as intended under normal, boundary, fault, and misuse conditions.
Evaluate new hazards, sequences, usability burden, alarm fatigue, cybersecurity effects, and interacting controls.
Identify the verified controls, revised estimate, criteria, uncertainty, and accountable conclusion.
Use production and post-production information to challenge assumptions and maintain the risk file.
Reusable challenge questions
Is intended use specific enough to support meaningful analysis?
Has reasonably foreseeable misuse been identified for the real users and environment?
Are hazard, sequence of events, hazardous situation, harm, and risk distinguished?
Are probability, severity, sources, assumptions, and uncertainty justified?
Were risk-control options considered in a systematic order?
Is each control linked to a requirement, implementation, and verification record?
Does evidence show both implementation and effectiveness?
Were new risks introduced by controls evaluated?
Is each residual-risk and benefit-risk conclusion supported?
Does the overall residual-risk review consider cumulative burden and interactions?
Is the pre-release risk management review complete and accountable?
Do production and post-production signals feed back into the risk file and product decisions?
Primary references
| Version | Date | Change |
|---|---|---|
| 1.0 | 13 September 2026 | Initial ISO 14971 practitioner guide based on the supplied publication content; ISO and FDA source status reviewed. |