ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62304 risk management is not a second risk process running beside ISO 14971. Clause 4.2 of the standard requires an ISO 14971 process, full stop; clause 7 then adds the software-specific activities that process needs and says where their outputs go — into the risk management file, not a software folder. Teams that build a separate “software risk analysis” and keep it in the engineering repository have misread the relationship, and it is the kind of gap a notified body audit finds.
This guide explains how IEC 62304 risk management fits ISO 14971:2019, what clause 7 requires step by step, which requirements bind Class A, and the four traceability links assessors look for.
The device risk analysis under ISO 14971 identifies hazards and hazardous situations for the medical device as a whole. IEC 62304 risk management asks, for each of those, whether software could be a cause — and if so, how, and what controls it. It does not run its own hazard identification from scratch. Its inputs come from the device process and its outputs return to it.
| IEC 62304 clause 7 activity | ISO 14971:2019 step it serves | Where the output lives |
|---|---|---|
| 7.1.1 Identify software items that could contribute to a hazardous situation | 5.4 Identification of hazards and hazardous situations | Risk analysis — software section of the risk management file |
| 7.1.2 Identify potential causes | 5.4 (sequences of events); 5.5 Risk estimation | Same |
| 7.1.3 Evaluate SOUP anomaly lists | 5.5 Risk estimation | Same |
| 7.1.4 Document potential causes | 4.5 Risk management file | The file itself |
| 7.2.1 Define risk control measures | 7.1 Risk control option analysis; 7.2 Implementation | Risk control records |
| 7.2.2 Risk controls implemented in software | 7.2 Implementation | Risk control records; the software requirements |
| 7.3.1 Verify risk controls; review for new hazards | 7.2 Verification of implementation and effectiveness; 7.5 Risks arising from risk control | Risk control verification records |
| 7.3.3 Document traceability | 7.6 Completeness of risk control; 4.5 file traceability | Traceability table in the file |
| 7.4 Risk management of software changes | 10.4 Actions (post-production); 7 (during development) | Change records in the file |
One caveat on that table: IEC 62304’s own Annex C maps clause 7 to ISO 14971:2007, in which risk analysis was clause 4 and post-production clause 9. The 2019 edition renumbered — risk analysis is clause 5, risk control clause 7, production and post-production clause 10 with its own information-collection and review sub-clauses. Map from intent, as above, not from the annex. Our guide to ISO 14971 covers the 2019 structure.
Annex B.4.3 of the standard states the assumption that shapes all IEC 62304 risk management: there is no agreed method for estimating the probability that software will fail. So when software sits in a sequence of events leading to harm, its failure probability is set to 1 and risk is estimated on the severity of the harm — and on the probabilities of the non-software events in the sequence, where those can be estimated. Clinical judgement about whether a clinician would detect the failure before harm is a legitimate discriminator. This is also why the software safety class is decided on worst-case harm; our guide to software safety classification covers that decision.
For each hazardous situation in the device risk analysis, identify the software items that could contribute to it — directly, by failing, or because a risk control measure implemented in that software could fail. This is why the analysis is repeated at the end of architectural design: it is the earliest point at which every software item is known.
For each contributing item, identify the potential causes, considering — as appropriate — five categories the standard names: incorrect or incomplete specification of functionality; software defects in the item’s functionality; failure or unexpected results from SOUP; hardware failures or other software defects that could produce unpredictable software operation; and reasonably foreseeable misuse. A category judged not applicable to an item gets a recorded reason, because clause 1.4 treats an undocumented “as appropriate” omission as a gap.
Where SOUP failure is a potential cause, evaluate at minimum the anomaly list the supplier publishes for the version in use, for anomalies that could form part of a sequence leading to a hazardous situation. Our guide to SOUP under IEC 62304 covers the mechanics.
The core of IEC 62304 risk management is risk control. For each documented software contribution, define and document risk control measures in accordance with ISO 14971 — in hardware, software, the working environment or user instruction. Where a measure is implemented in software, three consequences follow: it is written into the software requirements; each item that contributes to implementing it is classified on the risk the measure controls; and the item is developed under clause 5 at that class. A trivial monitoring function guarding against a fatal fault is Class C.
Verify the implementation of each risk control measure and record it; ISO 14971:2019 distinguishes verifying that a measure was implemented from verifying that it is effective, and a good record shows both. Then review the measure for whether it could itself create a new hazardous situation — a false alarm that prompts an unsafe workaround, a safe state that interrupts therapy.
IEC 62304 risk management traceability means four links for each software hazard: from the hazardous situation to the software item; from the item to the specific software cause; from the cause to the risk control measure; and from the measure to its verification. Each link is its own column in the traceability record, and a chain with any link blank is incomplete.
Every software change, including a change to SOUP, is analysed for whether it introduces new potential causes of a hazardous situation and whether additional software risk controls are needed. At Class B and C the analysis also asks whether the change could interfere with existing risk controls, and triggers the 7.1 to 7.3 activities as needed.
Clauses 7.1 to 7.3 are Class B and C. Class A is not excused from risk entirely: the classification itself is a risk decision recorded in the file (4.3 c)); the device risk analysis is re-evaluated when the software requirements are established (5.2.4); every change is analysed for new causes and needed controls (7.4.1); every problem report is evaluated for its effect on safety through the risk process (6.2.1.3, 9.2 b)); and the file is updated as problem resolution requires (9.5). A Class A team that has no risk entries for its software has missed five requirements.
Clause 5.1.7 requires the development plan to include or reference a plan for the software risk management activities, including the management of risks relating to SOUP. It is the software part of the ISO 14971 risk management plan, and it schedules the activities above against the life cycle: classification at system definition and end of architecture; hazard analysis at end of architecture and every architecture change; risk controls before the requirements baseline that carries them; verification at unit, integration and system testing; traceability continuously; change analysis on every change request. Our guide to the ISO 14971 risk management plan covers the device-level plan this sits inside.
The IEC 62304 Toolkit carries a software risk management procedure written as the software part of ISO 14971:2019, a risk management plan template, hazard analysis and risk control templates with the five cause categories and the class-from-controlled-risk rule built in, a verification record, a change safety analysis, a SOUP anomaly-list evaluation, a hazard register and a traceability matrix whose hazard sheet carries the four 7.3.3 links as separate columns with a completeness check — plus a mapping to ISO 14971:2019 written from the requirements’ intent rather than transcribed from the 2007 annex. The standard is licensed by the IEC; the requirements here are paraphrased from it.
No. Clause 4.2 requires an ISO 14971 process; clause 7 adds software-specific activities to it and requires their outputs in the risk management file. It is the software slice of one process.
Clauses 7.1 to 7.3 do not apply at Class A, but the classification record, the requirements-stage re-evaluation of the device risk analysis, change analysis under 7.4.1 and the safety evaluation of every problem report all do.
Because, as Annex B.4.3 explains, there is no consensus method for estimating it. Risk is therefore judged on severity, and on the probabilities of the non-software events in the sequence where those can be estimated.
Hazardous situation to software item; software item to software cause; software cause to risk control measure; risk control measure to its verification — clause 7.3.3, Class B and C.
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026