ISO 14971 Risk Management for Medical Devices: The Complete Guide

What Is ISO 14971?

ISO 14971 is the international standard for the application of risk management to medical devices. It defines a framework that manufacturers must follow to identify hazards associated with a medical device, estimate and evaluate the associated risks, control those risks, and monitor the effectiveness of those controls throughout the product's entire lifecycle.

The current version is ISO 14971:2019, which replaced the 2007 edition. It is published by the International Organization for Standardization (ISO) and developed by Technical Committee TC 210 (Quality management and corresponding general aspects for medical devices).

Risk management is not a phase of product development. It is a continuous process that starts before design inputs are finalized, runs through design, manufacturing, and commercial distribution, and continues until the device is decommissioned and no longer in use. ISO 14971 provides the structure for that process.

If you work in the medical device industry — whether you are a quality engineer, a regulatory affairs specialist, a design engineer, or a consultant — ISO 14971 is one of the most important standards you will use. Every major regulatory framework in the world references it. Every quality system audit will examine your risk management process against it. Every design review, CAPA investigation, and post-market surveillance activity connects back to it.

This guide covers everything you need to understand and implement ISO 14971 effectively.

Why Risk Management Matters

Medical devices interact with patients, clinicians, and healthcare environments in complex and sometimes unpredictable ways. A cardiac pacemaker operates inside the human body for years. A surgical robot responds to a surgeon's commands in real time during a procedure. A diagnostic algorithm processes patient data to suggest a treatment path.

In all of these cases, failures, misuse, or unforeseen interactions can lead to patient harm. Risk management is the systematic discipline of identifying what could go wrong, understanding how likely and how severe those outcomes could be, and taking deliberate action to reduce risk to an acceptable level.

Without structured risk management, decisions about device safety become ad hoc. Design engineers address hazards they happen to think of. Manufacturing teams fix problems reactively. Post-market issues that should have been anticipated come as surprises. ISO 14971 replaces this improvisation with a repeatable, auditable, lifecycle-spanning process.

Scope and Applicability

ISO 14971 applies to all stages of a medical device's lifecycle, including:

• Concept and feasibility
• Design and development
• Manufacturing and production
• Distribution, installation, and deployment
• Use by patients and clinicians
• Maintenance, servicing, and repair
• Decommissioning and disposal

The standard applies to every type of medical device, regardless of risk class — from Class I bandages to Class III implantable defibrillators. It also applies to in vitro diagnostic medical devices (IVDs). The depth and rigor of the risk management process should be proportionate to the risk, but the process itself is required for all devices.

Importantly, ISO 14971 addresses risks to patients, operators (clinicians and caregivers), other persons, equipment, and the environment. It does not address business risks, financial risks, or risks to the manufacturer's reputation — those are outside its scope.

Key Terminology

ISO 14971 uses specific terminology with precise definitions. Misunderstanding these terms causes confusion during both implementation and audits. Here are the essential definitions.

Term	ISO 14971 Definition	Practical Meaning
Harm	Physical injury or damage to the health of people, or damage to property or the environment	The bad outcome — patient death, tissue damage, misdiagnosis, device malfunction leading to injury
Hazard	Potential source of harm	The root cause or condition that could lead to harm — electrical energy, bioburden, software error, sharp edge, toxic material
Hazardous situation	Circumstance in which people, property, or the environment are exposed to one or more hazards	The scenario connecting the hazard to the harm — "patient contacts exposed conductor during rain"
Sequence of events	The chain of events from the hazard through the hazardous situation to harm	How the hazard actually reaches the patient and causes damage
Risk	Combination of the probability of occurrence of harm and the severity of that harm	Not just "how bad" or "how likely" — it is both dimensions together
Severity	Measure of the possible consequences of a hazard	How bad the harm would be if it occurred — death, serious injury, minor discomfort
Probability of occurrence of harm	The overall likelihood that a hazardous situation results in harm	The combined probability of the hazardous situation arising and then leading to harm
Residual risk	Risk remaining after risk control measures have been implemented	What remains even after you have done everything reasonable to reduce risk
Risk control	Process in which decisions are made and measures implemented to reduce or maintain risk within specified levels	The actions you take — design changes, protective measures, safety information
Benefit	Positive impact or desirable outcome of the use of a medical device on the health of an individual, or a positive impact on patient management or public health	The clinical value the device provides
Risk management file	Set of records and other documents produced by the risk management process	The complete documentation package that demonstrates your risk management activities
State of the art	Developed stage of technical capability at a given time as regards products, processes, and services, based on relevant consolidated findings of science, technology, and experience	What competent manufacturers currently know and do — not cutting-edge research, but established best practice

A critical distinction: "hazard" is not the same as "risk." A sharp edge is a hazard. The risk is the combination of (a) the probability that someone will be cut by the sharp edge, and (b) the severity of that cut. You can have a high hazard with low risk (e.g., a sharp edge inside a sealed, welded enclosure that no one can access) or a moderate hazard with high risk (e.g., a slightly elevated temperature in a device that contacts neonatal skin for hours).

The Risk Management Process: Step by Step

ISO 14971 defines a structured risk management process with distinct phases. Each phase produces documented outputs that become part of the risk management file.

Risk Management Planning

Every risk management activity begins with a plan. The risk management plan is a documented description of how risk management will be conducted for a specific medical device or device family. It must be established before risk management activities begin, and it must be reviewed and updated as the project evolves.

The risk management plan must include:

• Scope — The device or device family covered, the lifecycle phases addressed
• Responsibilities and authorities — Who performs risk management activities, who reviews them, who approves risk acceptability decisions
• Risk acceptability criteria — The criteria used to determine whether a risk is acceptable, including how the probability and severity of harm are defined and how they map to risk levels
• Verification activities — How risk control measures will be verified as effective
• Production and post-production information — How field data will be collected and fed back into risk management
• Review activities — How and when the risk management file will be reviewed for completeness and consistency

The risk management plan is not a template you fill in once and forget. It is a living document that adapts as the device design matures and new information becomes available. If your acceptability criteria change, or you add a new intended use, or you discover a new hazard category that needs analysis, the plan must be updated.

Practical tip: Many companies create a master risk management plan template at the QMS level and then instantiate it for each device project. This ensures consistency across products while allowing project-specific customization. Your template should be detailed enough that a new team member can read it and understand exactly how risk management is done at your organization.

Risk Analysis

Risk analysis is the systematic use of available information to identify hazards and estimate risk. This is where most of the intellectual work of risk management happens.

Intended Use and Reasonably Foreseeable Misuse

The starting point for risk analysis is a clear definition of:

• Intended use / intended purpose — What the device is designed to do, the patient population, the clinical context, the intended users
• Reasonably foreseeable misuse — Uses that are not intended but can be reasonably anticipated based on human behavior. A device designed for adult patients may foreseeably be used on pediatric patients. A single-use device may foreseeably be reprocessed. A device labeled for clinical use may be used in a home setting.

You cannot limit your risk analysis to the ideal scenario where every user reads the instructions, follows every step perfectly, and uses the device exactly as intended. Real-world use is messy. Reasonably foreseeable misuse must be analyzed with the same rigor as intended use.

Hazard Identification

Hazard identification is the most important step in the entire risk management process. If you fail to identify a hazard, you cannot analyze, evaluate, or control the risk associated with it. Missed hazards become the failures that reach patients.

ISO 14971 provides a list of example hazards in Annex C (informative), organized into categories:

Hazard Category	Examples
Energy hazards	Electricity (leakage current, defibrillation), radiation (ionizing, non-ionizing, UV, laser), thermal (burns, hypothermia), mechanical (sharp edges, moving parts, kinetic energy, vibration, acoustic pressure)
Biological and chemical hazards	Bioburden, biocompatibility (cytotoxicity, sensitization, irritation), incorrect formulation, toxicity, allergenicity, mutagenicity, pyrogenicity
Operational hazards	Incorrect output, loss of function, incorrect measurement, loss of or degradation of function, use error, inadequate instructions
Information hazards	Inadequate labeling, inadequate instructions for use, inadequate warning of side effects, inadequate specification of accessories
Software hazards	Incorrect algorithm, loss of data, incorrect data display, incorrect data transfer, cybersecurity vulnerabilities
Environmental hazards	Electromagnetic interference, incompatibility with other devices, contamination, inadequate packaging for transport/storage

Do not rely on Annex C alone. Use it as a starting point, then apply device-specific knowledge, clinical expertise, complaint history from predicate or similar devices, published literature, and input from cross-functional team members.

Estimating Risk: Severity and Probability

For each identified hazardous situation, you must estimate both the severity of the potential harm and the probability that the harm will occur.

Severity is typically categorized on a qualitative scale. Here is a common five-level scale, though your organization may use a different number of levels:

Severity Level	Category	Description	Examples
S1	Negligible	Inconvenience or temporary discomfort, no medical intervention required	Slight skin redness, minor noise, temporary discomfort during use
S2	Minor	Temporary injury or impairment requiring minor medical intervention	Minor cut, minor burn, temporary hearing threshold shift
S3	Serious	Injury or impairment requiring professional medical intervention	Significant laceration, second-degree burn, infection requiring antibiotics
S4	Critical	Life-threatening injury, permanent impairment, or injury requiring major medical/surgical intervention	Third-degree burn, permanent hearing loss, organ damage, nerve damage
S5	Catastrophic	Death or loss of a major body function	Patient death, permanent paralysis, loss of limb

Probability of occurrence of harm is the overall probability that a specific hazardous situation leads to harm. This is the combined probability of: (a) the hazardous situation arising, and (b) the hazardous situation leading to harm.

Probability Level	Category	Description	Approximate Frequency
P1	Incredible	So unlikely as to be considered essentially impossible	Less than 1 in 1,000,000 device uses
P2	Improbable	Unlikely but possible; could occur once during the lifetime of the product	1 in 100,000 to 1 in 1,000,000
P3	Remote	Could occur several times over the product's lifetime	1 in 10,000 to 1 in 100,000
P4	Occasional	Likely to occur at some point during product life	1 in 100 to 1 in 10,000
P5	Frequent	Likely to occur multiple times; has been observed regularly	Greater than 1 in 100

Important notes on probability estimation:

