ISO 14971: ISO 14971 – Tutorial (about 60 minutes)

ISO 14971 is the international standard that tells medical device manufacturers how to manage the safety risks of their products, from the first concept sketch until the last device is withdrawn from use. Regulators in Europe, the United States and most other markets expect manufacturers to follow it, so engineers, quality and regulatory specialists, clinicians and product managers all meet it sooner or later. After this tutorial you will be able to explain the standard's vocabulary, walk through its risk management process, recognise what goes into a risk management file and judge whether a team is applying the standard in substance rather than on paper.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO 14971:2019, Medical devices – Application of risk management to medical devices, the third edition, published by the International Organization for Standardization (ISO) in December 2019. It was prepared by ISO technical committee TC 210 (quality management and corresponding general aspects for products with a health purpose, including medical devices) in a joint working group with IEC subcommittee SC 62A, and it replaced the 2007 second edition. ISO's catalogue lists the 2019 edition as reviewed and confirmed in 2025, which means it remains current and no newer edition has been published. In Europe it is adopted as EN ISO 14971:2019 with Amendment A11:2021, which adds informative annexes relating the standard to the EU medical device regulations; the requirements themselves are unchanged. The US Food and Drug Administration (FDA) recognised the 2019 edition as a consensus standard at the end of 2019. Its companion guidance document is the technical report ISO/TR 24971:2020; in July 2026 ISO marked that report as to be revised, with a successor (ISO/AWI TS 24971-1) under development, but the 2020 report remains the published guidance. Verified 2026-10-29 against the ISO catalogue pages for ISO 14971:2019 (stage 90.93, confirmed 2025) and ISO/TR 24971:2020 (stage 90.92), the ISO/TC 210 committee news page and published regulatory commentary.

Who it is for: design and development engineers (hardware, software, mechanical, biomedical), quality and regulatory affairs specialists, clinical and human factors specialists, product and project managers, and suppliers who build components or software that end up inside medical devices. It is also useful for people moving into medical technology from automotive, aerospace or industrial safety, where risk thinking is familiar but the vocabulary and regulatory context differ.

Prerequisites: none. A general idea of how a product is designed, verified and manufactured will help, and every term the standard uses is explained when it first appears.

Learning objectives. After this tutorial you will be able to:

Explain why ISO 14971 exists, what it covers and what it deliberately leaves to the manufacturer.
Use the core vocabulary correctly, especially the difference between a hazard, a hazardous situation and harm.
Describe the structure of the standard and the flow of its risk management process from planning to post-production.
Apply the priority order for risk control and decide when a benefit-risk analysis is appropriate.
Recognise what auditors, notified bodies and regulators look for in a risk management file.
Follow a realistic device through the whole process in a worked example.
Relate ISO 14971 to ISO 13485, ISO/TR 24971, IEC 62366-1, IEC 62304, IEC 60601-1 and ISO 31000.

Lesson 1 – Origins, purpose and scope

Why a risk management standard for medical devices?

Every medical device carries some risk. A scalpel cuts, an X-ray system emits ionising radiation, an infusion pump can deliver too much or too little drug, and a diagnostic test can give a wrong result that leads to the wrong treatment. Society accepts these risks because devices also bring large benefits: they diagnose disease, keep people alive and relieve suffering. The practical question is therefore never "is this device risk-free?" but "has the manufacturer understood the risks, reduced them sensibly and made sure the remaining risk is justified by the benefit?" ISO 14971 gives manufacturers a common, structured way to answer that question and to show the answer to others.

Before international harmonisation, each country and each company had its own approach to device safety. Some relied on checklists of known failures, others on engineering judgement, others on formal techniques borrowed from aerospace or the process industries. The first international standard on the topic appeared as a first part in 1998 and was replaced by the complete ISO 14971 in 2000. The second edition of 2007 became the global reference for more than a decade. The third edition of 2019 kept the same core approach but clarified the requirements, defined clinical benefit, strengthened the link to production and post-production information, and mentioned explicitly that hazards related to data and systems security are in scope.

What the standard does

ISO 14971 is a process standard. It does not say how safe a particular device must be, and it does not list design rules for pumps, implants or software. Instead it requires the manufacturer to establish a documented process that identifies hazards, estimates and evaluates the associated risks, controls those risks, monitors whether the controls work, and keeps learning once the device is on the market. The manufacturer defines its own criteria for deciding whether a risk is acceptable, based on a policy set by top management and informed by applicable regulations, relevant standards and the generally acknowledged state of the art.

