Software Lifecycle (IEC 62304) is the international standard that defines the processes, activities, and tasks for developing and maintaining medical device software. It sets requirements for planning, requirements analysis, architecture, implementation, integration, testing, release, and maintenance, scaling the rigor to a software safety classification of Class A, B, or C based on possible patient harm.
What is Software Lifecycle (IEC 62304)?
IEC 62304 is a process standard, not a product standard. It does not tell teams what their software must do or which development method to use; it specifies the lifecycle activities and records a manufacturer must produce to show that medical device software was built and maintained under control. It applies whether the software is itself a medical device, often called SaMD (software as a medical device), or is embedded in a larger device such as an infusion pump or patient monitor.
The current version is IEC 62304:2006 with Amendment 1:2015. The FDA recognizes it as a consensus standard, and Europe accepts it as EN 62304 to support conformity with the EU Medical Device Regulation (MDR 2017/745). A second edition is in development but not yet published, so the 2006 text with its 2015 amendment remains the basis for compliance.
Why Software Lifecycle (IEC 62304) matters in medical device development
A software defect in a regulated device can cause a wrong dose, a missed alarm, or a failed therapy. IEC 62304 is the framework that notified bodies, FDA investigators, and MDSAP auditors expect when they assess how a manufacturer controls software risk.
The consequences of skipping it are concrete. Missing lifecycle records are a frequent design control audit finding and can hold up a 510(k) clearance or CE marking, and reworking documentation after a failed audit costs more than producing it during development. Because IEC 62304 ties directly to risk management under ISO 14971, a gap in the software lifecycle usually signals a gap in the device risk file.
How the Software Lifecycle (IEC 62304) works
The standard rests on three structural ideas. A software system is the full set of items that meet the user’s needs. A software item is any identifiable part of that system, such as a module. A software unit is the smallest part you test on its own. This breakdown lets teams focus effort where it most affects safety.
Each software item is assigned a safety class:
- Class A: No injury is possible.
- Class B: non-serious injury is possible.
- Class C: death or serious injury is possible.
The class drives how much documentation, design detail, and verification each item needs. When classification is not clearly justified, teams default to the stricter class.
Clause 5 defines the development process as activity areas that scale with the safety class:
- Software development planning.
- Requirements analysis.
- Architectural design.
- Detailed design (Class B and C).
- Unit implementation and verification.
- Integration and integration testing.
- System testing.
- Software release.
Supporting processes run in parallel:
- Clause 6: Maintenance.
- Clause 7: Software risk management with ISO 14971.
- Clause 8: Configuration management and change control.
- Clause 9: Problem resolution.
A recurring theme is SOUP, software of unknown provenance: any item not developed for this device, such as operating systems and open-source libraries. IEC 62304 requires you to identify each SOUP item, specify its requirements, and assess its failures for safety impact. Cybersecurity runs in a parallel lifecycle under IEC 81001-5-1, which most teams handle as one effort.
Common challenges and best practices
The most common mistake is treating documentation as a write-up done after coding. IEC 62304 expects records to be planned and produced as work happens, so retrofitting them rarely survives an audit. Underestimating the safety class is a second frequent problem, leaving teams short of the evidence reviewers ask for.
SOUP is often handled too late; cataloging libraries and their known anomalies early avoids painful rework. Good teams keep a live traceability matrix linking requirements to architecture, risk controls, and verification results, and integrate the IEC 62304 plan with their ISO 13485 design and development procedures. Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, Part 820 incorporates ISO 13485:2016 by reference, so software design controls now sit within that quality framework.
How SJML helps with Software Lifecycle (IEC 62304)
SJML supports software as a medical device and software-driven products as part of its Compliance-as-a-Service offering. The team helps structure the IEC 62304 lifecycle, from the software development plan and safety classification through requirements, architecture, verification, and maintenance, and aligns it with ISO 14971 risk management and ISO 13485 design controls. SJML also supports cybersecurity risk activities under IEC 81001-5-1 and EU AI Act readiness for qualifying products, so safety and security evidence are built together rather than before a submission.
Frequently asked questions
ISO 13485 is the quality management system standard for the whole device organization, while IEC 62304 governs the lifecycle of the software itself. ISO 13485 sets the design control framework, and IEC 62304 details the software planning, development, and maintenance activities that satisfy those controls. Teams run them together, with IEC 62304 records feeding the design history file.
IEC 62304 defines three safety classes based on the harm a software failure could cause.
Class A applies when no injury is possible.
Class B applies when non-serious injury is possible.
Class C applies when death or serious injury is possible.
The class is assigned per software item and determines how much design detail, documentation, and verification each item requires.
The FDA does not legally mandate IEC 62304, but it recognizes the standard as a consensus standard and accepts conformity as evidence of a controlled software process in premarket submissions. In practice, following IEC 62304 streamlines 510(k) and PMA reviews because it produces the planning, traceability, and verification records that reviewers expect for medical device software.
SOUP stands for software of unknown provenance: any software item not developed for the current device or lacking adequate development records. Operating systems, open-source libraries, and third-party drivers all count. IEC 62304 requires you to identify each SOUP item, document its functional and performance requirements, and evaluate how its potential failures could affect device safety.
Related terms
- IEC 62366-1 (Usability Engineering)
- ISO 14971 (Risk Management)
- IEC 81001-5-1 (Health Software Cybersecurity)
- Software as a Medical Device (SaMD)
- Design Verification