• Quantitative data is preferred when available (complaint rates, test data, published failure rates, epidemiological data). When quantitative data is unavailable, qualitative or semi-quantitative estimation is acceptable, but the rationale must be documented.
• Probability estimation should consider the sequence of events from hazard to harm, including any intermediate events and the probability of each.
• Do not confuse probability of a failure mode with probability of harm. A software crash (failure mode) may happen occasionally, but if the device fails to a safe state, the probability of harm from that crash may be remote.

Risk Evaluation

Risk evaluation determines whether a risk is acceptable based on the criteria defined in the risk management plan. This is where the risk matrix comes in.

The Risk Matrix

The risk matrix is a tool that maps combinations of severity and probability to risk levels. Here is a representative 5x5 matrix:

	P1 (Incredible)	P2 (Improbable)	P3 (Remote)	P4 (Occasional)	P5 (Frequent)
S5 (Catastrophic)	Medium	High	High	Unacceptable	Unacceptable
S4 (Critical)	Low	Medium	High	Unacceptable	Unacceptable
S3 (Serious)	Low	Medium	Medium	High	Unacceptable
S2 (Minor)	Low	Low	Low	Medium	High
S1 (Negligible)	Low	Low	Low	Low	Medium

Risk levels are typically classified into three or four regions:

• Unacceptable — Risk must be reduced. The device cannot be released with this risk level.
• High (ALARA/ALARP region) — Risk reduction is required. Risk must be reduced as low as reasonably practicable. If it cannot be reduced further, a risk-benefit analysis is required.
• Medium (ALARA/ALARP region) — Risk reduction should be pursued. Risk should be reduced as far as practicable, taking into account the state of the art.
• Low (Broadly acceptable) — Risk is acceptable without further reduction. However, if further reduction is practicable without introducing new risks, it should still be considered.

Common pitfall: Companies sometimes define their risk matrix boundaries in a way that makes almost everything "acceptable." This is a red flag for auditors. Your matrix should reflect a genuine assessment of what your organization considers tolerable risk, not a structure designed to avoid triggering risk controls. If 95% of your identified risks fall into "acceptable" before any risk controls are applied, your matrix may be too lenient — or your hazard identification may be too shallow.

The ALARP Principle

ALARP — As Low As Reasonably Practicable — is the guiding principle for risk acceptability in ISO 14971. It means that risk should be reduced until the cost (in time, money, technical complexity, or trade-off against other risks or device performance) of further reduction is grossly disproportionate to the benefit of that reduction.

ALARP does not mean zero risk. It means you have made a rational, documented decision that further risk reduction is not practicable given the current state of the art, and that the remaining risk is justified by the device's clinical benefit.

Note: ISO 14971:2019 replaced the explicit "ALARP" language used in the 2007 version with the phrase "as far as possible." The concept is the same, but the terminology was adjusted to avoid confusion with the specific legal interpretation of ALARP used in some jurisdictions (particularly the UK). In practice, most organizations still use ALARP as shorthand.

ALARP vs. AFAP: Understanding the Practical Differences

While ALARP and AFAP (As Far As Possible) are often described as conceptually equivalent, there is an important practical difference that manufacturers navigating both ISO 14971 and the EU MDR must understand.

ALARP permits a manufacturer to include economic impacts as one of the factors in determining what constitutes "reasonably practicable." Under ALARP, a manufacturer can argue that the cost of further risk reduction is grossly disproportionate to the safety benefit gained, and therefore the current residual risk level is acceptable.

AFAP, as used in the EU MDR's General Safety and Performance Requirements (GSPRs), does not allow economic impacts as part of the risk decision-making process. The MDR requires that all known and foreseeable risks be reduced as far as possible. GSPR 4, coupled with GSPR 8's reference to "all risks," means manufacturers cannot simply ignore very low risks — every risk must be addressed.

ISO 14971:2019 Clause 4.2, Note 1 acknowledges this distinction, stating that "The manufacturer's policy for establishing criteria for risk acceptability can define the approaches to risk control: reducing risk as low as reasonably practicable, reducing risk as low as reasonably achievable, or reducing risk as far as possible without adversely affecting the benefit-risk ratio."

In practice, this means:

• For EU MDR/IVDR submissions: You must demonstrate that every identified risk has been reduced as far as possible, even risks already in the "broadly acceptable" region. The justification for stopping risk reduction must be technical (no further reduction is physically or technically possible, or further reduction would introduce greater risks), not economic.
• For FDA submissions: The ALARP approach remains acceptable, and cost-benefit considerations can factor into risk acceptability decisions, though you must still demonstrate that the state of the art has been considered.
• For global submissions: Adopt the more conservative AFAP approach as your baseline. If you satisfy AFAP, you automatically satisfy ALARP. The reverse is not necessarily true.

Risk Acceptability Criteria: Detailed Guidance

Risk acceptability criteria are among the most scrutinized elements during audits, yet they are frequently poorly defined. ISO/TR 24971:2020 provides extensive guidance on how to establish these criteria properly.

Key principles for defining risk acceptability criteria:

Your criteria must be device-specific. Defining a single risk acceptability matrix globally in an SOP and applying it to all devices is almost always an error — and auditors know this. A Class III implantable cardiac device and a Class I adhesive bandage cannot share the same acceptability boundaries. The policy for establishing criteria should be defined at the QMS level, but the criteria themselves must be derived for each device or device family.

The policy for establishing criteria for risk acceptability should be based on:

• Applicable national and regional regulations (EU MDR, FDA, MDSAP)
• Relevant international standards and the current state of the art
• Generally accepted safety practices for comparable devices
• Known stakeholder concerns (patient advocacy groups, clinical user feedback, published adverse event data)

Common approaches to defining risk acceptability criteria include:

Approach	Description	When to Use
Risk matrix with defined zones	Define severity and probability scales, map combinations to acceptability regions (acceptable, ALARP, unacceptable)	Most devices; provides visual clarity and is well-understood by auditors
Quantitative risk thresholds	Set numerical probability thresholds for each severity level (e.g., "for catastrophic harm, probability must be less than 1 in 1,000,000 device-uses")	High-risk devices where quantitative data is available; implantable devices, life-sustaining devices
Comparison to state-of-the-art benchmarks	Define acceptability by reference to published safety data for comparable devices currently on the market	Devices entering established markets where predicate or similar device safety data exists
Regulatory-derived criteria	Derive criteria from specific regulatory performance standards (e.g., FDA guidance documents, harmonized standards with specific acceptance limits)	Devices where regulatory guidance specifies performance thresholds

What auditors look for:

• Criteria were defined before risk analysis was performed — not reverse-engineered to fit the results
• The criteria reflect a genuine assessment of tolerable risk, not a structure designed to make everything "acceptable"
• Separate criteria exist for pre-control risk evaluation and post-control (residual) risk evaluation
• The benefit used in risk-benefit analysis matches the benefit claimed in the clinical evaluation
• Probability and severity classes are precisely defined with clear boundaries between levels

Real-world audit finding: A manufacturer defined five severity levels but used vague descriptors like "moderate harm" without specifying what constitutes moderate harm for their specific device. During audit, the assessor found that different team members had assigned different severity ratings to the same hazardous situation because the criteria were ambiguous. The solution was to add device-specific clinical examples to each severity level — for instance, for an orthopedic implant: S3 (Serious) = "Implant loosening requiring revision surgery within 5 years," S4 (Critical) = "Periprosthetic fracture or implant failure requiring emergency revision surgery."

Risk Analysis Techniques

ISO 14971 does not mandate a specific risk analysis technique. The choice depends on the device, the stage of development, and the type of hazard being analyzed. Here are the most commonly used techniques.

FMEA — Failure Mode and Effects Analysis

FMEA is the most widely used risk analysis technique in the medical device industry. It is a bottom-up, systematic approach that examines each component, process step, or function of a device and asks: what could fail, how could it fail, what would happen if it failed, and how likely is the failure?

There are two main types:

• Design FMEA (dFMEA) — Analyzes the device design. Each component or subsystem is examined for potential failure modes.
• Process FMEA (pFMEA) — Analyzes the manufacturing process. Each process step is examined for potential deviations.

A typical FMEA worksheet includes the following columns:

Column	Description
Item / Process Step	The component, function, or process step being analyzed
Potential Failure Mode	How the item could fail to perform its intended function
Potential Effect of Failure	The consequences of the failure mode on the device, the user, or the patient
Severity (S)	Rating of the worst potential consequence
Potential Cause(s)	Root cause or mechanism of the failure mode
Probability of Occurrence (O)	Estimated frequency of the cause occurring
Current Design/Process Controls — Prevention	Existing controls that prevent the cause or failure mode
Current Design/Process Controls — Detection	Existing controls that detect the failure mode before the device reaches the patient
Detection (D)	Rating of the ability of current controls to detect the failure mode
Risk Priority Number (RPN)	S x O x D — a composite score used for prioritization
Recommended Action(s)	Proposed risk control measures
Responsibility and Target Date	Who will implement the action and by when
Results of Action	Revised S, O, D, and RPN after implementation

Important warning about RPN: The Risk Priority Number is useful for prioritizing where to focus risk reduction efforts, but it has well-documented limitations. RPN treats severity, occurrence, and detection as equally weighted and interchangeable, which they are not. A risk with S=5, O=1, D=1 (RPN=5) is fundamentally different from a risk with S=1, O=5, D=1 (RPN=5), even though the RPN is identical. The first involves a potentially catastrophic outcome; the second involves a trivial one.

For ISO 14971 compliance, risk acceptability decisions must be based on the combination of severity and probability of occurrence of harm — the two-dimensional risk as defined in the standard — not on RPN alone. Many companies use FMEA as a working tool during risk analysis but map the results into the ISO 14971 risk matrix for formal risk evaluation. This is a sound approach.

FTA — Fault Tree Analysis

Fault Tree Analysis is a top-down, deductive technique. It starts with an undesired event (the "top event") and works backward to identify all possible combinations of causes that could produce that event.

FTA uses Boolean logic (AND gates, OR gates) to model the relationships between events. It is particularly useful for:

• Complex systems with multiple redundancies
• Understanding common-cause failures (a single root cause that defeats multiple controls)
• Quantitative risk assessment (when failure probabilities are known for individual components)
• Analyzing catastrophic or high-severity hazards where you need confidence that all causal pathways have been identified

Example: For a top event of "Ventilator fails to deliver breath," the fault tree might decompose into: motor failure OR valve failure OR software command error OR power loss. Each of those would further decompose. Power loss might branch into: AC supply failure AND battery backup failure AND UPS failure — revealing that all three power sources must fail simultaneously for this path to produce the top event.