Scope and boundaries

The standard applies to all medical devices, including software that is itself a medical device and in vitro diagnostic (IVD) medical devices such as laboratory tests and home test kits. It covers all phases of the life cycle: concept, design, verification and validation, manufacturing, distribution, installation, use, servicing and final decommissioning or disposal. It addresses risks to patients, to users such as nurses and lay people, to other people nearby, and also damage to property and the environment.

Three boundaries are worth remembering. First, the standard does not apply to decisions a clinician makes about whether to use a device in a particular procedure for a particular patient; that clinical judgement is outside its scope. Second, it does not set acceptable risk levels; the manufacturer does. Third, it does not require a full quality management system, although in practice almost every manufacturer runs the process inside a quality management system such as one based on ISO 13485.

Lesson 2 – Key concepts and vocabulary

ISO 14971 uses a precise vocabulary, and most confusion in real projects comes from mixing up a few of its terms. The definitions below are paraphrased in plain language; the standard's own wording is more formal.

Harm – injury or damage to the health of people, or damage to property or the environment. Harm is what we ultimately want to avoid.
Hazard – a potential source of harm, such as electrical energy, a sharp edge, a toxic material, a wrong drug dose or a misleading result. A hazard on its own does not hurt anyone.
Hazardous situation – a circumstance in which people, property or the environment are exposed to one or more hazards. A live conductor inside a sealed enclosure is a hazard; a patient touching that conductor through a cracked enclosure is a hazardous situation.
Risk – the combination of how likely harm is to occur and how severe that harm would be. Risk always refers to harm, never to a hazard alone.
Severity – a measure of how bad the possible consequences of a hazard are, from negligible discomfort up to death.
Intended use – the use for which the manufacturer designed the device, as described in its specifications, instructions and other information. It includes the medical purpose, the patient population, the users and the use environment.
Reasonably foreseeable misuse – use that the manufacturer did not intend but that can be expected from readily predictable human behaviour, for example a home user skipping a cleaning step because it is tedious.
Risk analysis – the systematic use of available information to identify hazards and estimate risks.
Risk evaluation – comparing the estimated risk with the manufacturer's risk acceptability criteria to decide whether the risk is acceptable.
Risk assessment – risk analysis and risk evaluation taken together.
Risk control – deciding on and implementing measures that reduce risks to, or keep them within, specified levels. A single measure is called a risk control measure.
Residual risk – the risk that remains after risk control measures have been implemented.
Benefit – the positive impact or desirable outcome of using the device on an individual's health, or a positive effect on patient management or public health. The 2019 edition added this definition.
State of the art – what science, technology and accumulated experience make technically achievable for comparable products and processes at a particular point in time. It means what is generally accepted as good practice, not necessarily the most advanced technology available.
Risk management file – the set of records and other documents produced by risk management. It need not be one physical document; it can point to records held elsewhere.
Safety – freedom from unacceptable risk. Note that the definition does not promise freedom from all risk.
Top management – the person or group who direct and control the manufacturer at the highest level and who carry specific responsibilities in the standard.

From hazard to harm

The most important mental model in ISO 14971 is the chain that leads from a hazard to harm. A hazard becomes dangerous only when a sequence of events creates a hazardous situation. The hazardous situation then results in harm with some probability. Annex C of the standard and the guidance in ISO/TR 24971 describe this chain and split the probability of harm into two parts: the probability that the hazardous situation occurs (often called P1) and the probability that the hazardous situation leads to harm (P2). Splitting it this way stops teams from assuming every hazardous situation causes harm, or from ignoring rare situations that are almost always fatal.

Figure 1 – A hazard leads to harm only through a sequence of events and a hazardous situation; risk combines the severity and the probability of that harm.

Consider an electrically powered patient bed. The hazard is mechanical energy in the moving frame. One sequence of events is: a child plays with the hand control while a patient's arm hangs through the side rail. The hazardous situation is the patient's arm being in the path of the moving frame. The harm is a crushed arm. Each element can be attacked by risk control: designing out the gap (removing the hazardous situation), adding a lockout on the hand control (breaking the sequence of events), or limiting force (reducing severity).

