An IEC 62304 auditor rarely asks to run your software. They ask to see the records that prove how you built it: the requirement a line of code traces back to, the design decision behind a module, the test that shows a Class C function behaves, the evaluation of that open-source library someone pulled in three years ago. When those records were created alongside the code, the audit is paperwork. When they were not, you are reconstructing history from memory, and that is where compliance projects go to die.
That is the whole point of building to IEC 62304 from the start. The standard is not a test you pass at the end of development. It is a way of working that leaves a documented, traceable trail as you go. This guide explains what the standard requires, how its safety classes decide how much work you do, and why the cheapest route to compliance is the one that begins before the first commit.
What IEC 62304 Covers
IEC 62304 is the international standard for medical device software life cycle processes. The version in force is IEC 62304:2006 with Amendment 1 from 2015 (in Europe, EN 62304:2006+A1:2015). It is harmonized under the EU Medical Device Regulation, recognized by the US FDA, and referenced by regulators, including the UK MHRA. If you place medical device software on those markets, auditors and reviewers expect your development records to follow it.
The standard does not tell you which methodology to use. Waterfall, iterative, agile, all are acceptable, because 62304 governs processes and outputs, not management style. What it requires is a set of life cycle processes: software development, maintenance, risk management, configuration management, and problem resolution. Inside development sits a chain of activities from planning through requirements, design, implementation, integration, system testing, and release. The thread running through all of it is traceability, so that any piece of the software can be followed back to a requirement, a risk, a design decision, and a test.
How IEC 62304 Software Safety Classes Affect Development Requirements
Before any of the lifecycle activities matter, you make one decision that scales the entire effort: the software safety classification.
IEC 62304 sorts software into three classes by the harm a failure could cause. Class A applies when no injury or damage to health is possible from a software failure. Class B applies when a failure could lead to non-serious injury. Class C applies when a failure could lead to death or serious injury.
Amendment 1 sharpened how you reach that decision. You classify based on the software’s contribution to a hazardous situation, after accounting for risk control measures that sit outside the software, in hardware, alarms, or procedures. If a software failure could still contribute to a hazardous situation, the standard pushes you toward the higher class unless the severity of the resulting harm justifies a lower one. You can break a system into software items and assign different classes to different items, then segregate the higher-class items from the rest, but the segregation has to be justified, not just asserted.
This is the decision the “from day one” idea turns on. A Class C system carries the full weight of the standard. A Class A system carries far less. Get the class wrong early, and you either over-engineer with a low-risk tool or, worse, under-document a high-risk one and discover it at audit. Classify first, architect for the class, and every downstream task is sized correctly from the start.
IEC 62304 Requirements Across the Software Development Lifecycle
The activities you owe grow with the class. The table below is a simplified view, and the standard itself remains the authority on the exact tasks.
Figure: Your safety class sets your workload. Class A carries the least, Class C the most, while risk management, configuration management, and problem resolution run across every class.
Three processes run underneath all of this, for every class. Risk management feeds the classification and tracks how software contributes to hazards. Configuration management controls versions, builds, and changes, so you always know exactly what was shipped. Problem resolution records defects, their analysis, and their fixes, including whether a fix introduced a new risk of its own. None of these are phases you finish. They run the length of the product’s life, including maintenance after release, which 62304 treats as a process in its own right.
How to Manage SOUP Under IEC 62304
Almost no medical device software is written entirely from scratch. It sits on an operating system, pulls in open-source libraries, reuses code from an older product, and calls third-party components nobody on the current team wrote. IEC 62304 has a name for all of that: SOUP, software of unknown provenance. Software that was already developed and is generally available, or for which you simply have no adequate development records.
The standard does not forbid SOUP. It forbids using it blindly. For every SOUP item, you have to identify it precisely, version included, and specify the functional and performance requirements you need it to meet, along with the hardware and software it depends on. For Class B and Class C software, you also evaluate the published anomaly lists, the known-bug lists for each SOUP component, and decide whether any known defect could contribute to a hazardous situation in your device. SOUP then goes into your risk management, like any other potential source of failure.
This is where 62304 meets how modern software is actually built, and where many legacy systems fail an audit. An aging platform stuffed with undocumented third-party code is a SOUP problem wearing a trench coat. Cataloguing it, pinning its versions, and evaluating its known defects is engineering work, and it is far easier to do as you integrate a component than to excavate years later.
How IEC 62304 Works with Other Medical Device Standards
IEC 62304 is one standard in a small constellation, and it assumes the others are in place. Risk management runs on ISO 14971, and your software classification depends directly on the hazard analysis that lives there. The quality system around your development is expected to meet ISO 13485. Usability and use-related risk fall under IEC 62366-1. And the reason all of this matters commercially is regulatory: under the EU MDR, IEC 62304 is a harmonized standard, so following it supports your presumption of conformity, and the FDA recognizes it as a consensus standard in premarket submissions. Compliance with 62304 is rarely the goal on its own. It is a software-shaped piece of a larger market-access puzzle.
Why Building for IEC 62304 from the Start Reduces Compliance Costs
It is tempting to treat 62304 as documentation you can generate near release, once the software works. That is the expensive path, and it is expensive in a specific way.
The standard core demand is traceability, and traceability cannot be faked after the fact. Reconstructing which requirement drove which module, recovering the design rationale for code written months ago, and back-filling unit verification for a Class C system cost far more in time and credibility than producing the records as the work happens. Retrofitted records also tend to be the thin kind that auditors probe hardest, because gaps in a process show up as gaps in a paper trail.
The risk is not only scheduled. Software process failures put products on recall lists. Whatever the precise number, the pattern regulators keep finding is consistent: weak development controls turn into field failures. Building the controls in is cheaper than recalling a device that skipped them.
Expected Changes in IEC 62304 Edition 2
A second edition of IEC 62304 has been in development and is expected to be published in 2026. Until it is final, IEC 62304:2006+A1:2015 remains the standard you build to, so treat what follows as direction, not current requirement.
The draft points to a real shift. Its scope is expected to widen beyond traditional medical device software toward health software more broadly. It is expected to add explicit lifecycle requirements for AI and machine learning, the area where development controls are thinnest today, and where recalls have clustered. And it is expected to bring cybersecurity in as a core design concern rather than an afterthought. If you are building AI-enabled or connected medical software now, designing those expectations early is the same bet as classifying early: cheaper to build in than to bolt on when the edition lands.
Why IEC 62304 Compliance Should Begin at the Start of Development
IEC 62304 rewards teams that decide early what their software’s safety class is, then create the records that prove safe development as they write the code. Classify first. Architect for the class. Track your SOUP as you adopt it. Keep risk, configuration, and problem resolution running for the life of the product. Do that, and an audit becomes a review of work you already finished rather than an archaeology project.
Nalashaa builds and modernizes medical device software to IEC 62304, with classification, traceability, and SOUP handling designed in from the first sprint instead of being reconstructed under audit pressure. Talk to our medical device software engineering team.
Frequently asked questions
What is IEC 62304?
It is the international standard that defines life cycle processes for medical device software, covering development, maintenance, risk management, configuration management, and problem resolution. The version in force is IEC 62304:2006+A1:2015.
What are the IEC 62304 safety classes?
Three. Class A, where no injury is possible from a software failure; Class B, where non-serious injury is possible; and Class C, where death or serious injury is possible. The class determines how many of the standards’ activities apply to your software.
Is IEC 62304 mandatory?
The standard itself is not law, but it is harmonized under the EU MDR and recognized by the FDA, which makes following it the practical route to market in those regions. Auditors and reviewers expect your records to align with it.
What is SOUP in IEC 62304?
SOUP is software of unknown provenance: third-party, open-source, or legacy components you did not develop for the device, or have no adequate records. The standard requires you to identify it, specify what you need it to do, and, for Class B and C, evaluate its known defects for safety impact.
Does IEC 62304 allow agile development?
Yes. The standard governs processes and outputs, not methodology, so agile is compatible. AAMI TIR45 offers recognized guidance on applying agile practices within a 62304 framework.