FTA is more resource-intensive than FMEA but provides deeper insight into complex failure scenarios. It is commonly used alongside FMEA — FMEA identifies individual failure modes; FTA explores how combinations of failures interact.

PHA — Preliminary Hazard Analysis

Preliminary Hazard Analysis is a high-level, early-stage technique used to identify hazards and assess risk before detailed design information is available. It is typically the first risk analysis performed during the concept or feasibility phase.

PHA identifies:

• Energy sources (electrical, mechanical, thermal, radiation)
• Hazardous materials (chemicals, biological agents)
• Hazardous interfaces (between device subsystems, between device and patient, between device and environment)
• Environmental hazards (EMI, humidity, temperature)
• Human factors (use errors, foreseeable misuse)

PHA does not require detailed design data. It works from functional descriptions, intended use statements, and general knowledge of the technology. The output feeds into more detailed analyses (FMEA, FTA) once the design matures.

HACCP — Hazard Analysis and Critical Control Points

HACCP originated in the food industry but has been adopted for certain medical device applications, particularly devices that involve biological processes, sterile manufacturing, or processes where contamination control is critical.

HACCP identifies critical control points (CCPs) in a process — points where a hazard can be prevented, eliminated, or reduced to an acceptable level — and establishes monitoring, critical limits, and corrective actions for each CCP.

It is most applicable to:

• Sterilization processes
• Cleanroom manufacturing
• Devices involving biological materials (tissue-engineered products, blood-contacting devices)
• Aseptic filling and packaging processes

Choosing the Right Technique

Technique	Best For	Stage	Approach	Resource Level
PHA	Initial hazard identification, concept-stage risk assessment	Early (concept, feasibility)	Top-down, high-level	Low
FMEA	Systematic analysis of individual failure modes, design and process risk	Design, manufacturing	Bottom-up, detailed	Medium to high
FTA	Complex failure scenarios, common-cause failures, quantitative analysis	Design (detailed), verification	Top-down, deductive	High
HACCP	Process control, contamination, biological hazards	Manufacturing, process validation	Process-focused	Medium

Most medical device manufacturers use FMEA as their primary risk analysis technique, supplemented by PHA during early development and FTA for high-severity hazards or complex systems. You are not limited to one technique — use whatever combination provides the most thorough analysis for your specific device.

Risk Control

When risk evaluation determines that a risk requires reduction, you must implement risk control measures. ISO 14971 specifies a priority order for risk control options:

1. Inherent safety by design — Eliminate the hazard or reduce the risk through design choices. This is the most effective and most preferred option. Examples: using biocompatible materials instead of toxic ones, designing out sharp edges, selecting a lower voltage, removing a pinch point.

2. Protective measures in the medical device itself or in the manufacturing process — Add safety features that reduce risk without eliminating the underlying hazard. Examples: adding a guard over a moving part, incorporating an alarm for out-of-range conditions, adding a pressure relief valve, implementing a watchdog timer in software, adding redundant sensors.

3. Information for safety — Provide warnings, precautions, contraindications, and instructions for use. This is the least preferred option because it relies on the user reading, understanding, and following the information. Examples: labeling a single-use device "Do Not Reuse," adding a warning about MRI incompatibility, providing a contraindication for use in pediatric patients.

This priority order is not optional. It is a requirement of the standard. You cannot rely on a warning label when a design change would eliminate the hazard. Auditors will challenge risk controls that jump to option 3 without documented justification for why options 1 and 2 are not practicable.

Practical example: A portable infusion pump has a risk of over-infusion due to a stuck valve. Risk control options, in priority order:

1. Inherent safety by design: Select a valve mechanism that fails closed (no flow) rather than fails open (uncontrolled flow). Redesign the valve seat geometry to prevent sticking.
2. Protective measure: Add a flow sensor downstream of the valve with an alarm and automatic shutoff if flow exceeds the programmed rate by a defined threshold.
3. Information for safety: Add a warning in the IFU that clinicians should visually monitor flow rate and be prepared to clamp the line if the alarm sounds.

A robust design uses all three — but the first line of defense must be the design choice, not the label.

Risk Control Verification

Every risk control measure must be verified. Verification confirms two things:

1. The risk control measure is implemented correctly — The design change was made, the alarm works, the label was updated.
2. The risk control measure is effective — It actually reduces the risk as intended.

Additionally, you must verify that:

3. The risk control does not introduce new hazards — Adding a guard might create a pinch point. Adding a software check might introduce a new failure mode if the check itself fails. Adding a battery backup introduces battery-related hazards (thermal runaway, leakage).
4. The risk control does not adversely affect the overall residual risk — The new control does not increase the severity or probability of other identified risks.

Verification activities must be documented, and the results must be traceable to the specific risk control measure being verified.

Residual Risk Evaluation

After all risk control measures have been implemented and verified, you must evaluate the residual risk for each hazardous situation.

If the residual risk for an individual hazard meets the acceptability criteria defined in the risk management plan, it is documented and accepted.

If the residual risk does not meet the acceptability criteria, you have two paths:

1. Implement additional risk control measures to further reduce the risk. Return to the risk control step.
2. Conduct a risk-benefit analysis to determine whether the medical benefit of the device outweighs the residual risk. This is discussed in detail in the next section.

Overall Residual Risk Evaluation

Beyond evaluating residual risk for each individual hazard, ISO 14971 requires an evaluation of the overall residual risk — the aggregate risk profile of the device after all individual risk controls are in place. This is a critical and often misunderstood requirement.

The overall residual risk evaluation considers:

• The cumulative effect of all individual residual risks
• Interactions between risks that might not be apparent when evaluating risks individually
• Whether the overall risk profile is acceptable given the device's intended use and clinical benefit

If the overall residual risk is judged unacceptable, a risk-benefit analysis is required. If the benefits do not outweigh the overall residual risk, the device design should be changed or the device should not be released.

This evaluation must be documented. Many organizations add an "Overall Residual Risk Evaluation" section to their risk management report.

Risk-Benefit Analysis

Risk-benefit analysis is triggered when a residual risk (individual or overall) does not meet the acceptability criteria defined in the risk management plan, and no further risk control measures are practicable.

The analysis asks: does the medical benefit of the device outweigh the residual risk?

This is a clinical and regulatory judgment, not just an engineering calculation. It should consider:

• The clinical benefit — What does the device enable that would not be possible without it? Does it improve patient outcomes, enable earlier diagnosis, reduce procedure time, reduce the need for more invasive alternatives?
• The severity of the condition being treated or diagnosed — Residual risks that would be unacceptable for a cosmetic device may be acceptable for a device that treats a life-threatening condition.
• Available alternatives — Are there other devices or treatments with better risk profiles? If so, the residual risk is harder to justify.
• State of the art — Is the residual risk consistent with what competent manufacturers achieve for similar devices?
• Published literature and clinical data — What does the evidence say about the benefit-risk profile?

If the benefit outweighs the residual risk, the decision must be documented along with the rationale. If it does not, the device should not be released.

Important: Risk-benefit analysis is not a loophole to accept any risk. It is a rigorous, evidence-based process. "Our device is clinically useful, therefore all residual risks are acceptable" is not a valid risk-benefit analysis. The analysis must be specific: which risks are being accepted, what is the specific clinical benefit that justifies acceptance, and what evidence supports the benefit claim.

Production and Post-Production Information

Risk management does not end when the device ships. ISO 14971 requires manufacturers to establish a system for collecting and reviewing production and post-production information relevant to the device's safety.

This information includes:

• Complaint data — Reports of adverse events, malfunctions, and user complaints
• Post-market surveillance data — Proactive data collection about device performance in the field
• Literature and standards — New scientific publications, updated standards, changes in the state of the art
• Regulatory intelligence — Safety alerts, recalls, and regulatory actions related to similar devices
• Manufacturing data — Process deviations, nonconformances, CAPA data that might indicate emerging hazards

When this information reveals previously unrecognized hazards, changes in risk estimates, or evidence that risk controls are less effective than assumed, the risk management process must be revisited. This means updating the risk analysis, re-evaluating risks, and implementing additional controls if needed.

The feedback loop between post-production information and risk management is one of the most important requirements in ISO 14971. It is also one of the most frequently cited deficiencies in regulatory audits.

Information Source	What to Look For	Action If Triggered
Complaints / adverse events	New hazardous situations, failure modes not previously identified, higher-than-estimated occurrence rates	Update risk analysis, re-estimate probability, evaluate need for additional controls
Post-market surveillance	Trends in device performance, emerging safety signals	Conduct trend analysis, update risk evaluation if statistical significance reached
Literature / standards	New hazards identified for similar devices, updated state of the art	Review applicability to your device, add to hazard identification if relevant
Regulatory actions on similar devices	Recalls, safety alerts, warning letters for comparable devices	Assess whether the same hazard exists in your device, update risk analysis
Manufacturing deviations / CAPA	Recurring nonconformances, process drift	Evaluate whether deviations affect risk estimates, update pFMEA if applicable

The Risk Management File

The risk management file is the complete documented record of your risk management process. It is not a single document — it is a collection of documents, records, and references that together demonstrate that risk management was performed in accordance with ISO 14971 and your risk management plan.

Required Contents

Document	Purpose
Risk management plan	Defines how risk management will be conducted, including scope, responsibilities, acceptability criteria, and methods
Risk analysis records	Hazard identification worksheets, FMEA/FTA/PHA worksheets, risk estimation records
Risk evaluation records	Risk matrix, risk acceptability decisions for each identified risk
Risk control records	Description of risk control measures, rationale for selected controls (including priority order justification), verification records
Residual risk evaluation	Individual residual risk assessments and overall residual risk evaluation
Risk-benefit analysis (if applicable)	Documented analysis for risks that exceed acceptability criteria
Risk management report	Summary document confirming that the risk management plan was implemented, overall residual risk is acceptable, appropriate methods are in place for production and post-production information collection
Production and post-production monitoring records	Evidence of ongoing surveillance and feedback into risk management

The Risk Management Report

The risk management report is a critical document — it is the summary conclusion of the risk management process. It must confirm:

1. The risk management plan has been appropriately implemented
2. The overall residual risk is acceptable (with rationale)
3. Appropriate methods are in place to collect and review production and post-production information
4. The risk management file is complete