Risk is about harm, acceptability is about criteria

Two further points deserve emphasis. Risk is estimated for harm arising from hazardous situations, so a list of hazards with risk scores attached directly to them is usually a sign that the analysis has skipped a step. And whether a risk is acceptable is not an intrinsic property of the risk; it is the result of comparing the estimate with criteria the manufacturer defined in advance.

Lesson 3 – Structure of the standard

The 2019 edition is compact. Its normative text runs to ten clauses, followed by three informative annexes. Most of the detailed guidance that the 2007 edition carried in its annexes was moved into the separate technical report ISO/TR 24971:2020, so the standard itself focuses on what must be done and the report explains how it can be done.

The clauses

Clause 1 – Scope: what the standard covers, including IVDs and all life cycle stages, and the clinical decision exclusion described in Lesson 1.
Clause 2 – Normative references: there are none, so the standard can be applied on its own.
Clause 3 – Terms and definitions: the vocabulary from Lesson 2.
Clause 4 – General requirements for the risk management system: the risk management process itself, management responsibilities, competence of personnel, the risk management plan and the risk management file.
Clause 5 – Risk analysis: the analysis process, intended use and reasonably foreseeable misuse, characteristics related to safety, identification of hazards and hazardous situations, and risk estimation.
Clause 6 – Risk evaluation: comparing each estimated risk with the acceptability criteria in the plan.
Clause 7 – Risk control: option analysis, implementation and verification of measures, residual risk evaluation, benefit-risk analysis, risks arising from risk control measures and completeness of risk control.
Clause 8 – Evaluation of overall residual risk: looking at all residual risks together, against the benefits, using a method defined in the plan.
Clause 9 – Risk management review: a review before commercial release that the plan has been carried out, the overall residual risk is acceptable and methods for collecting post-market information are in place; the result is recorded in a risk management report.
Clause 10 – Production and post-production activities: actively collecting and reviewing information once the device is made and used, and acting on it.

The informative annexes are Annex A, which explains the rationale for the requirements; Annex B, which gives an overview of the risk management process and shows how the clauses of the 2019 edition correspond to the 2007 edition; and Annex C, which explains fundamental risk concepts, including the chain from hazard to harm and examples of hazards and sequences of events.

Figure 2 – The clauses of ISO 14971 form a closed loop in which production and post-production information feeds back into risk analysis.

Reading the structure as a loop

Figure 2 shows why the standard is often drawn as a cycle rather than a line. The pre-market part of the process ends with the risk management review, but the process itself never ends while the device is in use. Information from production, complaints, service, the literature and similar devices can reveal a hazard nobody thought of or show that a risk is more likely than estimated. When that happens the manufacturer goes back to risk analysis, re-evaluates and, if needed, adds controls. The risk management file is a living record, not a design history document that is frozen at launch.

Requirements that apply throughout

Clause 4 sets the frame for everything else. Top management must define a policy for establishing criteria for risk acceptability, provide adequate resources, assign competent people and review the suitability of the risk management process at planned intervals. Competence matters: the people doing risk management need knowledge of the device, its clinical use and the risk management techniques, and the manufacturer must keep records showing it. Each device or family needs a risk management plan, and the risk management file must allow anyone to trace each identified hazard through its analysis, evaluation, control measures, verification and residual risk evaluation.

The role of ISO/TR 24971

ISO/TR 24971:2020 is a technical report, which means it contains guidance rather than requirements. It covers acceptability criteria, risk analysis techniques, security-related hazards, IVD considerations, disclosure of residual risk and questions that help identify safety characteristics. Auditors often treat it as the reference for reasonable practice. In 2026 ISO decided to revise the report, and a successor technical specification is in development; until it is published, the 2020 report is the guidance to use.

Lesson 4 – How it works in practice

This lesson follows the process in the order a project team usually experiences it. In a real project many steps overlap and repeat; the order is logical, not strictly chronological.

Step 1: plan the work

The risk management plan is written early, usually during design planning. It states the scope (which device, which variants and which life cycle phases are covered), who is responsible for what, how risk management activities will be reviewed, the criteria for risk acceptability, the method and criteria for evaluating overall residual risk, how risk control measures will be verified for implementation and effectiveness, and how production and post-production information will be collected and reviewed. The plan can change as the project learns, but changes must be recorded.

