Maps to
QMSR / ISO 13485: §820.30(b)
ISO 13485: §7.3.2
IEC 62304: §4.3
Requirement text
The manufacturer shall assign a software safety class (A, B, or C) to the software system and to each software item, based on the severity of harm that could result from software failure. The classification determines which IEC 62304 requirements are mandatory and must be documented.
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
- •A software safety class (A, B, or C) must be assigned and documented for the software system.
- •Classification must be based on the severity of harm from worst-case software failure, considering risk controls external to the software.
- •Class A: software failure cannot contribute to serious injury or death.
- •Class B: software failure can contribute to non-serious injury.
- •Class C: software failure can contribute to death or serious injury.
- •The classification rationale must be documented and traceable to the risk analysis.
Common gaps
Internal software controls used to lower safety classification
majorManufacturers claim lower safety classes by pointing to risk controls implemented within the software itself (e.g., range checks, watchdog timers). IEC 62304 explicitly states that only risk control measures external to the software system may be used for classification — software probability of failure is assumed to be 1.
Device risk classification conflated with software safety classification
majorTeams confuse IEC 62304 software safety classification (A/B/C) with EU MDR device risk classification or FDA's 'Basic/Enhanced' documentation levels. These use different criteria and affect different regulatory requirements. FDA's levels are determined by intended use before mitigations, while IEC 62304 classification considers external mitigations.
Classification claimed without documentation evidence
majorManufacturers state 'compliant with IEC 62304:2015+A1' in GSPR checklists without producing the documented, evidence-based classification rationale. Notified Bodies require documentation demonstrating the classification decision process, not just assertions.
Evidence signals
- •
FILE_EXISTS
Software.*Development.*Plan|Software.*Classification|SDMP|Risk.*Management.*Report
- •
CONTENT_MATCH
Does this document state the IEC 62304 software safety class (A, B, or C) assigned to the software, with a rationale explaining the worst-case harm from software failure and why higher severity classes are excluded?
Audit defense
The Software Development and Maintenance Plan for [your product] (Doc ID: [your document ID]) documents the IEC 62304 software safety class assignment with rationale linking to the Risk Management Report. The classification drives which development requirements apply and is verified at the start of each development cycle.