The risk management report should be reviewed and approved by personnel with the authority to make risk acceptability decisions (as defined in the risk management plan). This typically includes representatives from quality, engineering, regulatory, and clinical affairs.

Common audit finding: The risk management report exists but is generic — it makes sweeping statements about risk acceptability without referencing specific evidence. A good risk management report is specific. It references the risk analysis results, identifies the highest residual risks, explains why the overall residual risk is acceptable, and confirms that post-production monitoring is in place. It should be a document that a reviewer can read and understand the device's risk profile without needing to dig through the entire risk management file.

Relationship to Other Standards and Regulations

ISO 14971 does not exist in isolation. It is deeply interconnected with quality management systems, regulatory requirements, and other standards.

ISO 14971 and ISO 13485

ISO 13485:2016 (Quality management systems for medical devices) references risk management repeatedly. Clause 7.1 requires risk management throughout product realization. Clause 7.3.3 requires risk management outputs as design inputs. Clause 8.2.3 requires investigation of complaints using risk management principles.

However, ISO 13485 does not define how to do risk management — it references ISO 14971 for that. The two standards are complementary:

Aspect	ISO 13485	ISO 14971
Focus	Quality management system	Risk management process
Scope	Organization-wide QMS	Device-specific risk management
Risk management role	Requires risk management as part of QMS processes	Defines the risk management process
Documentation	Quality manual, procedures, records	Risk management file
Relationship	Calls out risk management requirements; references ISO 14971	Provides the methodology that satisfies ISO 13485's risk management requirements

ISO 14971 and EU MDR (Regulation 2017/745)

The EU Medical Device Regulation makes risk management central to compliance. Article 10(2) requires manufacturers to establish, document, implement, and maintain a system for risk management. Annex I (General Safety and Performance Requirements — GSPRs) begins with the requirement that devices be designed and manufactured in such a way that they are suitable for their intended purpose and achieve the performance intended by the manufacturer, and that they do not compromise the clinical condition or safety of patients when used under normal conditions and for their intended purpose, provided that any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient.

The EU MDR references ISO 14971:2019 as a harmonized standard. When you apply a harmonized standard, you benefit from a "presumption of conformity" — meaning that compliance with the standard is accepted as evidence of compliance with the corresponding regulatory requirement.

Key considerations for EU MDR compliance:

• The MDR uses a broader definition of risk than ISO 14971:2007 did (which was already addressed in the 2019 revision). The MDR explicitly requires consideration of benefits and risks, not just risk reduction.
• The MDR requires that risk management be integrated with clinical evaluation. Your clinical evaluation report and risk management file should cross-reference each other.
• Annex I GSPRs require specific risk controls for specific hazard categories (electrical safety, radiation, software, biocompatibility, etc.). Your risk management process must demonstrate that each applicable GSPR is addressed.
• Post-market surveillance feeds directly into risk management. The MDR requires a structured PMS system that generates data used to update the clinical evaluation and risk management.

ISO 14971 and FDA Requirements

FDA does not directly reference ISO 14971 as a mandatory standard, but the alignment is strong:

• 21 CFR 820.30 (Design Controls) requires risk analysis as part of design input and design verification/validation
• 21 CFR 820.90 (Nonconforming Product) and 21 CFR 820.198 (Complaint Files) require risk-based decision-making
• The new QMSR (Quality Management System Regulation), which incorporates ISO 13485 by reference, inherently pulls in ISO 14971 risk management principles
• FDA guidance on premarket submissions (510(k), PMA, De Novo) expects a risk analysis — typically an FMEA or equivalent — as part of the submission
• FDA's guidance on software (IEC 62304) explicitly requires a risk management process per ISO 14971

FDA has recognized ISO 14971:2007 (the previous version) as a consensus standard. As of early 2026, the recognition of the 2019 version continues to be applied. Manufacturers can reference the standard in their submissions to support a presumption of conformity for risk management requirements.

ISO 14971 and Other Global Regulatory Frameworks

Beyond the EU and US, ISO 14971 is recognized or required by regulatory authorities worldwide:

Jurisdiction	Regulatory Authority	ISO 14971 Status
Canada	Health Canada	Required for medical device licenses; integrated with MDSAP audit program
Australia	TGA (Therapeutic Goods Administration)	Required; TGA audits against ISO 14971 as part of conformity assessment
Japan	MHLW/PMDA	Referenced in Japanese regulatory requirements; recognized through MDSAP
Brazil	ANVISA	ISO 14971 compliance required for device registration; audited through MDSAP
South Korea	MFDS	ISO 14971 recognized as part of the quality management system requirements

MDSAP (Medical Device Single Audit Program) audits cover risk management as one of five core process areas. MDSAP auditors evaluate risk management against ISO 14971 requirements and assess how well risk management is integrated with design controls, production controls, purchasing controls, and CAPA/post-market processes. For companies selling in MDSAP-participating countries (US, Canada, Australia, Brazil, Japan), a single MDSAP audit can satisfy risk management assessment requirements across all five jurisdictions.

ISO/TR 24971 — Guidance on the Application of ISO 14971

ISO/TR 24971:2020 is the companion technical report to ISO 14971. It is not a standard — it is guidance. But it is invaluable guidance. It provides:

• Practical examples of risk management processes
• Guidance on risk acceptability criteria and risk matrices
• Detailed discussion of risk-benefit analysis
• Guidance on production and post-production information
• Examples of risk management plans and risk management reports
• Guidance on how to address specific hazard categories

If you are implementing ISO 14971 for the first time, ISO/TR 24971 is essential reading. Think of it as the "how-to manual" that ISO 14971 (the "what to do" standard) does not provide.

IEC 62366-1 — Usability Engineering

IEC 62366-1 (Application of usability engineering to medical devices) addresses use-related risk — the risk that arises from the interaction between the user and the device. Use errors, close calls, and use-related hazardous situations identified through usability engineering must be fed into the ISO 14971 risk management process.

The two standards are deeply interlinked. Your use-related risk analysis (per IEC 62366-1) should be consistent with and traceable to your ISO 14971 risk management file. In practice, many companies maintain a single risk management file that incorporates both use-related and non-use-related hazards.

IEC 62304 — Medical Device Software Lifecycle

IEC 62304 (Medical device software — Software life cycle processes) requires that the software safety classification of a software system or software item be determined based on the risk management process per ISO 14971. The severity of harm that could result from a software failure, as determined through ISO 14971 risk analysis, drives the software safety classification (Class A, B, or C), which in turn determines the rigor of the software lifecycle activities required.

ISO 14971:2019 vs. ISO 14971:2007 — Key Changes

The 2019 revision brought significant changes. If you are transitioning from the 2007 version, or if your risk management process was originally built against the 2007 version, these are the changes you need to understand.

Area	ISO 14971:2007	ISO 14971:2019	Impact
Benefit-risk analysis	Mentioned but not emphasized; only triggered when individual residual risk is unacceptable	Central concept; required for overall residual risk evaluation; benefit considered alongside risk throughout	Organizations must integrate benefit assessment into the risk management process, not treat it as an exception
Terminology: "as far as possible"	Used "ALARP" (As Low As Reasonably Practicable) and "as low as practicable"	Uses "as far as possible" to avoid jurisdiction-specific legal interpretations of ALARP	Primarily a terminology change; the underlying principle is the same
Overall residual risk	Required overall residual risk evaluation but with less prescriptive guidance	Strengthened requirements for overall residual risk evaluation with clearer guidance	Organizations must demonstrate a more rigorous evaluation of cumulative residual risk
State of the art	Referenced but not defined	Explicitly defined in terms and definitions (Clause 3); emphasized throughout	Risk management decisions must explicitly consider the state of the art
Scope clarification	Focused on risks "associated with medical devices" broadly	Clarified that the scope covers risks to patients, operators, other persons, other equipment, and the environment	Ensures all affected parties are considered
Informative annexes	Contained in the standard itself	Moved to ISO/TR 24971:2020	The standard itself is more concise; detailed guidance is in the companion technical report
Production and post-production	Required but with less detail on what "relevant information" means	Expanded requirements; clearer guidance on what information to collect and how to use it	Organizations must strengthen their post-market feedback loops into risk management
Alignment with EU MDR	Predated EU MDR	Developed with awareness of EU MDR requirements	Better alignment with European regulatory expectations
Risk management plan	Required	Requirements expanded — must include method for evaluation of overall residual risk	Plans must be updated to include overall residual risk evaluation methodology
Risk management report	Required	Requirements clarified — must confirm completeness of risk management plan implementation and acceptability of overall residual risk	Reports need to be more specific and evidence-based

Clause-Level Changes in Detail

For teams performing a detailed crosswalk between the two editions, here are the specific structural and content changes at the clause level:

Structural changes:

• The 2019 edition has 10 main clauses compared to 9 in the 2007 edition. A new Clause 2 ("Normative references") was added, stating that no other standards are required to establish and maintain a risk management process per ISO 14971. This shifted the numbering of all subsequent clauses.
• The title of Clause 9 changed from "Risk management report" to "Risk management review" — emphasizing that a review must occur, not just a report be written. The reviewers must now be identified in the risk management plan in advance of the review.
• Clause 10 (Production and Post-Production Activities) was expanded from a single clause into four sub-clauses (10.1 through 10.4), covering information collection, information review, actions on specific devices, and actions on the risk management process separately.

Specific content changes by clause:

Clause (2019)	Change	Detail
Clause 3 (Terms and definitions)	"State of the art" formally defined	Previously referenced but never defined in the standard; now given a precise definition
Clause 3	"Benefit" added as a defined term	New definition supporting the expanded benefit-risk analysis requirements
Clause 3	"Reasonably foreseeable misuse" definition updated	Aligned with IEC 62366-1 usability terminology
Clause 4.4 (Risk management plan)	Method for overall residual risk evaluation required	Plans must now explicitly describe the methodology for evaluating overall residual risk
Clause 4.4	Criteria for overall residual risk acceptability required	Separate from individual risk acceptability criteria
Clause 7 (Risk control)	"As far as possible" replaces "ALARP" language	Removes jurisdiction-specific legal connotations
Clause 8 (Overall residual risk)	Disclosure of residual risk statement added	Manufacturers must document how residual risks are disclosed to users
Clause 9 (Risk management review)	Determines when subsequent reviews are needed	Not just a one-time review; must define triggers for re-review and report updates
Clause 10.2 (Information review)	Includes changes in "generally accepted state of the art"	Explicit requirement to monitor evolving best practices
Clause 10.3 (Actions)	Separates actions for specific devices vs. risk processes	Also adds consideration of devices already on the market, not just the device under development

