IEC 62304 for developers: what it actually means in code

The first time I worked on software that went into a medical device, I made the mistake almost everyone from “normal” software makes: I assumed IEC 62304 was a set of rules about how to write code. It is not.

The standard says almost nothing about coding style. It says something far more uncomfortable: you must be able to prove, at any point, what you built, why you built exactly that, and how you verified it works. The code is only one of the artifacts.

This is the article I wish I had read back then — written by an engineer, not by a quality consultant.

What is IEC 62304, really?

IEC 62304 is the international standard for medical device software life cycle processes. It applies both to software that is a device (software as a medical device) and to software inside a device.

What it defines are processes, not implementations:

• development (planning, requirements, architecture, detailed design, implementation, integration, system testing, release);
• software risk management (tied to ISO 14971);
• configuration management (you know exactly which version of what you shipped);
• problem resolution (bugs are tracked, analysed and closed on record);
• maintenance (what happens after release).

Nowhere does it say “use X” or “reach 80% test coverage”. It says: decide, justify, document, verify.

Why does the safety class decide how much work you do?

This is the lever that changes everything. Before anything else, software is assigned a safety class, based on the worst thing that can happen if it fails:

Class	What can happen if the software fails	What is additionally required
A	Cannot contribute to a hazardous situation — or contributes, but the risk stays acceptable after risk control measures external to the software	Minimal — including identification of third-party components
B	Injury, but not serious	Architecture + software unit verification
C	Death or serious injury	Additionally: detailed design per unit and per interface, plus extra acceptance criteria

One important detail, added by the 2015 amendment: classification happens after you account for risk control measures outside the software. A hardware interlock or an independent monitor can legitimately lower the class — which is exactly the lever described in the next paragraph.

Classification is not administrative paperwork: it determines which activities you are obliged to perform. A class A module can pass with minimal documentation. The same module classified as C demands detailed design down to software units and additional acceptance criteria.

This is also where the highest-leverage engineering strategy I have seen in this field comes from: segregating the risky components. If you can demonstrate architecturally that the dangerous part is isolated from the rest, you can classify separately — and dramatically reduce effort across the rest of the system. That is an architecture decision with a direct budget impact, not just a compliance one.

What does traceability look like in practice?

Traceability is the requirement that surprises developers most. In short: for any piece of functionality, you must be able to follow the whole chain.

From a system requirement → to a software requirement → to the architectural element implementing it → to the test verifying it → back to the risk it controls.

In practice this means every requirement has a stable identifier, and commits, tests and documents reference it. You do not need expensive tooling to start; you need discipline and an ID that never changes.

What I learned: if you leave traceability “for the end”, it is already lost. Reconstructing the links after six months of development costs far more than maintaining them as you go.

What is SOUP, and why does it hurt?

SOUP stands for Software Of Unknown Provenance — any component you did not develop under this process: open-source libraries, runtimes, drivers, even parts of the operating system.

Using SOUP is not forbidden. Identification is required at every class; the remaining obligations below apply from Class B upward. So for each component you must:

• identify it precisely — name, version, manufacturer (not “latest”);
• specify the functional and performance requirements you rely on;
• specify the system requirements it imposes;
• evaluate published anomaly lists (known bugs) and analyse whether any affect you;
• include the component in your risk analysis.

Here is the practical difference from ordinary software: npm install or adding a NuGet package is no longer a five-second decision. Every new dependency carries a real documentation cost and must be re-evaluated on every update.

The healthy consequence: in regulated projects, the dependency tree stays deliberately small. Not out of technical purism, but because every dependency is paid for in paperwork.

What actually changes in your daily work?

If you come from commercial software, these are the changes you feel immediately:

• You cannot start with the code. Requirements and design come first, and they are real artifacts, not a two-line ticket.
• Changes are not free. A “small” modification can trigger risk re-evaluation, design updates and retesting. It is not pure bureaucracy — it is the price of the fact that someone can be harmed.
• Versions matter absolutely. You must be able to rebuild the exact shipped build, with exactly the same dependencies.
• Bugs have a process. You do not just fix them; you record them, analyse their impact (including on risk), and document the resolution.
• Tests are evidence, not a safety net. A passing test that is not linked to a requirement does nothing for you at audit time.

What are the common mistakes?

From what I have seen, the most expensive ones:

1. Classifying “to be safe”. Class C across the whole system, out of caution, inflates the effort considerably — and gives up the segregation argument you should be able to make anyway. A properly argued classification is a large saving, but it comes with the obligation to defend it.
2. Documentation written at the end. Retroactively reconstructed documents are obvious at audit and frequently inconsistent with the code.
3. Dependencies added without SOUP records. Discovered late, they block the release.
4. Confusing verification with validation. Verification = we built the product right. Validation = we built the right product (the one clinically needed). These are different things.
5. Treating the standard as an obstacle. Most of it is, in fact, good engineering written formally.

How does it relate to FDA requirements?

Briefly: they are not the same thing, but they overlap heavily — and the FDA recognises IEC 62304 as a consensus standard, so conformance with it can form part of the evidence you present.

Two things worth knowing, so you do not start from wrong assumptions:

• The FDA does not use classes A/B/C. For premarket submission documentation, FDA guidance works with two levels — Basic and Enhanced Documentation Level. These are different criteria from the 62304 classification and are determined separately.
• The US framework changed recently. Under the Quality Management System Regulation (QMSR), applicable from February 2026, 21 CFR 820 incorporates ISO 13485:2016 by reference — so older references to “design controls” in §820.30 need to be read in that new context.

In practice, a common approach is to build your process on IEC 62304 (it is more clearly structured as an engineering process) and then add whatever your specific market authority requires on top. If you also deal with electronic records and electronic signatures, you additionally enter 21 CFR Part 11 territory — but that is a separate discussion, which I cover in another article.

What you take with you from “normal” software

The part that pleasantly surprised me: once you adjust, many of the practices imposed here are things you should be doing anyway. Explicit requirements. Written architecture decisions. Few, well-known dependencies. Reproducible builds. Bugs tracked to closure.

The difference is not that you work “more bureaucratically”. It is that you are not allowed to rely on memory and luck. And honestly, that discipline made me a better engineer on unregulated projects too.

If you are building something in this space and want the view of an engineer who has shipped under these requirements — rather than a regulatory consultant — let’s talk.