IEC 62304 risk classes A, B, C: what each one actually requires

Class A is "no injury possible." Class B is "non-serious injury possible." Class C is "death or serious injury possible." That sentence is the entire risk classification framework. The other 80 percent of your validation effort is the documentation and testing burden each class triggers downstream.

Get the class right and the rest of the lifecycle is cheap. Get it wrong and you're either rewriting the DHF mid-audit or generating six months of evidence the FDA didn't need.

How classification actually works

Per IEC 62304 §4.3, the manufacturer assigns the safety class based on the possible effects on the patient, operator or other people resulting from a hazard the software contributes to. Risk control measures external to the software are considered when assigning the class.

Two things matter here. First, the risk is post-mitigation. If a hardware interlock prevents the software from causing harm, the software class drops. Second, the assignment is per software system or item. A single device can have Class C control software and Class A logging software living in the same binary.

The hazard analysis drives the classification. ISO 14971 is the input. IEC 62304 §7 is the structure for software risk management on top of that.

Class A in practice

Class A software cannot contribute to a hazardous situation. Or any contribution it makes does not result in unacceptable risk after the external risk controls are applied.

Concrete examples I've seen classified as Class A:

• A standalone label-printing utility for IFU revision tracking
• A web-based feedback form for post-market surveillance
• An internal dashboard that aggregates non-clinical metrics
• Firmware that controls cosmetic LED patterns on a device exterior

§5 requires the minimum lifecycle documentation here. A software development plan, a software requirements spec, a brief architecture description and unit-level implementation. Verification testing exists but it's light. Class A doesn't require detailed software architecture per §5.3.1, and integration testing is not required per §5.6.

What auditors look for: a defensible argument that the software cannot cause harm. The classification rationale is the first document they read. If the rationale is one sentence, expect a 483.

Class B in practice

Class B software can contribute to a hazardous situation that results in non-serious injury.

Examples I've seen as Class B:

• Patient data display software where a misread could lead to a delayed but recoverable clinical decision
• Therapy parameter input software with hardware limits preventing dangerous values
• Diagnostic assist software that surfaces findings for clinician review, with the clinician retaining final judgment
• Logging software where the captured parameters are used in treatment review

The lifecycle bar steps up. §5.3 requires a documented software architecture. §5.5 requires unit implementation and verification with documented acceptance criteria. §5.6 requires integration testing. §5.7 requires system testing.

Auditors look for traceability. Requirement → design → test → risk control. The trace matrix is the spine of the DHF for Class B. If your matrix has gaps, every gap becomes an observation.

The other thing they check is unit testing rigor. The standard doesn't strictly require statement coverage for Class B, but I've watched FDA reviewers increasingly expect structural coverage metrics, especially for SaMD. Build it in early. Retrofitting coverage data is brutal.

Class C in practice

Class C software can contribute to a hazardous situation that results in death or serious injury.

Examples:

• Closed-loop insulin dosing algorithms
• Radiation therapy treatment planning calculations
• Ventilator control software
• AED rhythm analysis algorithms
• Infusion pump rate control firmware

The bar is full. Everything Class B requires plus detailed architectural design per §5.3.4 with separation of concerns, documented design decisions and explicit identification of segregation between software items of different classes.

§5.5.2 requires the manufacturer to establish strategies, methods and procedures for verifying each software unit. For Class C this typically means structural coverage analysis: statement coverage, decision coverage. Many teams target MC/DC for the most critical units even though the standard doesn't strictly require it.

§7 risk management is exhaustive. Every identified hazard needs a documented risk control, the verification of that control and a residual risk evaluation. Software of unknown provenance gets its own treatment under §8.

Auditors look for defense in depth. Architecture documents that show how a single fault cannot propagate to patient harm. Test evidence at every level. Risk control verification with measured residual risk.

The DHF for Class C software is often 10x the volume of a Class B DHF for the same lines of code. That ratio surprises people. It shouldn't.

The misclassification trap

The most expensive mistake is classifying down. Calling Class C software "Class B with hardware mitigations" when the hardware mitigation isn't actually independent of the software. I've seen this trip teams in mid-audit, and the recovery is months.

The second most expensive mistake is classifying up. Treating an internal logging tool as Class B because nobody wants to defend a Class A classification. This wastes engineering time and creates SOP debt that compounds for years. The "play it safe" instinct is wrong here. Defensible Class A is cheaper than indefensible Class B.

Get the classification right at the start. Document the rationale. Have a clinical SME review it. Revisit when the architecture changes.

When you mix classes in one system

Per §5.3.3, software items of different classes can coexist, but the manufacturer must demonstrate segregation. Architectural separation, distinct memory spaces, explicit interface contracts.

If you can't demonstrate segregation, the entire system inherits the highest class. A Class A logging module embedded in a Class C control loop is Class C software for compliance purposes. This is the place architectural decisions made early save real validation cost later.

What's worth doing now

Pull your existing classification rationales. If any one is shorter than a paragraph, rewrite it. The rationale is the document the auditor reads first; treating it as a checkbox is how observations happen.

Check your segregation arguments for any mixed-class system. I see teams claim segregation the architecture doesn't actually support. The pattern is consistent enough that I'd treat it as the default risk.

Map your test evidence against your class requirements. Class B without integration testing is an observation. Class C without risk control verification is a recall waiting to happen.

Classification drives everything downstream. Get it right once, document it well, and the rest of the lifecycle gets a lot cheaper.

VibeVal checks IEC 62304 structural requirements against your declared risk class. $0.50 per Class A check, $2.00 for B, $5.00 for C. Each check returns a CSA-aligned rationale and a SHA-256 attestation hash for the DHF.