Annex changes:

The most significant structural change was the relocation of informative annexes to ISO/TR 24971:2020. The 2007 edition contained 10 informative annexes (A through J) covering practical examples and guidance. The 2019 edition retains only 3 informative annexes:

• Annex A — Rationale for requirements
• Annex B — Risk management process for medical devices (overview)
• Annex C — Fundamental risk concepts

The former annexes on hazard examples, risk analysis techniques, and risk management plan/report examples now live in ISO/TR 24971:2020, which also added new content:

• Annex G — Guidance on risk management for cybersecurity (new)
• Annex H — Guidance on assessing and remediating risk management files of devices that previously did not comply with ISO 14971 (new — particularly valuable for IVD manufacturers affected by IVDR reclassification)

Practical Transition Steps

If your risk management system was built on ISO 14971:2007, here is what you need to do:

1. Update your risk management plan template to include the method for overall residual risk evaluation and to reference the 2019 version
2. Review your risk acceptability criteria — ensure they include provisions for benefit-risk analysis
3. Add an overall residual risk evaluation to each device's risk management file if one does not already exist
4. Review terminology — replace "ALARP" with "as far as possible" if needed for regulatory alignment, though continuing to use ALARP internally is fine as long as the intent aligns with the standard
5. Obtain ISO/TR 24971:2020 and review it against your current practices — the informative annexes that were previously in the standard are now there
6. Update your risk management report template to explicitly confirm plan implementation and overall residual risk acceptability
7. Review post-production information processes to ensure they meet the expanded requirements

Real-World Examples: When Risk Management Fails

Understanding ISO 14971 in the abstract is one thing. Understanding what happens when it is applied poorly — or not at all — is what makes risk management real. These examples illustrate why every clause in the standard exists.

Medtronic MiniMed Insulin Pump Cybersecurity Recall (2019)

In 2019, Medtronic issued a Class I recall (the most serious category) affecting over 1,000 MiniMed 508 and MiniMed Paradigm series insulin pumps. The FDA determined that the wireless communication protocol used by the pump's optional remote control was vulnerable to cybersecurity exploitation. An unauthorized person with specialized technical skills and equipment could potentially connect wirelessly to a nearby pump and instruct it to either over-deliver insulin (causing life-threatening hypoglycemia) or stop insulin delivery entirely (causing hyperglycemia and diabetic ketoacidosis, which can be fatal).

Risk management lessons:

• Hazard identification gap: The original risk analysis did not adequately identify cybersecurity-related hazards for the wireless communication interface. At the time of initial design, cybersecurity threats to medical devices were not broadly recognized, but the state of the art evolved — and the risk file was not updated to reflect it.
• Post-production monitoring failure: As cybersecurity threats to medical devices became well-documented in the years before the recall, the risk management file should have been updated. The feedback loop between emerging threat intelligence and the risk management process was insufficient.
• Risk control hierarchy: The vulnerability was in the communication protocol design — an inherent safety by design issue (Tier 1 risk control). No amount of labeling or user training (Tier 3) could adequately control a risk that required a fundamental design change.

Cordis Precise PRO Carotid Stent System Recall (2021)

Cordis recalled its Precise PRO Rx US Carotid Stent System due to a manufacturing issue where the stent's delivery system could malfunction, potentially causing the stent to deploy incorrectly or not at all during a carotid artery procedure. An incorrectly deployed stent in the carotid artery could lead to stroke or death.

Risk management lessons:

• Process FMEA gap: The manufacturing failure mode was not adequately captured in the process FMEA, or the risk controls for that failure mode were insufficient.
• Severity vs. probability: This is a high-severity, potentially catastrophic hazard (stroke, death). Even a very low probability of occurrence results in an unacceptable risk level when severity is catastrophic — the risk matrix correctly flags this.

Guidewire Coating Flaking — FMEA vs. ISO 14971 Perspective

The FDA recalled a Class I guidewire intended for percutaneous catheter navigation through blood vessels. The guidewire coating had the potential to flake off inside the patient's vasculature. From a traditional FMEA perspective, "coating flaking" might be scored as a moderate-severity failure mode (partial loss of device function). But from the ISO 14971 perspective — which evaluates severity based on harm to the patient, not device performance — particles released into the bloodstream can cause embolism, stroke, or death. This is a Severity 5 (Catastrophic) hazard.

This example illustrates a critical point: FMEA severity ratings based on device function do not substitute for ISO 14971 severity ratings based on patient harm. Many organizations maintain separate FMEA severity scales (device-function-oriented) and ISO 14971 severity scales (patient-harm-oriented), with a documented mapping between them.

Heart-Lung Machine: End-to-End Risk Analysis

A heart-lung machine (cardiopulmonary bypass device) provides a comprehensive illustration of ISO 14971 in practice because it involves nearly every hazard category simultaneously:

Hazard Category	Specific Hazards	Potential Harm
Energy (mechanical)	Roller pump occlusion — tubing rupture due to over-occlusion; inadequate flow due to under-occlusion	Air embolism, tissue ischemia, organ failure, death
Energy (electrical)	Leakage current through blood-contacting circuit	Cardiac arrhythmia, fibrillation
Biological	Blood-contacting surfaces causing hemolysis, complement activation, or thrombogenesis	Organ damage, stroke, systemic inflammatory response
Chemical	Plasticizer leaching from PVC tubing (DEHP)	Potential toxic exposure, particularly in neonatal and pediatric patients
Operational	Gas blender delivering incorrect FiO2; flow rate sensor providing inaccurate reading	Hyperoxia, hypoxia, inadequate perfusion
Software	Control algorithm calculates incorrect pump speed; user interface displays wrong parameter	Inadequate perfusion, air embolism, hemodynamic instability
Information	Inadequate training of perfusionist on device-specific alarms and override procedures	Delayed response to critical alarms, incorrect manual override
Environmental	Electromagnetic interference from electrosurgical unit (ESU) affecting device electronics	Loss of monitoring function, erroneous readings during critical procedure

This type of multi-hazard, high-severity device requires all risk analysis techniques in combination: PHA during concept, design and process FMEA during development, FTA for critical failure scenarios (e.g., "complete loss of perfusion"), and HACCP principles for blood-handling and sterilization processes.

Common Audit Findings

Auditors — whether from Notified Bodies, FDA investigators, or internal audit teams — consistently identify the same types of risk management deficiencies. Knowing these in advance helps you avoid them.

Top 10 Audit Findings

#	Finding	Why It Happens	How to Fix It
1	Incomplete hazard identification	Team relied on a single brainstorming session or only used Annex C without device-specific analysis	Use multiple techniques (PHA, FMEA, FTA), involve cross-functional team (engineering, clinical, manufacturing, service), review complaint data and literature for similar devices
2	Risk management not updated post-market	Risk management file was completed during design and never revisited	Establish formal triggers for risk file review — complaints, CAPAs, design changes, new literature, regulatory actions on similar devices
3	Risk acceptability criteria not defined before analysis	Criteria were reverse-engineered to fit the results	Define risk acceptability criteria in the risk management plan before performing risk analysis; have the plan approved before analysis begins
4	Risk controls not verified	Verification was assumed based on design verification testing but not explicitly linked	Create explicit traceability from each risk control measure to a verification activity and result
5	Severity reduced by risk controls	Team changed severity rating based on adding a protective measure, which is conceptually incorrect — the potential harm is the same; only the probability of it occurring changes	Severity is a characteristic of the harm, not the likelihood. Risk controls reduce probability or detection, not severity. The only way to reduce severity is to change the hazard itself
6	No overall residual risk evaluation	Team evaluated each risk individually but did not assess the cumulative risk profile	Add a dedicated overall residual risk evaluation section to your risk management report
7	Risk-benefit analysis is superficial	Analysis says "device provides clinical benefit, therefore risk is acceptable" without evidence	Cite specific clinical evidence, compare to alternatives, reference state of the art, be specific about which risks are being accepted and why
8	Foreseeable misuse not addressed	Team only analyzed intended use scenarios	Review use-related hazards with clinical users, analyze complaint data for off-label use, conduct formative usability studies
9	Risk management plan not updated when design changes	Plan was written at project start and never revised to reflect scope changes, new intended uses, or design pivots	Include plan review as a required activity at each design review milestone
10	Traceability gaps between risk management and design controls	Risk management and design processes run in parallel but are not linked	Risk management outputs (risk controls) should appear as design inputs; design verification activities should include risk control verification; requirements traceability matrix should reference risk file

The Seven Error Classes Identified by Auditors

The Johner Institute, a leading European regulatory training and consulting organization whose staff includes active Notified Body auditors, has categorized risk management deficiencies into seven recurring error classes based on their audit experience. These complement the top-10 findings above and provide a different lens on where organizations go wrong.