The acceptability criteria deserve care. Many manufacturers use a matrix with severity categories along one axis and probability categories along the other, with each cell marked acceptable or not acceptable. Others use qualitative descriptions or numeric targets. The standard does not prescribe a format; it requires that the criteria follow top management's policy and that they take account of regulations, relevant standards, the state of the art and known stakeholder concerns. A matrix is only as good as the definitions behind it, so the severity and probability categories must be described clearly enough that two engineers would classify the same harm the same way.

Step 2: analyse the risks

Risk analysis starts by documenting the intended use and reasonably foreseeable misuse. Then the team identifies characteristics of the device that could affect safety, such as whether it delivers energy, contacts the body, uses software to make decisions, is used at home by lay people, or must be sterile. From those characteristics the team identifies known and foreseeable hazards and the sequences of events that could turn them into hazardous situations, in both normal use and fault conditions.

No single technique finds every hazard, so mature teams combine several. A preliminary hazard analysis gives a broad early view. Failure mode and effects analysis works bottom-up from component or process failures. Fault tree analysis works top-down from a harmful outcome to its contributing causes. Hazard and operability studies challenge each function with guide words such as "more", "less" or "reverse". Use-related risk analysis, linked to usability engineering under IEC 62366-1, examines tasks users perform and how they could go wrong. ISO/TR 24971 and IEC 31010 describe these techniques. The standard cares about the result, a complete and traceable identification of hazardous situations, not about which technique produced it.

For each hazardous situation, the team then estimates the risk by assigning a severity and a probability to the resulting harm. Data can come from published standards, clinical literature, complaint records for similar devices, reliability predictions, test results and expert judgement. When the probability of harm genuinely cannot be estimated, which is common for software failures, the team lists the possible consequences and bases its decisions on severity, typically assuming that the failure will occur and controlling it accordingly.

Step 3: evaluate the risks

Each estimated risk is compared with the acceptability criteria from the plan. A risk that meets the criteria needs no further reduction under the standard, although regulations in some markets expect manufacturers to keep reducing risk where reasonable, as Lesson 5 explains. A risk that does not meet the criteria must go to risk control.

Step 4: control the risks

Risk control is the heart of the process. The standard requires the manufacturer to consider options in a fixed priority order, because some kinds of control are inherently more dependable than others.

Figure 3 – Risk control options are considered in priority order, verified, and followed by residual risk evaluation and, only where needed, a benefit-risk analysis.

Inherently safe design and manufacture removes the hazard or makes the hazardous situation impossible, for example by using a low voltage, choosing a connector that cannot be attached to the wrong port, or making a drug reservoir too small to hold a lethal dose. Protective measures in the device itself or in the manufacturing process detect or contain the problem: alarms, interlocks, pressure limits, watchdog timers, automatic shut-off, 100 % inspection of a critical dimension. Information for safety, such as warnings in the instructions, labels on the device and user training, comes last because it depends on people reading, understanding and remembering it under real conditions.

The priority order does not forbid using several kinds of control together, and in practice important risks usually have a design measure, a protective measure and a warning. What the order forbids is jumping straight to a warning when a design change was practicable. A notified body auditor who sees a serious risk controlled only by a sentence in the instructions will ask why nothing better was possible.

Every risk control measure must be verified twice: that it was actually implemented (the alarm is in the released software) and that it is effective (the alarm sounds within the required time and users notice it). Effectiveness of information for safety is often verified through usability testing with representative users.

After controls are in place, the residual risk is evaluated against the same criteria. If it is still not acceptable and no further control is practicable, the manufacturer may perform a benefit-risk analysis: gathering and reviewing data and literature to decide whether the medical benefits of the intended use outweigh that residual risk. If they do not, the risk remains unacceptable and the device design or its intended use must change. The team must also check whether the controls themselves introduce new hazards or affect other risks; a battery added to keep an alarm working, for example, brings its own thermal and chemical hazards. Finally, the team confirms that controls have been considered for every identified hazardous situation.

Step 5: look at the whole picture

