noukuTL;DR: IEC 62304 is a software lifecycle process standard, not a product-conformance standard — it tells you which development activities are mandatory, not what your software must do. The classification (A, B, or C) drives how much of that lifecycle applies, and it's derived from the hazard, not the software's complexity. The two mistakes we see most often: treating classification as a one-time decision made at kickoff, and assuming decomposition into lower-classified software items is automatic rather than something you have to actively design and justify.
The Standard Governs Process, Not Product
IEC 62304, "Medical device software — Software life cycle processes," does not specify functional or performance requirements for a device. It specifies which engineering activities — planning, requirements analysis, architectural design, detailed design, unit verification, integration testing, system testing, release, plus ongoing configuration management, problem resolution, and maintenance — are required, and to what depth, for a given piece of software.
This distinction matters because it changes what "compliance" means. A submission doesn't demonstrate IEC 62304 conformance by showing the software works. It demonstrates conformance by showing the process that built the software left the required trail: traceable requirements, a defined architecture, verified units, documented integration and system test coverage, and a controlled release. Regulators (FDA recognizes IEC 62304 as a consensus standard; EU MDR references it through harmonized standards) use that trail as evidence of process rigor — it is one input into a submission, not a certificate a product carries on its own.
A common downstream error: engineering teams that treat the standard as a checklist to satisfy after the fact, rather than a set of gates that has to be planned into the schedule from day one. Retrofitting IEC 62304 artifacts onto a codebase that was built without them is possible, but it's materially more expensive than building the trail as you go — you end up reverse-engineering requirements and architecture documentation from code that already shipped.
Classification Is a Hazard Judgment, Not a Complexity Estimate
The standard defines three safety classes, and the class is what determines how much of the lifecycle is mandatory:
- Class A — no injury or damage to health is possible.
- Class B — non-serious injury is possible.
- Class C — death or serious injury is possible.
The classification question is not "how complicated is this module?" It's "if this software fails or behaves incorrectly, what's the worst credible harm?" That means classification is downstream of hazard analysis under ISO 14971, not an independent software engineering judgment. A trivial fifty-line module that computes a dosage multiplier can be Class C. A large, architecturally complex logging subsystem with no path to patient harm can be Class A.
This is where we see the first recurring mistake: teams classify software based on engineering intuition about risk ("this is just UI code, it's low risk") instead of running it through documented hazard analysis first. IEC 62304 explicitly expects the classification to be traceable back to the risk management file — if a reviewer can't follow the line from a specific hazard to the classification decision, the classification isn't defensible, regardless of whether it happens to be correct.
The second recurring mistake is treating classification as something decided once, at project kickoff, and never revisited. Classification should be reassessed whenever the architecture changes in a way that affects the hazard analysis — a new integration point, a changed failure mode, a component moving from advisory to closed-loop control. A classification frozen at the start of a project on assumptions that no longer hold is a documentation gap that surfaces at the worst possible time: during an audit or a post-market investigation.
Decomposition: The Segregation Escape Hatch, and Why It's Not Automatic
Amendment 1:2015 clarified something teams frequently get backwards: classification doesn't have to apply uniformly to an entire software system. It can be applied at the software item level, provided you can demonstrate adequate segregation between items of different classes.
In practice, this means an architecture that isolates a Class C control function from a Class A diagnostics/UI layer can classify each item separately — you don't have to carry the full Class C lifecycle burden (more rigorous detailed design documentation, more exhaustive unit and integration verification) across code that has no path to patient harm.
The mistake is assuming this segregation is a property you get automatically because two things live in "different modules" or "different services." Segregation has to be actively designed and verified — process isolation, defined interfaces with no shared mutable state, communication mechanisms that can't silently propagate a fault from the low-classification item into the high-classification one. If the segregation argument doesn't hold up under scrutiny (a shared memory region, a shared thread pool, an interface that lets malformed input from the Class A item reach the Class C item unchecked), the whole system reverts to the higher classification. Teams that assume decomposition first and try to retrofit the isolation argument later usually find the architecture doesn't actually support the claim they wanted to make.
SOUP Is a Risk Item, Not a Bill-of-Materials Entry
SOUP — Software of Unknown Provenance — covers any software component you didn't develop under a controlled lifecycle: third-party libraries, an RTOS, a compiler runtime, an open-source dependency. IEC 62304 doesn't prohibit SOUP. It requires that you:
- Identify it explicitly, including version.
- Document its functional and performance requirements as used in your system — not the vendor's full feature set, just what you actually depend on.
- Review the vendor's published anomaly list (known defects) against your intended use.
- For SOUP used in a Class B or C item, justify how you're mitigating the fact that it wasn't developed under a lifecycle that produced verification evidence equivalent to what you'd need to have built it yourself.
The mistake here is treating SOUP identification as an inventory exercise — "list the third-party libraries" — rather than a risk exercise. A well-known, widely-audited library used outside its documented operating envelope is a bigger risk than an obscure library used exactly as intended. The justification has to speak to your usage, not the library's general reputation.
Where Methodology Assumptions Go Wrong
IEC 62304 is process-content-agnostic on development methodology. It does not mandate waterfall, and it is compatible with iterative or agile delivery — the standard cares that the required activities happen and produce traceable evidence, not that they happen in a particular sequence or cadence. Agile teams can satisfy it; they just have to be deliberate about where the documentation gates sit relative to sprints, rather than assuming continuous delivery removes the need for them.
The practical failure mode we see isn't methodology mismatch — it's teams assuming the standard requires a specific process shape, either avoiding agile because "regulated software has to be waterfall," or avoiding IEC 62304 rigor because "we're agile, that doesn't apply to us." Neither assumption is correct. What has to survive contact with any methodology is the traceability: requirement to architecture to implementation to test to release, with the risk classification threaded through all of it.
Build the Evidence Trail as You Go, Not After
None of the above changes what code you write. It changes what evidence that code has to leave behind, and at what points in the schedule that evidence has to exist rather than get reconstructed later. For teams building the software (rather than assembling the regulatory submission), the practical consequence is: hazard analysis and classification come before architecture decisions, not after; segregation is a design constraint stated up front, not a documentation task at the end; and SOUP review happens at the time a dependency is chosen, not during an audit prep sprint.