V-model structure, hazard analysis, and documented design rationale — severity-based classification logic existed in prior practice.
Formal Class A/B/C tiers drive required activities; only risk controls external to the software may reduce classification.
Classification rationale document — reviewers verify worst-case failure scenario, external-control basis, and traceability to the risk management report.
Maps to
IEC 62304: §4.3 Software safety classification
ISO 13485: §7.3.2 Design and development planning
Pre-QMSR Part 820 (legacy QSR): §820.30(b) Design and development planning.
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.
Why this clause exists
Software safety classification is the architectural decision that scales regulatory burden to actual patient risk — without it, every manufacturer faces the choice between applying the full weight of Class C requirements to a utility whose failure could never injure anyone, or leaving a genuinely dangerous system under-controlled. The clause formalizes what would otherwise be an informal engineering judgment, and the specific rule that only risk control measures external to the software can lower the classification is not arbitrary: software is assumed to have probability of failure equal to 1 because a developer who is also allowed to claim that their own code reduces the classification has a structural incentive to design around the rule rather than around the hazard. The Therac-25 incidents (1985–1987), where race conditions in a radiation therapy device's software control interface contributed to lethal overdoses, illustrate the catastrophic consequence of inadequate software-level scrutiny for devices where software failure directly controls patient exposure. IEC 62304:2006+A1:2015 clause 4.3 codifies the three-class framework precisely because the consequences of misclassification are not symmetric: a device under-classified as A when it should be C operates without the unit verification, architectural segregation, and software risk management requirements that define Class C — and the compliance record gives no visible warning until a patient is harmed.
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)
- Internal software controls used to lower safety classification — Manufacturers 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 — Teams 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 — Manufacturers 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.