Maps to
QMSR / ISO 13485: §820.30(g)
ISO 13485: §7.1
IEC 62304: §7
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.
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.
Atomic constraints
- •Software items that could contribute to hazardous situations must be identified (Class B and C).
- •Potential causes of software contribution to hazards must be analyzed, including SOUP anomaly lists.
- •Software risk control measures must be defined and implemented.
- •Implemented software risk control measures must be verified for effectiveness.
- •Traceability must be maintained between hazardous situations, software items, risk controls, and verification evidence.
- •Software changes must be analyzed for impact on existing risk control measures.
Common gaps
Software risk management disconnected from ISO 14971 process
majorSoftware-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.
Evidence signals
- •
FILE_EXISTS
Risk.*Table|FMEA|Traceability.*Matrix|Software.*Risk
- •
CONTENT_MATCH
Does this document identify software items that contribute to hazardous situations, define risk control measures implemented in software, and maintain traceability from hazards to software risk controls and their verification?
Audit defense
Software risk management for [your product] is integrated into the Risk Table (Doc ID: [your document ID]) with software-specific failure mode rows. A traceability matrix traces each software-related hazard to the software requirement implementing the risk control and to the test verifying its effectiveness, per IEC 62304 section 7.3.3.