Individual risks can each be acceptable while the device as a whole is not, for example when many small risks add up or when several risks affect the same vulnerable patient group. The evaluation of overall residual risk looks at all residual risks together, in relation to the benefits, using the method set out in the plan. Typical methods include a structured review by a cross-functional panel with clinical input, comparison with similar devices on the market, and review of the combined effect of warnings on users. If the overall residual risk is judged acceptable, the manufacturer informs users about significant residual risks in the accompanying documentation. This disclosure is different from information for safety used as a risk control: it tells users what risk remains so they can make informed decisions.

Step 6: review before release

Before commercial distribution, the people responsible review the execution of the plan. The review confirms that the plan was carried out appropriately, that the overall residual risk is acceptable and that appropriate methods are in place to collect and review production and post-production information. The result is documented as the risk management report, which becomes part of the risk management file.

Step 7: keep learning after release

The manufacturer must establish a system to actively collect and review information about the device in production and in use. Sources include production and process monitoring, complaints and service records, adverse event reports, the literature, publicly available information about similar devices, and changes in the generally acknowledged state of the art. The review asks whether previously unrecognised hazards or hazardous situations have appeared, whether an estimated risk or the overall residual risk is no longer acceptable, and whether the state of the art has moved. If so, the team updates the risk management file and feeds the issue into quality system processes such as corrective and preventive action, design change or field safety action.

Roles and artefacts

ISO 14971 does not prescribe an organisation chart, but certain roles appear in almost every company: top management, who own the policy and resources; a risk management lead who keeps the file coherent; design engineers who own hazards and controls in their area; clinical and human factors experts who judge severity and use-related risks; quality engineers who link the file to verification and production controls; and post-market surveillance staff who feed field data back. The table summarises the main artefacts.

Artefact	Purpose	Typical owner
Risk management policy	Sets how acceptability criteria are established across the company	Top management
Risk management plan	Scope, responsibilities, criteria, verification and post-production approach for one device	Risk management lead
Hazard analysis and risk tables	Hazards, sequences of events, hazardous situations, estimates and controls	Cross-functional team
Verification records	Evidence that controls are implemented and effective	Design and test engineers
Benefit-risk and overall residual risk evaluation	Justification that remaining risk is outweighed by benefit	Clinical and risk leads
Risk management report	Outcome of the review before release	Risk management lead, approved by management
Post-production review records	Evidence that field information is collected, reviewed and acted on	Post-market surveillance

Lesson 5 – Assessment, certification and compliance

There is no ISO 14971 certificate in the usual sense

ISO 14971 is not a management system standard, so there is no accredited certification scheme for it comparable to the certificates issued for ISO 13485 or ISO 9001. Training providers may issue course certificates to individuals, but those say nothing about a company's compliance. Conformity with ISO 14971 is demonstrated through evidence: the risk management file, its links to design and production records, and the way the process runs day to day. That evidence is examined in several settings.

Quality management system audits

ISO 13485 requires a documented approach to risk management in product realisation and refers to ISO 14971 for guidance. Certification bodies auditing an ISO 13485 quality management system, and auditing organisations under the Medical Device Single Audit Program (MDSAP), therefore look at how the risk management process is defined, whether top management has set a policy, whether personnel are competent, and whether risk management actually drives design, purchasing, production and complaint handling. A typical audit technique is to pick a hazard and follow it from the risk table through to the design requirement, the verification test, the label and the complaint trend.

European Union

Under the EU Medical Device Regulation (MDR, Regulation (EU) 2017/745) and the In Vitro Diagnostic Medical Device Regulation (IVDR, Regulation (EU) 2017/746), manufacturers must establish, implement, document and maintain a risk management system, and the general safety and performance requirements in Annex I of each regulation describe what it must achieve. The European version EN ISO 14971:2019 with Amendment A11:2021 is cited as a harmonised standard, which means that conformity with it gives a presumption of conformity with the regulatory requirements it covers. The A11 amendment added Annexes ZA and ZB that map the standard's clauses to the relevant requirements of the MDR and the IVDR and explain where the regulations go further. One area that receives attention is the regulations' expectation that risks are reduced as far as possible without adversely affecting the benefit-risk ratio, which is stricter than simply meeting acceptability criteria; EU manufacturers usually reflect this in their policy and criteria. Notified bodies review the risk management documentation as part of the technical documentation assessment for most device classes.

United States

