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.3.3 Design and development inputs
Pre-QMSR Part 820 (legacy QSR): §820.30(g) Design validation.
Requirement text
For Class B and C software, the manufacturer shall identify software items that could contribute to hazardous situations, analyze the causes of such contributions including SOUP anomalies, define and implement risk control measures in the software, verify those controls, maintain traceability between software risk items and risk controls, and analyze software changes for safety impact.
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) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
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 publishing known defects with risk assessments (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.