How do I classify software into Class A, B, or C under IEC 62304?
IEC 62304 §4.3 · ISO 14971 risk management
The short answer
IEC 62304 defines three safety classes based on the severity of harm that could result from a software failure. The class determines which lifecycle activities and documentation are mandatory. Classification must consider risk controls from ISO 14971 — controls outside the software can reduce the software safety class.
The three software safety classes
| Class | Harm severity (residual after risk controls) | Lifecycle requirements |
|---|---|---|
| Class A | No injury or damage to health possible | Baseline lifecycle documentation |
| Class B | Non-serious injury possible | Adds architecture, unit verification, integration testing |
| Class C | Death or serious injury possible | Adds per-unit design specs, full traceability, independent review |
Step-by-step classification process
- Define the hazardous situation: What failure modes could occur? What clinical harm could result (using ISO 14971 hazard analysis)?
- Identify risk controls (ISO 14971): What risk controls are in place? Are they inside the software or outside it (hardware, procedure, user training)?
- Determine residual severity: After all risk controls are applied, what is the residual severity of harm that could still result from a software failure?
- Assign software safety class: Based on the residual severity (no harm → A; non-serious injury → B; death or serious injury → C)
- Classify at the software item level: Different components of the same system can have different classes; classify each item separately
- Document the classification rationale: This is required — a written document showing the failure modes, the risk controls considered, the residual severity, and the resulting class
Risk controls outside software can reduce the class
ISO 14971 risk controls that are outside the software — and that are real, effective, independent of the software failure mode, reliably implemented, and documented — can reduce the software safety class.
Example: An infusion pump software that could deliver an overdose. If a hardware alarm circuit (independent of the software, reliably detected in validation) stops the pump when a threshold is exceeded, the residual harm from a software failure may be reduced. This must be documented and validated — it cannot be assumed.
Component-level classification
A single software system can have items classified at different levels. For example:
- Drug dose calculation module — Class C (error could cause death)
- Clinical alert display module — Class C (missed alert could cause harm)
- Audit logging module — Class A (failure has no direct patient harm)
- User interface theme/styling module — Class A (no clinical function)
Component-level classification is advantageous because it limits the most demanding Class C requirements to only the safety-critical parts of the system.
Common classification mistakes
- Classifying the whole system as one class: All components receive Class C even when many have no patient safety impact
- Not considering risk controls: Classifying based on the initial unmitigated risk rather than residual risk after controls
- Not documenting rationale: Verbal agreement on class without a written classification document — this is always a finding in audits
- Using intended use instead of failure mode: Classification should be based on what happens when the software fails, not what it is designed to do
Frequently asked questions
Can a Class C software item become Class B with risk controls?
Yes, if valid risk controls outside the software reduce the residual severity to non-serious injury. The risk controls must be truly independent of the software failure mode, reliably implemented in hardware or procedure, and validated as effective. The reduction must be documented with supporting risk management records.
Does Class A still require documentation?
Yes. Class A still requires a Software Development Plan, Software Requirements Specification, system test records, release records, a SOUP register, and problem resolution records. Class A does not mean "no process" — it means a reduced (but still defined) set of required activities.
Does the software class change during development?
It can, and should be re-evaluated if the intended purpose changes, if new hazard analysis reveals additional failure modes, or if risk controls are added or removed. Reclassification requires updating the classification document and may require additional lifecycle activities.
What class does inherited SOUP receive?
SOUP is managed at the software item level where it is used. If a SOUP library is used in a Class C software item, that SOUP must be managed at Class C SOUP requirements (including full anomaly evaluation). SOUP classification cannot be lower than the safety class of the item that uses it.