A software safety class is not a label you attach at the end of development. It decides how much of IEC 62304 applies to you, and therefore what a release costs for the rest of the product's life. We see the same pattern often enough to write it down: teams pick Class C because it feels responsible, and pay for it in every release afterwards.
Why the class decision is a cost decision
IEC 62304 scales its requirements with the harm that software can cause. Class A asks for planning, requirements, system testing and a controlled release. Class C adds a documented design down to the level of individual units, with verification to match. Between those two sits a difference of months, not days, and it repeats with every substantial change.
The decision is usually made early, when the architecture is still a sketch and nobody wants to argue about it. Choosing the higher class looks like the cautious option. It is not cautious if it is unjustified: you are committing a small team to an evidence load they will meet under time pressure, on every release, for years.
What actually determines the class
The class follows from what happens if the software fails, after you account for risk controls that sit outside the software. That last part is where most classifications go wrong.
If a hardware interlock cuts power independently of any code, or an alarm reaches the operator through a path the software cannot suppress, the harm the software can cause is genuinely lower. Those controls have to be real: independent of the software item in question, verified, and documented in your ISO 14971 risk management file. A watchdog implemented in the same firmware that it is supposed to catch is not an external control.
| Class | If the software fails | What it adds |
|---|---|---|
| A | No injury or damage to health is possible | Planning, requirements, system testing, release |
| B | Non-serious injury is possible | Adds architecture, unit verification, integration testing |
| C | Death or serious injury is possible | Adds detailed design down to unit level |
Segregation: the lever most teams skip
A software system does not have to carry one class. Individual software items can be classified separately, provided the segregation between them is adequate and you can show it in the architecture. This is the single most effective way to keep the expensive class small.
In practice that means separating, for example:
- the item that drives therapy or interprets a measurement: the part that can actually cause harm
- the item that renders a dashboard, exports data, or handles OTA delivery
- the item that manages connectivity and buffering
Separate processes, separate memory, a defined interface between them, and a rationale for why a failure on one side cannot propagate to the other. Then only the first item carries Class C. The segregation argument is part of your architecture documentation, not a note in a ticket. An auditor will ask to see it.
Where segregation claims usually break
Shared state is the recurring culprit: a common database the safety-relevant item reads back from, a shared logging buffer that can fill and block, an update mechanism that can replace both items at once. If a failure can travel across the boundary, the boundary is not segregation.
What each class costs you in documentation
The gap that surprises teams is between B and C. Class C requires design documentation at unit level, which means the design has to be written down before the code and kept in step with it afterwards. On a codebase that changes weekly, that is a permanent tax, not a one-off deliverable.
Class B is often the honest answer for connected devices where the therapy path is hardware-limited and the software's failure mode is a delayed or missing measurement. That is a real risk, and it is usually not a fatal one, but you have to argue it, with the risk file behind you.
How we run the classification
We do the classification together with the architecture, not after it, because the architecture is the only thing that can change the answer. Concretely:
- start from the hazards in the ISO 14971 file, not from the feature list
- list the risk controls outside the software and check each one is genuinely independent
- draw the software items and the boundaries you intend to defend, then classify per item
- write the segregation rationale while the reasoning is fresh
- revisit the classification whenever the architecture moves, not at release
Done this way the class is a conclusion you can defend, and usually a cheaper one than the reflex answer. Done at the end, it is a guess you pay for repeatedly.