The FDA lists ISO 14971:2019 in its database of recognised consensus standards. A manufacturer can declare conformity to it in a premarket submission, which reduces the amount of process evidence the reviewer needs to examine, although device-specific risk information is still required. When FDA recognised the 2019 edition, it set a transition period after which declarations of conformity to the 2007 edition were no longer accepted. The Quality Management System Regulation (QMSR) in 21 CFR Part 820, which took effect in February 2026, incorporates ISO 13485:2016 by reference, so risk management expectations now reach US manufacturers through the quality system requirements as well as through submissions and inspections.

What assessors look for

Whichever body is assessing, the same questions recur. Is there a policy and are the acceptability criteria justified? Are intended use, users and use environments described specifically enough? Are hazardous situations identified for normal use, misuse and fault conditions, including use-related and security-related ones? Is the priority order of risk control visible in the decisions? Is every control verified for implementation and effectiveness? Is the overall residual risk evaluated with a defined method and are significant residual risks disclosed? Is the file kept up to date with post-market data? A tidy file that answers these questions with traceable evidence is the closest thing to "compliance" that ISO 14971 offers.

Lesson 6 – Worked example

This example follows a fictional company, Kestrel Medical, as it applies ISO 14971 to a new portable syringe driver. All numbers and classifications are illustrative and chosen to show the reasoning, not to recommend values for real devices.

The device and its context

The KS-20 is a battery-powered syringe driver that pushes the plunger of a standard syringe to deliver medication subcutaneously over many hours. Its intended use is continuous delivery of prescribed medicines, such as pain relief and anti-nausea drugs, to adult patients receiving palliative care at home or in hospices. Community nurses set it up and change syringes; patients and family members live with it and may silence alarms. A companion tablet app used by nurses connects over Bluetooth to view the infusion history and change the rate within limits set by the prescriber. Kestrel already operates an ISO 13485 quality management system and has a company risk management policy approved by its top management.

Step 1: plan

The risk management lead writes the plan. It covers the pump hardware, firmware, the nurse app, the disposable extension set bought from a supplier, manufacturing at Kestrel's own site, servicing and disposal. It assigns hazard ownership to the hardware, firmware, app and human factors leads, defines design review points at which the risk tables are reviewed, and adopts the company's five-by-five severity and probability matrix. Severity ranges from negligible discomfort to death; probability categories are defined per hour of use so that engineers and clinicians interpret them the same way. The plan specifies that overall residual risk will be evaluated by a panel including a palliative care physician, comparing the KS-20 with established syringe drivers on the market, and that complaint and service data will be reviewed quarterly after launch.

Step 2: analyse

The team documents intended use and foreseeable misuse. Misuse scenarios include a relative pressing buttons to "help" a patient in pain, a nurse loading a syringe brand the device was not designed for, and the pump being placed under bedclothes where an alarm is muffled. Using the safety characteristics questions from ISO/TR 24971, the team notes that the device delivers energy to a drug, contains software that controls dosing, is used by lay people at home, runs on a rechargeable battery and communicates wirelessly.

A preliminary hazard analysis, followed by a firmware FMEA, a fault tree for "overdose delivered" and a use-related risk analysis of nurse and family tasks, produces a set of hazardous situations. Four of them illustrate the reasoning:

Over-infusion of an opioid because the pump misidentifies the syringe size and calculates the wrong plunger speed. Severity: critical, potentially fatal respiratory depression.
Under-infusion because the line is blocked and the pump keeps running without delivering drug. Severity: serious, uncontrolled pain and distress for a dying patient.
Unauthorised rate change by someone exploiting the wireless link. Severity: critical.
Skin injury from a battery overheating while the pump rests against the patient. Severity: moderate burn.

For the firmware-related sequence in item 1, the team cannot estimate a credible probability of a software fault, so, as the standard requires when probability cannot be estimated, it lists the possible consequences and bases its decisions on their severity, treating the failure as if it will occur. For item 2, complaint data on comparable pumps and bench testing give a reasonable estimate that occlusions are frequent, while harm depends on how long they go unnoticed.

Step 3: evaluate

Against the matrix, items 1, 2 and 3 fall in the not-acceptable region. Item 4 is borderline: overheating is improbable with the chosen cell chemistry, but the pump is worn against frail skin for long periods, so the team decides to control it rather than argue it into the acceptable region.

Step 4: control

The team works through the priority order for each item.