Error Class	Description	Root Cause	Prevention
1. Incorrect use of terminology	Confusing hazard, hazardous situation, harm, and risk. Entering device malfunctions in the "hazard" column, or listing harm as a hazard. Calculating risk as a simple product of severity and probability (which is not mathematically meaningful in a qualitative scale). Using Risk Priority Number (RPN) as though it equals "risk" per ISO 14971.	Insufficient training on ISO 14971 definitions	Train all risk management team members on ISO 14971 terminology before beginning analysis. Conduct terminology calibration sessions before each FMEA or risk analysis workshop.
2. No systematically derived acceptance criteria	Defining acceptance criteria globally in an SOP and applying identically to all devices. Not matching the benefit described in clinical evaluation to the benefit used in risk-benefit analysis. Imprecise probability and severity class definitions with ambiguous boundaries.	Treating risk management as a template exercise	Derive criteria for each device based on its specific intended use, patient population, clinical context, and applicable regulations. Validate that severity level descriptors include device-specific clinical examples.
3. Incomplete hazards and risks	Gaps in hazard identification from inaccurate application of analysis methods. Failure to transfer design FMEA findings into the ISO 14971 risk table. Neglecting usability-related risks due to absent or insufficient formative/summative usability testing. Analyzing hazards after implementing mitigation measures rather than before.	Single-technique approach, lack of clinical input, insufficient cross-functional participation	Use multiple hazard identification techniques. Ensure FMEA results flow into the risk management file. Begin hazard identification before controls are considered. Include usability engineering outputs.
4. Risks incorrectly assessed	Misjudging probability because the complete chain of events was not traced. Assuming the greatest risk always occurs at the highest severity levels (a low-severity but very high-probability hazard can be a greater concern). Staff lacking clinical or technical expertise to estimate severity or probability accurately.	Insufficient expertise, incomplete sequence-of-events analysis	Walk through every step from hazard to harm. Use quantitative data when available. Include clinical experts who understand real-world consequences.
5. Post-production risks overlooked	Neglecting risks that arise during production and field use. Not updating the risk analysis when production processes change. Failing to use post-market surveillance data to improve risk estimates.	Risk management treated as a design-phase activity	Establish explicit triggers for risk file updates based on production data, complaints, CAPAs, and PMS reports. Make post-production risk review a standing agenda item in management review.
6. Insufficient verification of risk control measures	Failing to verify both that a measure was implemented and that it is effective. These are two separate verification activities and both are required. Relying on training and labeling (Tier 3 controls) without justifying why inherently safe design (Tier 1) is not practicable.	Conflating implementation with effectiveness	Create separate verification records for implementation and effectiveness. Document rationale when Tier 1 controls are not adopted.
7. Formal documentation errors	Missing reviews and approvals on risk documents. Illogical creation and release dates (e.g., risk management report dated before the risk analysis it summarizes). Inability to trace which device version corresponds to which document version. Missing required documents (plan or report). Risk management report lacking required conformity statements.	Poor document control, risk management not integrated with QMS	Apply the same document control rigor to risk management documents as to any other QMS record. Use electronic QMS tools with audit trails and version control.

Audit Statistics and Patterns

While comprehensive public statistics on risk management audit findings are limited, several data points from Notified Body and regulatory reports indicate the scale of the problem:

• Risk management is consistently among the top 3 areas of nonconformity cited by EU Notified Bodies during MDR and IVDR technical documentation reviews. Alongside clinical evaluation and post-market surveillance, risk management deficiencies account for a disproportionate share of major nonconformities.
• FDA 483 observations related to design controls (21 CFR 820.30) frequently cite inadequate risk analysis as a root cause. The transition to the new QMSR, which incorporates ISO 13485 by reference, is expected to increase the specificity of risk management-related findings.
• The most common single finding across all auditor reports is incomplete hazard identification — the failure to identify hazards that a competent team, applying the state of the art, should have identified. This is particularly damaging because it undermines every downstream step: you cannot evaluate, control, or monitor a risk you have not identified.
• Post-market feedback loop failures are the second most frequently cited category. Auditors report finding risk management files that were completed during design and development and never updated despite years of commercial distribution, accumulating complaint data, and evolving standards.
• Among Notified Bodies auditing under EU MDR, common additional findings include: lack of clarity on why specific GSPRs were deemed applicable or not applicable, insufficient information on how GSPRs are addressed in labeling and IFU, and risk management files that reference outdated versions of standards.

Severity-Specific Mistakes to Avoid

Do not reduce severity when you add a risk control. This is one of the most common and most fundamental errors. If the potential harm is "third-degree burn to patient tissue," that harm is severity level 4 (critical) whether or not you have added a temperature sensor with an alarm. The alarm reduces the probability that the hazardous situation will lead to harm. It does not change the severity of a third-degree burn if it does occur.

There is one exception: if you change the hazard itself — for example, by selecting a lower-wattage heating element that is physically incapable of reaching a temperature that could cause a third-degree burn — then the maximum severity genuinely changes because the physical mechanism for producing the original harm no longer exists.

Do not conflate probability of failure with probability of harm. If a battery has a 1% chance of overheating, and an overheated battery has a 10% chance of rupturing, and a ruptured battery has a 50% chance of causing a burn, the probability of harm is 1% x 10% x 50% = 0.05%, not 1%. Walk through the sequence of events.

Practical Tips for Implementation

Starting From Scratch

If you are building a risk management process for the first time, here is a suggested approach:

1. Buy and read the standard. ISO 14971:2019. Also get ISO/TR 24971:2020. These are not optional — you need to understand the requirements directly, not through secondhand summaries.

2. Define your risk management plan template. This is the foundational document. Include risk acceptability criteria (severity scale, probability scale, risk matrix, and acceptability boundaries), define the risk analysis methods you will use, specify roles and responsibilities, and describe how post-production information will be collected and reviewed.

3. Assemble a cross-functional risk management team. Risk management is not a one-person job. At minimum, include: a design engineer, a quality engineer, a manufacturing/process engineer, a clinical or regulatory affairs professional, and someone with direct knowledge of how the device is used clinically.

4. Conduct hazard identification systematically. Use Annex C of ISO 14971 (hazard examples) and ISO/TR 24971 as starting points. Review predicate device complaint history, published literature on similar devices, and applicable standards (IEC 60601-1 for electrical safety, ISO 10993 for biocompatibility, IEC 62366-1 for usability, etc.).

5. Perform risk analysis using FMEA (or your chosen technique). Estimate severity and probability for each hazardous situation. Document your rationale for each estimate.

6. Evaluate risks against your criteria. Apply the risk matrix. Identify which risks require reduction.

7. Implement risk controls following the priority order: inherent safety by design, protective measures, information for safety.

8. Verify risk controls. Link each control to a verification activity. Confirm effectiveness. Confirm no new hazards are introduced.

9. Evaluate residual risk — both individual and overall. Conduct risk-benefit analysis if needed.

10. Write the risk management report. Summarize the process, confirm completeness, document the acceptability of overall residual risk, and confirm post-production monitoring is in place.

11. Establish the post-production feedback loop. Define how complaint data, PMS data, CAPA results, and new information will trigger risk file reviews.

Scaling Risk Management for Different Device Types

The depth and rigor of your risk management process should be proportionate to the device's risk profile.

Device Type	Risk Profile	Risk Management Approach
Class I (low risk) — e.g., tongue depressor, elastic bandage	Simple device, well-understood hazards, low severity	Streamlined PHA or simplified FMEA; risk matrix may use fewer levels; risk management file is compact but complete
Class II (moderate risk) — e.g., infusion pump, powered surgical instrument	Moderate complexity, electrical/mechanical/software hazards, moderate to high severity potential	Full FMEA (design and process), formal risk matrix, thorough risk control verification, comprehensive risk management file
Class III (high risk) — e.g., cardiac pacemaker, total hip replacement	Complex device, multiple interacting hazard categories, high severity potential, long-term implantation	Extensive FMEA plus FTA for critical failure scenarios, quantitative risk analysis where feasible, detailed risk-benefit analysis, comprehensive post-market surveillance feeding back into risk management
Software as Medical Device (SaMD)	Unique hazard profile — no physical energy hazards, but information-based harm (misdiagnosis, incorrect therapy recommendation)	FMEA focused on software failure modes, algorithm errors, data integrity; FTA for critical clinical decision paths; integration with IEC 62304 software safety classification; cybersecurity risk analysis
Combination products	Multiple hazard categories from device and drug/biologic components	Separate risk analyses for each component plus integrated analysis of combination-specific hazards (drug-device interaction, delivery mechanism failures)

Integrating Risk Management with Design Controls

Risk management and design controls are not parallel activities — they are intertwined.

• Design inputs should include risk management outputs (risk controls that need to be designed into the device)
• Design outputs should be evaluated against identified hazards
• Design reviews should include risk management review as a standing agenda item
• Design verification should include risk control verification
• Design validation should confirm that risk controls are effective in the intended use environment
• Design changes should trigger a review of the risk management file to determine whether the change introduces new hazards or alters existing risk estimates

The requirements traceability matrix (RTM) should include references to the risk management file. If a design requirement exists because of a risk control, that linkage should be explicit and traceable in both directions.

Common Pitfalls to Avoid

Beyond the audit findings listed earlier, here are practical mistakes that organizations make during implementation:

Treating risk management as a documentation exercise. If your risk management process consists of filling in a spreadsheet template after the design is complete, you are doing it wrong. Risk management should drive design decisions in real time. The FMEA session where an engineer says "We should change this material because the current one has a biocompatibility risk" — that is risk management working. The spreadsheet is just the record.

One-and-done risk management. Some organizations complete the risk management file during design, archive it, and never look at it again until an audit. This violates the standard and, more importantly, it misses real safety signals. Risk management is a lifecycle process.

Copy-pasting from another device. Starting from a similar device's risk management file is efficient, but every hazard, every risk estimate, and every risk control must be reviewed and validated for the new device. Blindly copying creates two problems: you carry forward hazards that do not apply (wasting effort on irrelevant controls) and you miss hazards that are unique to the new device.

Ignoring the state of the art. When a new standard is published, a new technology becomes available, or a competitor demonstrates a safer design approach, the state of the art has changed. Your risk acceptability decisions must reflect this. A residual risk that was acceptable five years ago may no longer be acceptable if the state of the art now provides a practicable means to reduce it further.

Insufficient clinical input. Engineers understand failure modes. Clinicians understand how devices are actually used. Risk management needs both perspectives. If your risk management team does not include someone with clinical knowledge of the device's use environment, your hazard identification will have blind spots.

Software Risk Management: Detailed Guidance

Software-driven medical devices — both Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD) — present unique risk management challenges that warrant specific attention beyond what the general ISO 14971 process covers.

How ISO 14971 and IEC 62304 Work Together

ISO 14971 and IEC 62304 are not separate processes — they are two halves of a single regulatory expectation. ISO 14971 gives you the "why and what" of risk management (identify hazards, evaluate risks, control them). IEC 62304 gives you the "how" of building medical software safely (planning, requirements, design, implementation, verification, release, maintenance). For software-driven devices, both standards apply simultaneously and must be integrated at every step.

The integration works as follows:

1. System-level hazard analysis (ISO 14971): Identify all hazards associated with the device, including those where software is a contributing cause.
2. Software safety classification (IEC 62304): Based on the ISO 14971 risk analysis, classify the software system and its software items into safety classes:

