Hazard analysis, risk control measures, and traceability from hazard to control — ISO 14971 process already requires this at the device level.
Software items contributing to hazardous situations must be identified; SOUP anomaly lists are a required risk input; traceability extends from hazard to verified risk control.
Software risk traceability matrix — reviewers check that every software-implemented risk control has a corresponding requirement and a passing verification test.
Maps to
IEC 62304: §7 Software risk management process
ISO 13485: §7.1 Planning of product realization, §7.3.3 Design and development inputs
Pre-QMSR Part 820: §820.30(g) Design validation.
Requirement text
For software safety classes B and C, the manufacturer must identify software items that could contribute to a hazardous situation identified in the medical device risk analysis activity of ISO 14971, identify the potential causes of that contribution and document them in the risk management file (evaluating as a minimum, if failure or unexpected results from SOUP is a potential cause, any anomaly list published by the supplier of the SOUP item relevant to the version used), define and document risk control measures for each case documented in the risk management file where a software item could contribute to a hazardous situation (and, if a risk control measure is implemented as part of the functions of a software item, include it in the software requirements, assign to each contributing software item a software safety class based on the risk that the measure is controlling, and develop the software item in accordance with Clause 5), verify the implementation of each risk control measure and document that verification, review the risk control measure to determine if it could result in a new hazardous situation, document traceability of software hazards as appropriate, analyse changes to the software, including changes to SOUP, to determine whether the modification could interfere with existing risk control measures, and perform relevant risk management activities defined in 7.1, 7.2 and 7.3 based on the analyses of software changes; and, for software safety classes A, B and C, the manufacturer must analyse changes to the medical device software (including SOUP) to determine whether additional potential causes are introduced contributing to a hazardous situation and whether additional software risk control measures are required.
Why this clause exists
IEC 62304:2006+A1:2015 clause 7 exists at the intersection of software engineering and ISO 14971 risk management because neither discipline alone is sufficient to close the gap between hazard identification and verified risk control in software: risk management identifies what must be controlled, but without a software-specific process, no mechanism exists to ensure the identified control is actually implemented in code, tested to verify it works, and maintained across software changes. The failure mode this clause prevents is the risk management file that lists software-based controls as present and effective when the corresponding software either never implemented them or implemented them in a form that was subsequently overwritten by a maintenance change. SOUP anomaly analysis is included explicitly because SOUP components introduce a category of failure cause that is outside the manufacturer's direct control — a known defect in a third-party library that is not reviewed and assessed may silently contribute to a hazardous situation without the manufacturer having any knowledge that a control they rely on has been undermined. The traceability requirement — hazardous situation to software item to risk control to verification — creates the audit chain that makes the risk management process claims checkable: an auditor who can follow that chain from hazard to verified test has objective evidence that the control exists and was tested; an auditor who cannot trace it has only an assertion.
What changed
Amendment 1 (2015) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for identification and avoidance of common software defects (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Software risk management disconnected from ISO 14971 process — Software-specific risk management is performed in isolation from the overall device risk management process required by ISO 14971. Software hazards are not integrated into the Risk Management File, and software risk controls are not tracked alongside hardware and use-related controls.