Over-infusion: inherently safe design comes first. The barrel clamp is redesigned so that it only accepts syringes in a narrow range of diameters, and the plunger drive has a mechanical maximum speed. As protective measures, two independent sensors measure syringe diameter and plunger travel, and firmware stops the infusion if they disagree. The nurse must confirm the detected syringe brand and size on screen. The instructions list compatible syringes, and training covers the confirmation step.
Under-infusion: a pressure sensor triggers an occlusion alarm. Because a muffled alarm was identified as foreseeable, the pump also sends an alert to the nurse app at the next connection and shows a coloured status light visible from across the room. The instructions explain where to place the pump.
Unauthorised rate change: design measures include pairing only with registered nurse tablets, encrypted and authenticated communication, and firmware that rejects any rate outside the limits set at prescription. Rate changes from the app are logged and shown on the pump display.
Battery overheating: the cell is chosen with built-in protection, the enclosure separates the cell from the skin-contact surface, and firmware cuts charging above a temperature threshold.

Verification follows. Bench tests show the clamp rejects incompatible syringes; fault-injection tests show that a simulated sensor disagreement stops delivery within the specified time; occlusion alarm timing is measured at the lowest flow rate; penetration testing of the wireless interface finds no way to change the rate without authentication; thermal testing confirms surface temperatures under fault conditions. A summative usability test with community nurses shows that all participants correctly confirm the syringe size and respond to the occlusion alert.

The team then looks for risks introduced by the controls. The authentication step could delay an urgent rate change if a nurse's tablet fails. The team adds an on-pump procedure, protected by a nurse access code, so care is never blocked by the app. The new procedure is itself analysed for misuse by family members. A completeness check confirms that every hazardous situation in the tables has a recorded decision.

Step 5: overall residual risk

All individual residual risks are now within the acceptable region except one: a small residual risk of under-infusion going unnoticed overnight when no app connection exists. Further control is judged impracticable without adding a mobile network connection that would bring new hazards and exclude homes without coverage. The clinical panel performs a benefit-risk analysis: home syringe drivers allow patients to remain at home at the end of life with continuous symptom control, comparable devices carry similar residual risk, and nurses visit daily. The panel concludes the benefit outweighs the residual risk. Looking at all residual risks together, it also checks that the number of warnings in the instructions is manageable for a stressed carer. The significant residual risks are disclosed in the instructions for use.

Step 6: review

Before launch, the risk management lead, the design lead, the head of quality and a clinical adviser review the file against the plan. They confirm that each step was carried out, that traceability is complete and that the quarterly post-production review is set up in the complaint-handling procedure. The risk management report is approved by Kestrel's head of quality and its managing director.

Step 7: after launch

Nine months after launch, quarterly review of service records shows several complaints that family members could not hear the occlusion alarm in noisy households. No patient harm is reported, but the team recognises that its probability estimate for "alarm not noticed" was too optimistic. The risk tables are updated, a corrective action raises the alarm volume range and adds an escalating tone, and the instructions are revised. The change is verified, the risk management file is updated and the next quarterly review checks whether complaints fall. This closing of the loop is exactly what clause 10 expects.

Lesson 7 – Relationship to other standards and frameworks

ISO 14971 rarely stands alone. It sits inside a quality management system, receives input from specialised standards and supplies them with the risk framework they rely on.

Figure 4 – ISO 14971 runs inside an ISO 13485 quality system, is explained by ISO/TR 24971 and provides the risk framework used by specialised device standards.

Standard	Focus	Relationship to ISO 14971
ISO 13485:2016	Quality management system for medical device organisations	Requires risk management across product realisation and points to ISO 14971; the quality system provides document control, design controls and corrective action that the risk process relies on.
ISO/TR 24971:2020	Guidance on applying ISO 14971	Explains how to meet the requirements; contains no requirements of its own.
IEC 62366-1	Usability engineering for medical devices	Identifies use-related hazards and validates user interface risk controls; its results feed the risk tables.
IEC 62304	Software life cycle processes for medical device software	Requires an ISO 14971 risk management process and uses it to decide software safety classes and software risk controls.
IEC 60601-1	Basic safety and essential performance of medical electrical equipment	Requires a risk management process conforming to ISO 14971 and relies on the risk management file as evidence for many of its requirements, for example to identify essential performance and judge acceptable risk.
ISO 10993-1	Biological evaluation of medical devices	Frames biocompatibility evaluation as part of the risk management process.
IEC 81001-5-1	Security activities in the health software life cycle	Addresses security risks whose safety consequences are assessed through ISO 14971.
ISO 31000	Generic risk management guidelines for any organisation	Shares the general idea of identifying, analysing, evaluating and treating risk, but defines risk as the effect of uncertainty on objectives and gives guidance only; ISO 14971 is specific to safety of medical devices and contains requirements.