IEC 62304 Safety Class	Definition	Development Rigor Required	Example
Class A	Software that cannot contribute to a hazardous situation, or whose contribution to a hazardous situation does not result in unacceptable risk after consideration of external risk control measures	Minimal — software requirements and release documentation	Administrative scheduling software, non-clinical data logging
Class B	Software that can contribute to a hazardous situation that could result in non-serious injury	Moderate — architecture, verification, integration testing required	Alarm systems for non-critical conditions, visualization tools for physiological parameters, dosage calculators without direct control
Class C	Software that can contribute to a hazardous situation that could result in death or serious injury	Maximum — detailed design, unit verification, integration testing, full traceability	Infusion pump control software, ventilator algorithms, radiation therapy planning software, AI-driven diagnostic algorithms

3. Software-specific risk controls (IEC 62304 + ISO 14971): Implement risk controls through the software architecture and design. For example, if hazard analysis reveals that missing data validation could cause a misdiagnosis, the control is additional input validation coded into the software — which becomes a formal requirement in the Software Requirements Specification (SRS), traceable back to the hazard.
4. Verification of software risk controls (IEC 62304): Each software risk control must be verified through testing. IEC 62304 requires traceability from hazard identification through requirements, design, implementation, and test results.
5. Post-market monitoring feeds back to both processes: Software updates, bug fixes, field incidents, and cybersecurity events must be evaluated against both the ISO 14971 risk management file and the IEC 62304 software maintenance process.

Critical concept — the 100% failure rate assumption: IEC 62304 takes a conservative approach to software failure probability. Unlike hardware, where failure rates can be estimated from reliability data, software failures are systematic (design errors, not random wear-out). IEC 62304 effectively assumes a 100% probability of failure as the worst case when classifying software safety — meaning the safety classification is driven entirely by the severity of harm that could result from the failure, not by an estimate of failure probability. This is why robust external risk control measures (hardware interlocks, independent monitoring systems) are so important for reducing the effective safety class of software items.

SaMD-Specific Risk Considerations

Software as a Medical Device introduces hazard categories that traditional hardware devices do not have — and eliminates some that hardware devices always have. SaMD has no sharp edges, no leakage current, and no moving parts. But it has its own distinct risk profile:

Information-based harm: The primary mechanism of harm for SaMD is not the transfer of energy to a patient (as with electrical or mechanical devices) but the influence of information on clinical decisions. A SaMD that provides a false-negative cancer screening result does not physically injure the patient — but the delayed diagnosis can lead to disease progression, delayed treatment, and potentially death. The harm is real; the mechanism is different.

SaMD-specific hazard categories:

Hazard Category	Examples	Potential Harm
Algorithm errors	Incorrect diagnostic classification, false positives/negatives, biased model outputs, edge-case failures	Misdiagnosis, delayed treatment, unnecessary treatment, patient anxiety
Data integrity	Corrupted input data, incorrect data mapping between systems, loss of patient data during transfer, incorrect DICOM parsing	Diagnosis based on wrong patient data, treatment applied to wrong patient, loss of critical clinical information
User interface errors	Misleading visualization, ambiguous result presentation, hidden critical information, inconsistent units	Clinician misinterpretation of results, incorrect clinical decision
Interoperability failures	Incompatible data formats between systems, version mismatch with connected devices, API failure	Loss of data, incorrect data transformation, failure to communicate critical results
Performance degradation	Model drift over time, reduced accuracy on populations different from training data, latency exceeding clinical decision timelines	Gradual decrease in diagnostic accuracy that may not be immediately apparent
Cybersecurity	Unauthorized access to patient data, manipulation of algorithm inputs or outputs, ransomware affecting device availability	Privacy breach, manipulated clinical results, loss of device availability during critical procedures

AI/ML-specific risk management considerations:

The emergence of AI and machine learning-based SaMD introduces additional risk dimensions that go beyond traditional software risk management. Standards such as BS/AAMI 34971:2023 provide specific guidance for managing risks of AI/ML-based medical devices. Key additional considerations include:

• Training data bias: If the training dataset does not represent the intended patient population (e.g., under-representation of certain skin tones in a dermatological AI, or under-representation of pediatric patients), the algorithm may perform poorly or dangerously on underrepresented groups. This must be identified as a hazard and controlled through dataset validation, subgroup analysis, and clinical validation across diverse populations.
• Model opacity (black box problem): For complex ML models, it may not be possible to trace exactly why a specific output was generated. This limits the effectiveness of traditional root-cause analysis for adverse events and must be addressed through explainability measures, validation against known ground truth, and robust post-market performance monitoring.
• Adaptive/learning algorithms: If the SaMD continues to learn from new data after deployment, its behavior may change over time in ways not anticipated during pre-market risk analysis. Each update to the model — whether automatic or manual — must trigger a re-evaluation of the risk management file.

Cybersecurity Risk Management

Cybersecurity risk management for medical devices has become a critical topic addressed by ISO/TR 24971:2020 Annex G (new in the 2020 revision), IEC 81001-5-1 (Health software and health IT systems safety, effectiveness and security), and the FDA's updated guidance on cybersecurity in medical devices (February 2026).

How cybersecurity risk fits into ISO 14971:

Cybersecurity vulnerabilities are treated as hazards under ISO 14971 when exploitation of the vulnerability could lead to patient harm. The key distinction is that ISO 14971 evaluates cybersecurity risks through the lens of patient safety — not information security alone. A data breach that exposes patient records is a privacy concern, but under ISO 14971, the relevant question is: could this breach lead to physical harm? If an attacker can modify device settings, alter diagnostic outputs, or disable safety alarms, the cybersecurity vulnerability becomes a safety hazard.

Integration approach:

1. Threat modeling — Identify potential threat actors, attack vectors, and exploitable vulnerabilities. Use frameworks such as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) adapted for the medical device context.
2. Hazard analysis — For each identified cybersecurity threat, determine whether exploitation could lead to a hazardous situation and ultimately patient harm. Map cybersecurity threats to ISO 14971 hazards.
3. Risk evaluation — Evaluate the severity and probability of harm using ISO 14971 criteria. Note that probability estimation for cybersecurity risks is fundamentally different from hardware reliability — it depends on attacker motivation, capability, and opportunity rather than random failure rates.
4. Risk control — Apply the ISO 14971 priority order: secure design by default (inherent safety), protective security measures (encryption, authentication, access controls, intrusion detection), and information for safety (security hardening guides for users).
5. Post-market monitoring — Continuously monitor for new cybersecurity threats, vulnerabilities, and exploits. Cybersecurity threats evolve faster than traditional hardware hazards — quarterly vulnerability assessments and participation in Information Sharing and Analysis Organizations (ISAOs) are recommended practices.

IVD-Specific Risk Management Considerations

While ISO 14971 applies to all medical devices including in vitro diagnostic devices (IVDs), IVDs present distinct risk management challenges that require specific attention — particularly under the EU IVDR (Regulation 2017/746).

How IVD Risk Differs from General Medical Device Risk

The fundamental difference is in the mechanism of harm. Most medical devices interact physically with the patient (electrical energy, mechanical force, thermal energy, biocompatible materials in contact with tissue). IVDs primarily interact with patient samples — blood, urine, tissue specimens — not the patient directly. The harm from an IVD is almost always information-based: a wrong result leads to a wrong clinical decision, which leads to patient harm.

This distinction has important implications for risk analysis:

Risk Dimension	Traditional Medical Device	In Vitro Diagnostic Device
Primary harm mechanism	Direct energy transfer or material interaction with patient	Incorrect diagnostic information leading to wrong clinical decision
Severity assessment	Based on physical harm from device interaction	Based on clinical consequences of incorrect diagnosis or monitoring
Probability estimation	Based on device failure rates, use error rates, environmental factors	Based on analytical performance (sensitivity, specificity, accuracy), pre-analytical variables, and clinical decision pathways
Key hazard categories	Electrical, mechanical, thermal, biological, chemical	Analytical errors (false positive/negative), specimen handling, reagent stability, interference, cross-reactivity, software-related errors
Risk control emphasis	Device design, protective measures, labeling	Analytical performance validation, quality control procedures, result interpretation guidance, reference intervals

IVD-Specific Hazard Categories

Beyond the general hazard categories in ISO 14971 Annex C, IVDs require analysis of hazards specific to the diagnostic process:

IVD Hazard Category	Examples	Potential Harm
Pre-analytical errors	Wrong sample type collected, improper sample storage, hemolysis, lipemia, sample mix-up	Incorrect result leading to misdiagnosis or wrong treatment
Analytical errors	Assay interference (heterophilic antibodies, bilirubin, hemoglobin), hook effect in immunoassays, cross-reactivity with structurally similar analytes, lot-to-lot variability	False positive (unnecessary treatment, patient anxiety, invasive follow-up) or false negative (missed diagnosis, delayed treatment)
Post-analytical errors	Incorrect reference intervals, results reported in wrong units, critical values not flagged, results associated with wrong patient	Treatment decisions based on misinterpreted results
Reagent/consumable hazards	Reagent degradation beyond shelf life, calibrator instability, quality control material matrix effects	Systematic analytical errors affecting entire patient populations tested with the affected lot
Instrument hazards	Carryover between samples, probe clogging, optical system degradation, temperature control failure	Sporadic or systematic analytical errors

IVDR-Specific Requirements vs. ISO 14971

The EU IVDR has several risk management requirements that go beyond ISO 14971:

Benefit-risk analysis for all risks: The most significant difference between ISO 14971 and the IVDR is that the standard only requires a benefit-risk analysis when risks are unacceptable after risk controls have been applied. The IVDR requires that a benefit-risk analysis be performed for all risks and the overall residual risk, regardless of whether they meet acceptability criteria. This means your technical file submission must include a benefit-risk analysis even if all individual risks fall within acceptable limits.

IVDR reclassification impact: The IVDR significantly reclassified many IVD devices compared to the previous IVD Directive (IVDD). Devices that were previously self-certified under List A or List B, or fell outside the annexes entirely, may now be classified as Class B, C, or D under IVDR — requiring Notified Body involvement for the first time. For devices affected by reclassification, manufacturers may need to build or substantially upgrade risk management files that were previously minimal. ISO/TR 24971:2020 Annex H provides specific guidance for assessing and remediating risk management files for devices that previously did not comply with ISO 14971.

Performance evaluation integration: The IVDR requires a very comprehensive performance evaluation covering scientific validity, analytical performance (sensitivity, specificity, accuracy, precision, repeatability, reproducibility), and clinical performance. The performance evaluation data directly feeds into risk estimation — your probability estimates for analytical errors must be supported by your analytical performance data, and any gaps in performance data must be reflected as uncertainties in your risk estimates.

