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: §820.30(b) Design and development planning.
Requirement text
The manufacturer shall assign to each software system a software safety class (A, B, or C) according to the risk of harm to the patient, operator, or other people resulting from a hazardous situation to which the software system can contribute in a worst-case scenario. When a software system is decomposed into software items, and when a software item is decomposed into further software items, such software items shall inherit the software safety classification of the original software item (or software system) unless the manufacturer documents a rationale for classification into a different software safety class. Compliance with IEC 62304 is defined as implementing all of the processes, activities, and tasks identified in the standard in accordance with the software safety class.
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. Figure 3 of clause 4.3 states that, in determining the software safety class of the software system, the probability of a software failure shall be assumed to be 1 and only risk control measures not implemented within (external to) the software system shall be considered. A developer who was also allowed to claim that their own code reduces the classification would have 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) 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)
- 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). Figure 3 of IEC 62304 clause 4.3 states that, in determining the software safety class, the probability of a software failure shall be assumed to be 1 and only risk control measures not implemented within (external to) the software system shall be considered.
- 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.