ISO 13485 and ISO 14971

The two standards are partners. ISO 13485 tells an organisation how to run a quality management system; ISO 14971 tells it how to manage product safety risk. ISO 13485 also asks for a risk-based approach to controlling quality system processes, such as how much supplier oversight or process validation is needed, which is a broader use of risk than ISO 14971's focus on harm from the device. Many companies use the device risk file to set priorities for those quality decisions.

Usability, software and security

IEC 62366-1, IEC 62304 and IEC 81001-5-1 each run their own activities but report into the same risk file. Usability engineering finds use errors and validates warnings and interface designs. Software life cycle processes find how software could contribute to hazardous situations and ensure software risk controls are designed and tested. Security risk management, which the 2019 edition acknowledges by including data and systems security in the hazards to consider, finds threats and vulnerabilities and checks whether their exploitation could lead to harm. Keeping one consistent set of hazardous situations across these activities is the main integration challenge.

Common pitfalls and best practices

Common pitfalls

Treating risk management as a document produced at the end of design to satisfy an auditor, rather than as a tool that shapes the design from the start.
Scoring hazards directly instead of the harm from hazardous situations, which hides the sequences of events that controls should target.
Defaulting to warnings and training for risks that a design change or protective measure could have reduced.
Verifying that a control exists but never testing whether it actually works for real users in real environments.
Copying an acceptability matrix from another company without a policy behind it or a justification tied to the device's clinical context.
Assigning invented low probabilities to software failures instead of reasoning from severity when the probability cannot be estimated.
Freezing the risk management file at launch and ignoring complaints, service data and changes in the state of the art.

Best practices

Start risk analysis at concept stage and update it at every design review, so hazards turn into design inputs early.
Write intended use, users and use environments in concrete terms; vague descriptions lead to missed hazardous situations.
Combine top-down and bottom-up techniques and include clinicians and real users in hazard identification.
Keep traceability from each hazardous situation to its controls, verification evidence and residual risk in a tool that the whole team uses daily.
Define severity and probability categories with examples so that different reviewers classify consistently.
Check every new control for the hazards it introduces before considering the risk closed.
Design post-production monitoring with clear triggers for re-opening the risk analysis, and review it on a fixed schedule.

Summary and key takeaways

ISO 14971:2019 is the current edition, confirmed in 2025, and is applied worldwide as the process standard for medical device safety risk management, including IVDs and software.
The standard sets out a process, not safety limits; the manufacturer defines acceptability criteria under a policy approved by top management.
Harm arises from hazards only through sequences of events and hazardous situations, and risk combines the severity and probability of that harm.
Risk control options must be considered in priority order: inherently safe design, then protective measures, then information for safety.
Every control is verified for implementation and effectiveness, and new risks created by controls are analysed.
Benefit-risk analysis is used when residual risk remains unacceptable and further control is not practicable, and overall residual risk is evaluated across the whole device.
There is no accredited ISO 14971 certificate; conformity is shown through the risk management file in quality system audits, notified body reviews and regulatory submissions.
The process continues after release, with production and post-production information feeding back into the analysis.

Reflection questions

Pick a device you know, such as a blood pressure monitor or a hearing aid. Name one hazard, a sequence of events, the hazardous situation and the harm, and suggest one control that targets each step of the chain.
Your team proposes to control a serious risk with a warning label because a design change would delay the launch. How would you use the priority order of risk control to respond, and what evidence would you ask for?
How would you set severity and probability categories for a home-use device so that engineers, clinicians and post-market staff classify the same event consistently?
Which information sources would you include in a post-production monitoring plan for a software-based diagnostic app, and what findings would trigger a reopening of the risk analysis?
In your organisation, where would usability, software and security analyses connect to the main risk management file, and what could go wrong if they were kept separate?