EU Reference Laboratories (EURLs): For IVDR Class D products (e.g., HIV tests, hepatitis tests, blood typing reagents), EU Reference Laboratories perform independent batch testing. Risk management files for Class D devices must account for the additional quality verification provided by EURL testing and how it affects residual risk estimates.

Practical tip for IVD manufacturers: When building your risk management file, structure your hazard identification around the total testing process (pre-analytical, analytical, post-analytical phases) rather than only around the device itself. Many IVD-related patient harms arise from the interface between the device and the laboratory workflow — sample handling, result interpretation, quality control procedures — not from the analytical instrument alone. ISO/TR 24971:2020 includes a specific annex on risk management considerations for IVD devices that provides additional guidance.

A Worked Example: Hazard to Risk Control

To illustrate how the ISO 14971 process works end to end, here is a simplified example for a hypothetical battery-powered portable patient monitor.

Device: Portable patient monitor (SpO2, heart rate, ECG). Battery-powered, intended for use in hospital and ambulance settings. Class IIa (EU MDR).

Step 1: Hazard identification

Hazard ID	Hazard	Hazard Category
H-001	Electrical energy (battery)	Energy
H-002	Inaccurate SpO2 reading	Operational
H-003	Loss of monitoring function (device shutdown)	Operational
H-004	Electromagnetic interference (EMI)	Environmental
H-005	Biocompatibility of skin-contact sensors	Biological

Step 2: Risk analysis (for H-002 — Inaccurate SpO2 reading)

Element	Detail
Hazard	Inaccurate SpO2 reading
Sequence of events	Sensor degradation or software algorithm error causes SpO2 to display a value that is inaccurately high (e.g., displays 97% when actual is 85%)
Hazardous situation	Clinician relies on falsely normal SpO2 reading and does not intervene for a hypoxic patient
Harm	Delayed treatment of hypoxemia; potential organ damage or death
Severity	S5 (Catastrophic) — death is a possible outcome
Probability (before controls)	P3 (Remote) — sensor degradation is infrequent, and clinicians often use multiple assessment methods
Initial risk level	High (S5 x P3)

Step 3: Risk evaluation

Per the risk matrix, S5 x P3 = High. Risk reduction is required.

Step 4: Risk control

Priority	Risk Control Measure
1. Inherent safety by design	Select sensor technology with self-diagnostic capability that detects signal quality degradation. Implement algorithm validation against a clinically diverse patient population to minimize systematic inaccuracy.
2. Protective measure	Implement a Signal Quality Index (SQI) that suppresses SpO2 display and generates an alarm when signal quality falls below a defined threshold. Add a "sensor check" indicator visible to the clinician.
3. Information for safety	Label: "This device is intended as an adjunct in patient assessment. Clinical decisions should not be based solely on pulse oximetry readings." IFU: Instructions for sensor placement, troubleshooting, and clinical interpretation.

Step 5: Risk control verification

Verification Activity	Result
Bench testing: Verify SQI algorithm detects simulated sensor degradation scenarios	SQI correctly triggered alarm in 98/100 simulated degradation scenarios. Two missed scenarios were edge cases that were addressed by adjusting threshold.
Clinical validation: Verify SpO2 accuracy against arterial blood gas in controlled desaturation study per ISO 80601-2-61	Arms (root mean square) accuracy within +/- 2% SpO2 across 70-100% SpO2 range
Verify no new hazards: Review whether SQI alarm introduces nuisance alarm fatigue risk	SQI alarm false-positive rate measured at less than 0.5% during clinical validation. Alarm volume and escalation protocol reviewed against IEC 60601-1-8. Added to risk file as new hazard H-006 with residual risk assessment.

Step 6: Residual risk evaluation

Element	Post-Control Value
Severity	S5 (Catastrophic) — unchanged, because the potential harm is the same
Probability	P1 (Incredible) — with SQI suppression, algorithm validation, and clinical labeling, the probability of a clinician relying on a falsely normal reading without any indication of poor signal quality is extremely low
Residual risk	Medium (S5 x P1) — within ALARP region; further reduction is documented as not practicable

Frequently Asked Questions

Is ISO 14971 certification possible? No. ISO 14971 is a process standard — you apply it to your risk management activities. There is no "ISO 14971 certification" analogous to ISO 13485 certification. Compliance with ISO 14971 is assessed as part of your quality system audits (by Notified Bodies, FDA investigators, or other auditors), not through a standalone certification process.

Can I use a different risk management approach instead of ISO 14971? In theory, a manufacturer could develop a proprietary risk management process. In practice, ISO 14971 is universally expected. EU MDR harmonizes it. FDA recognizes it. ISO 13485 references it. Notified Bodies audit against it. Using a different framework would require demonstrating equivalent rigor, which is more work than simply applying ISO 14971.

How often should the risk management file be reviewed? There is no fixed interval prescribed by the standard. Reviews should be triggered by: design changes, new complaint or adverse event data, CAPA actions, new regulatory requirements or standards, new clinical data or literature, changes in intended use, and periodic scheduled reviews (many companies do annual reviews for commercial devices). At minimum, the risk management file should be reviewed whenever information is received that could change risk estimates.

Who should sign off on risk acceptability? The risk management plan must define who has the authority to make risk acceptability decisions. This should be someone with appropriate technical and clinical knowledge and the organizational authority to accept risk on behalf of the manufacturer. In practice, this is often the VP of Quality, VP of Engineering, or a designated risk management authority. For high-severity residual risks, many organizations require multi-disciplinary sign-off.

What is the relationship between ISO 14971 and IEC 60601-1? IEC 60601-1 (Medical electrical equipment — general requirements for basic safety and essential performance) references ISO 14971 extensively. Many IEC 60601-1 requirements are conditional — they apply "unless the risk management process determines otherwise." This means your ISO 14971 risk management process provides the justification for design decisions related to electrical safety.

Does ISO 14971 apply to software-only medical devices? Yes. Software as a Medical Device (SaMD) is a medical device. ISO 14971 applies fully. The hazard categories differ — software does not have mechanical or thermal hazards, but it has information hazards, algorithm errors, data integrity risks, and cybersecurity risks. IEC 62304 (software lifecycle) requires the software safety classification to be based on ISO 14971 risk analysis results.

What if we cannot reduce a risk to an acceptable level? If residual risk remains above the acceptability threshold after all practicable risk controls have been implemented, you must conduct a risk-benefit analysis. If the clinical benefit outweighs the residual risk, the risk may be accepted (with documentation). If the benefit does not outweigh the risk, the device should be redesigned or not released. There is no option to simply accept unacceptable risk without a documented, evidence-based benefit-risk justification.

Can I use only FMEA to satisfy ISO 14971 requirements? No — and this is a common misconception. Using FMEA alone is insufficient to meet the full requirements of ISO 14971. FMEA is a risk analysis technique (one step in the process), but ISO 14971 requires a complete risk management process that includes risk management planning, hazard identification (which should use multiple techniques, not just FMEA), risk estimation, risk evaluation against pre-defined acceptability criteria, risk control with priority-ordered measures, risk control verification, residual risk evaluation, overall residual risk evaluation, risk-benefit analysis (when applicable), a risk management report, and post-production monitoring. Many auditors now explicitly expect manufacturers to use at least two risk management techniques. A PHA during the concept phase followed by FMEA during design is a minimum reasonable combination for most devices.

How does ISO 14971 apply to combination products (drug-device)? Combination products present unique challenges because they combine hazard categories from both the device and the pharmaceutical or biologic component. ISO 14971 applies to the device portion, and separate pharmaceutical risk management frameworks apply to the drug component. However, the critical addition is that you must also analyze combination-specific hazards — risks that arise specifically from the interaction of the device and drug components. Examples include: incorrect drug delivery rate due to device malfunction, drug degradation caused by incompatibility with device materials, and altered drug pharmacokinetics due to delivery mechanism characteristics. The risk management file should contain separate analyses for device-only hazards, drug-only hazards, and combination-specific hazards, with an integrated overall residual risk evaluation covering all three.

What is the "disclosure of residual risk" requirement in ISO 14971:2019? The 2019 edition added a requirement (Clause 8) for manufacturers to disclose residual risks to users and patients. This is distinct from "information for safety" (a risk control measure). Disclosure of residual risk is descriptive — it informs the user about risks inherent to using the device so they can make an informed decision. Information for safety is instructive — it tells the user what to do or avoid to prevent harm. For example, for an MRI-compatible implant: the disclosure of residual risk might state "There is a small residual risk of localized tissue heating during MRI scanning." The information for safety would state "Do not exceed 3.0 Tesla field strength. Limit SAR to 2.0 W/kg." Both must be present, and they serve different purposes.

How should risk management activities be timed relative to design controls? Risk management should be initiated at the earliest stage of product development — during the concept and feasibility phase, before design inputs are finalized. A common mistake is treating risk management as a task performed after the design is complete, to generate documentation for the design history file. Instead:

• Concept phase: Preliminary Hazard Analysis (PHA) to identify high-level hazards and inform early design decisions
• Design input phase: Risk analysis results feed into design input requirements — risk controls become design requirements
• Design output phase: Evaluate design outputs against identified hazards
• Design review milestones: Risk management review is a standing agenda item at every design review
• Design verification: Risk control verification is part of design verification
• Design validation: Clinical validation confirms risk controls are effective in the intended use environment
• Design transfer: Process FMEA confirms manufacturing risks are controlled
• Post-market: Ongoing surveillance and risk file updates

Summary

ISO 14971 is the backbone of medical device safety. It provides a structured, lifecycle-spanning process for identifying what could go wrong, estimating how bad and how likely it would be, deciding what to do about it, verifying that what you did works, and continuously monitoring for new information that could change the picture.

The standard is not complicated in concept. The challenge is in the execution — doing it thoroughly, keeping it current, and integrating it with every other aspect of device development and commercial life. The organizations that do risk management well are not the ones with the most elaborate spreadsheets. They are the ones where risk thinking is embedded in daily decisions: in design reviews where engineers challenge each other's assumptions, in CAPA investigations that trace back to the risk file, in post-market surveillance that generates actionable signals rather than filing cabinets of unused data.

Whether you are implementing ISO 14971 for the first time or refining a process that has been in place for years, the principles are the same: be systematic, be thorough, be honest about what you do not know, and never treat risk management as a documentation exercise. Patients depend on it.