What is the difference between a hazard, a hazardous situation, and harm in ISO 14971 terminology?

ISO 14971 uses these terms with precise, distinct meanings that engineers must apply consistently. A hazard is a potential source of harm — for example, an exposed sharp edge, or a software defect that could cause an incorrect dose calculation. A hazardous situation is a circumstance in which people, property, or the environment are exposed to one or more hazards — for example, a clinician handling the device with the sharp edge exposed, or a patient about to receive a dose calculated by the defective software. Harm is the actual physical injury or damage to health that results — a laceration, or an overdose event. Risk is formally defined as the combination of the probability of harm occurring and the severity of that harm — meaning the same hazard can represent very different risk levels depending on how likely it is to actually progress through a hazardous situation into realized harm, and how severe that harm would be if it occurred.

What is the risk control hierarchy and why does it matter which order controls are applied?

ISO 14971 specifies a strict priority order for risk control measures, applied in this sequence: first, inherent safety by design (eliminating the hazard or reducing its probability through the design itself — for example, a mechanical interlock that makes an incorrect assembly physically impossible); second, protective measures in the device itself or in the manufacturing process (such as an alarm, a fail-safe mechanism, or a hardware limit); and only third, and least preferred, information for safety (labeling, instructions for use, training) that relies on the user reading and correctly following a warning. This hierarchy matters because relying primarily on a warning label to control a hazard that could have been designed out entirely is considered weak risk control — users can and do fail to read, misunderstand, or ignore warnings, so ISO 14971 pushes design teams to exhaust design-based and protective controls before falling back on labeling as the primary risk control measure.

Can a device with high individual risks still be approved if the overall benefit-risk ratio is favorable?

Yes — ISO 14971 explicitly requires an overall residual risk acceptability judgment that weighs the totality of remaining risk (after all practicable risk controls have been applied) against the expected clinical benefit of the device, not just a requirement that every individual risk fall below some universal numeric threshold. A device with a serious individual risk (for example, a small probability of a severe complication from an invasive cardiac procedure) can still have a favorable overall benefit-risk profile if the device treats a life-threatening condition with no equivalently effective lower-risk alternative — which is exactly why a Class III device like an implantable defibrillator can be approved despite carrying non-trivial procedural and device-related risks, because the alternative (no treatment, or a less effective treatment) carries a demonstrably worse expected outcome for the target patient population.

Engineering·9 min read·August 7, 2026

⚠️ Medical Device Risk Management: The ISO 14971 Process

A practical guide to ISO 14971 medical device risk management — hazard identification, risk estimation and evaluation, risk control hierarchy, and how the risk management file connects to design controls and post-market surveillance.

By EngineersUniverse Editorial Team

Engineering Editorial & Technical Review Team

Published August 7, 2026

Risk Management Is a Continuous Process, Not a One-Time Document

ISO 14971, "Application of risk management to medical devices," establishes the internationally recognized process for identifying hazards, estimating and evaluating the associated risks, controlling those risks, and monitoring the effectiveness of that control — across the entire device lifecycle, from initial concept through design, manufacturing, and post-market use. A critical framing that ISO 14971 insists on, and that new device engineers sometimes underestimate, is that risk management is not a document produced once near the end of development to satisfy a regulatory submission checklist — it is a living process that starts at the earliest design concept and continues through post-market surveillance, actively feeding new field information back into the risk analysis for the life of the product.

The Core Risk Management Process

Risk Analysis: Hazard Identification and Risk Estimation

The process begins with systematically identifying hazards associated with the device — this typically draws on techniques like Failure Modes and Effects Analysis (FMEA), Fault Tree Analysis (FTA), or a structured hazard identification checklist informed by similar predicate devices, published adverse event data, and clinical/engineering expertise. For each identified hazard, the team traces plausible sequences of events leading from the hazard through a hazardous situation to potential harm, then estimates both the probability of that harm occurring and its severity if it does. Probability estimation for medical devices often has to rely on engineering judgment, similar-device field history, or component reliability data rather than the extensive population-level failure statistics available in, say, automotive or aerospace risk analysis, which is one of the genuine methodological challenges of medical device risk analysis — the estimates have to be defensible and documented even when precise statistical data doesn't exist.

Risk Evaluation

Once probability and severity are estimated (typically using a defined risk matrix specific to the device's risk management plan, with severity and probability each divided into several qualitative or semi-quantitative levels), the resulting risk is evaluated against pre-established acceptability criteria. Risks falling in an unacceptable zone must be reduced through risk control measures before the device can proceed; risks already in an acceptable zone are documented but still tracked, since post-market data can later revise the risk estimate.

Risk Control

For any risk requiring reduction, ISO 14971 mandates applying risk control measures in the strict priority hierarchy described in this article's FAQ: inherent safety by design first, protective measures second, and information for safety (labeling/warnings/training) only as a last resort or supplement. After implementing a risk control measure, the team must re-evaluate the resulting residual risk and verify the control measure did not introduce new hazards of its own — a genuinely common and easy-to-overlook failure mode where a fix for one risk inadvertently creates another.

Overall Residual Risk Evaluation and Benefit-Risk Analysis

After all individual risk controls are applied and residual risks re-evaluated, ISO 14971 requires an assessment of the overall residual risk — the combined remaining risk across all identified hazards taken together, not just each hazard considered in isolation, since risks can interact or compound. Where overall residual risk is not judged acceptable on its own, the standard requires a formal benefit-risk analysis weighing that residual risk against the device's expected clinical benefit, as discussed in this article's FAQ.

The Risk Management File

All risk management activities — the risk management plan, hazard analysis, risk evaluation records, risk control verification, and the risk management report summarizing overall residual risk acceptability — are compiled into the risk management file, a required deliverable reviewed during both internal design reviews and external regulatory submissions or audits. The risk management file is not a standalone document disconnected from the rest of the QMS — it is deeply cross-referenced with the Design History File's design inputs and outputs (since risk controls often become formal design requirements) and with post-market surveillance data (since real-world complaint and adverse event data must be actively compared against the original risk analysis's probability and severity estimates, and the risk management file updated when field data reveals the original estimates were inaccurate).

Risk Management as a Design Input, Not an Audit

The single most important practical lesson for an engineer new to medical device risk management is that ISO 14971 works best — and is intended to work — when integrated directly into the design process from day one, not performed retrospectively against an already-finalized design. A hazard identified early, while the design is still flexible, can often be eliminated through inherently safer design choices at low cost. The same hazard identified late, after tooling, manufacturing processes, and supplier relationships are locked in, frequently can only be addressed through a weaker protective measure or a labeling warning — precisely the least-preferred rung of the risk control hierarchy — simply because the design has lost the flexibility to be changed. Risk management done well is therefore a design tool engineers actively use throughout development, not a compliance audit performed on a finished product.

Topics covered

ISO 14971medical device risk managementrisk management filehazard analysis medical deviceFMEA medical devicerisk control hierarchyresidual risk acceptabilitybenefit-risk analysis medical device