Guide
IEC 62304: A Software Lifecycle That Holds Up Under Notified Body Review
IEC 62304 is the international standard for medical device software lifecycle processes — required reading for any manufacturer building SaMD or software inside a device, and the framework FDA, notified bodies, and Health Canada all use to evaluate software quality. The 2015 amendment tightened expectations around legacy software, SOUP (Software of Unknown Provenance), and the problem resolution process. This guide walks through the safety classes, the lifecycle activities that scale with class, the artefacts that make up the software file, and a practical implementation path. It is written for software leads, R&D managers, QA, and regulatory affairs at medical device manufacturers.
Start free trial Free trial, no credit card, onboard in days, not months.
Safety classes A, B, C and the scaling principle
IEC 62304 assigns each software system or software item a safety class — A (no injury or damage to health possible), B (non-serious injury possible), C (death or serious injury possible) — based on the hazard the software contributes to and the effectiveness of external risk controls. The class drives how many lifecycle activities apply and at what depth: a Class A item escapes detailed unit testing and integration testing requirements; a Class C item triggers the full set, including documented unit verification and integration test specifications. Misclassification — almost always under-classification — is the most common 62304 finding. Classifying a closed-loop control item as Class A because 'the doctor is in the loop' rarely survives review.
The software development plan and architecture
Clauses 5.1 and 5.3 require a Software Development Plan that describes the lifecycle model, the deliverables, the configuration management and problem resolution approach, and the verification activities at each stage. Clause 5.3 then requires the software architecture to be documented down to the level needed to identify SOUP, separate items by safety class, and isolate risk-controlling segregation. Architecture diagrams that stop at 'the app talks to the API' are not sufficient — the reviewer needs to see the segregation that justifies a lower safety class for items that don't touch the hazard path.
SOUP: the rule that catches everyone
Software of Unknown Provenance covers any software item not developed for the purpose of incorporation into the medical device — open-source libraries, commercial components, operating systems, container base images. Clause 5.3.3 requires you to specify functional and performance requirements for each SOUP item, the hardware and software it requires to operate, and any anomalies that could contribute to a hazard. Clause 7 then requires SOUP to be included in the change control and problem resolution process. A modern SaMD pulls hundreds of npm or pip packages — the 62304-compliant answer is not to list them in a spreadsheet once, but to maintain a live SOUP inventory with version pinning, vulnerability monitoring, and a documented evaluation for any SOUP on the hazard path.
Verification, integration testing, and unit verification
Clauses 5.5, 5.6, and 5.7 cover unit implementation and verification, integration and integration testing, and software system testing. The depth scales with class: Class C requires documented unit verification with acceptance criteria, documented integration test specifications, and full system testing against requirements; Class B drops the unit verification specification requirement; Class A drops most of it. The trap is the gap between 'we have unit tests in CI' and 'we have documented unit verification with acceptance criteria traceable to requirements'. CI pass-rates aren't enough — the file needs the specification, the result, and the trace.
Problem resolution: clause 9, the post-release lifecycle
Clause 9 requires a documented problem resolution process for any anomaly found in the software — internal, customer-reported, or SOUP — covering investigation, evaluation against the risk file, change implementation, verification of the change, and notification to affected parties where required. The clause is enforced more aggressively in 2026 than it was in 2018, because notified bodies have seen too many bug trackers running entirely outside the QMS with no link to risk reassessment or to the change-control system. A defensible 62304 implementation runs problems through the same routing as CAPA and connects them to the risk file.
A 60-day implementation path
Days 1 to 10: gap assessment against IEC 62304 for one product — software classification, plan, architecture documentation, SOUP inventory completeness, verification trace, problem resolution linkage. Days 11 to 25: rebuild the software file artefacts that are weakest, typically the SOUP inventory and the verification-to-requirement trace; reclassify items that are under-classified. Days 26 to 40: wire the problem resolution process into CAPA and the risk file; close the loop on the existing anomaly backlog. Days 41 to 60: roll the pattern to remaining products; run an internal audit focused on clauses 5.3, 5.7, and 9; freeze the baseline for the next external review.
Where this lives in V5 Ultimate
The clauses above aren't theoretical — every one maps to a shipped module and an industry profile. Jump to the parts of the product that turn this guide into evidence on a Monday morning.
Modules that do the work
Quality management
62304 software file inside the QMS, not bolted alongside it.
Document control
Software Development Plan and architecture as live controlled records.
Complaints & CAPA
Clause 9 problems routed through the same engine as everything else.
Compliance self-assessment
Score the software lifecycle against 62304 clauses on demand.
Industries this hits hardest
Frequently asked
Is IEC 62304 required by FDA?
FDA recognises IEC 62304:2006 with amendments and accepts it as a means of demonstrating compliance with the software portions of 21 CFR 820 and the premarket software guidance. It is not the only path, but it is the path almost every device manufacturer uses because it aligns with EU MDR, Health Canada, and MDSAP expectations simultaneously.
What's the difference between IEC 62304 and IEC 82304-1?
IEC 62304 covers the software lifecycle processes — how you build, verify, and maintain the software. IEC 82304-1 covers health software products as a whole, including the labelling, the IFU, and the product-level safety considerations, and applies to standalone health software (general wellness or medical) sold as a product. SaMD manufacturers typically apply both.
How does IEC 62304 interact with ISO 14971?
IEC 62304 explicitly references ISO 14971 as the source of the risk analysis that drives software safety classification. The two run as a coordinated pair: hazards from 14971 inform the class of each software item; software anomalies from clause 9 feed back into the 14971 risk file. Implementing one without the other is a finding waiting to happen.
Do AI/ML models count as SOUP?
Pre-trained models you did not develop for the device — including foundation models and third-party medical AI components — count as SOUP and must be inventoried, evaluated, and version-controlled accordingly. Models you trained in-house from your own data are not SOUP, but the training data, frameworks, and any pre-trained backbone you fine-tuned from are still in scope for the relevant 62304 controls.
See it on your shop floor.
Free trial, no credit card, onboard in days, not months.