IEC 62304 Software Lifecycle: A Practical Guide for Medical Device Developers

Why IEC 62304 Exists

IEC 62304:2006 (amended 2015) is the internationally recognized standard for medical device software lifecycle processes. It was developed because generic software development standards — even rigorous ones like DO-178C used in aviation — do not address the specific risk context of software embedded in or operating as a medical device.

The standard is harmonized with EU MDR and is referenced by FDA as an acceptable means of demonstrating that software development practices meet the expectations in FDA's guidance on software validation and design controls. For any manufacturer developing software as part of a medical device, IEC 62304 is effectively mandatory — not following it will generate questions during FDA reviews and Notified Body audits that are difficult to answer without demonstrating an equivalent level of rigor.

IEC 62304 applies to software that is part of a finished medical device, software that is itself a medical device (SaMD), and the development and maintenance of that software throughout its lifecycle. It is intentionally process-focused: it defines what must be done and documented, not how to write code. This means IEC 62304 can be implemented alongside any engineering methodology — agile, waterfall, or hybrid — as long as the required processes and documentation are in place.

Software Safety Classes: A, B, and C

The foundation of IEC 62304 is the software safety class system, which determines how rigorous your development lifecycle must be. The class is assigned based on the severity of harm that could result from a software failure, not from the probability of failure.

Class A: No injury or damage to health is possible from a software failure. The software may contribute to device malfunction, but that malfunction cannot injure the user or patient. Class A software has the lightest documentation and process requirements under IEC 62304.

Class B: Non-serious injury is possible from a software failure. The device could malfunction in a way that causes physical harm, but death or serious injury are not plausible consequences. Class B requirements are substantially more demanding — software architecture, unit verification, and integration testing requirements apply.

Class C: Death or serious injury is possible from a software failure. This includes any software controlling dosing of therapy, surgical device actuation, or life-sustaining device function. Class C requirements add mandatory code reviews, full traceability from requirements through testing, and rigorous configuration management.

Assigning the wrong software safety class — typically by assigning Class A or B when Class C is appropriate — is one of the most consequential errors in medical device software development. Regulators will challenge your safety class assignment. Your risk management records must support the classification, and the software architecture documentation must reflect it.

Required Software Lifecycle Processes

IEC 62304 Section 5 through Section 9 defines the required processes across the software lifecycle. For Class B and C software, all of these processes apply in full. Class A software has relaxed requirements for some processes.

Software development planning (Section 5.1): You must establish and maintain a software development plan that defines the processes, deliverables, and standards you will follow. This is not a project plan — it is a document that explains how your development process satisfies IEC 62304 requirements. FDA reviewers will ask for this.

Software requirements analysis (Section 5.2): Software requirements must be documented, reviewed, and approved. Requirements must address functional performance, inputs and outputs, user interfaces, external interfaces, safety requirements derived from your risk management process, and software-specific risk controls. Each requirement must be uniquely identified to support traceability.

Software architecture design (Section 5.3): Required for Class B and C software. The architecture must identify software items (modules or units), define their interfaces, and demonstrate that the architecture supports the safety requirements. For Class C software, the architecture must also identify software items that implement risk controls.

Software detailed design (Section 5.4): Required for Class C software. Detailed design documentation must be maintained for each software item.

Software unit implementation and verification (Section 5.5): Code must be implemented against the detailed design. Verification (testing, reviews, or analysis) at the unit level is required for Class B and C.

Software integration and integration testing (Section 5.6): Software items must be integrated following a defined plan, and integration testing must confirm that the items work together as specified.

Software system testing (Section 5.7): System-level testing against software requirements must be documented with traceable test cases, procedures, and results.

Software Configuration Management and Problem Resolution

IEC 62304 Section 8 (Software Configuration Management) and Section 9 (Software Problem Resolution Process) are often under-implemented, and they are where Notified Body auditors and FDA investigators spend significant time during software reviews.

Configuration management requires that software items be uniquely identified and controlled such that you can reproduce any previously released version of your software. This means version control is mandatory — but version control alone is not sufficient. Your configuration management system must also control build artifacts, third-party libraries and their versions, software tools used in development (compilers, testing frameworks, code analyzers), and released software packages.

The ability to reproduce a historical build is particularly important for post-market surveillance. If a software-related adverse event occurs in the field, your investigation may require running the specific version of software that was in the affected device. If you cannot reproduce that build, your investigation is compromised.

Problem resolution requires a documented process for identifying, analyzing, and resolving software anomalies found during development or after release. Every software defect that could affect safety or performance must be evaluated against your risk management records. If a defect is identified in released software, you must determine whether it constitutes a reportable incident under FDA or MDR requirements.

Software change control — any modification to released software — must follow both your IEC 62304 change management process and your design change control procedure. Changes to Class C software require particularly rigorous re-verification and regression testing.

What FDA Expects in a Software Description Document

For FDA submissions (510(k), De Novo, PMA), FDA expects a Software Description document that summarizes your software's development practices and lifecycle documentation. FDA's guidance document "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices" (2005, currently under revision) defines the expected content based on your device's Level of Concern — which maps to IEC 62304 safety classes.

For a Major Level of Concern device (analogous to Class C software), FDA expects a Software Description Document that includes your software development lifecycle description, risk analysis specific to software, anomaly list, and software testing documentation including unit test reports, integration test reports, and system test reports. Your SDS should demonstrate that your processes satisfy IEC 62304.

For a Moderate Level of Concern (analogous to Class B), FDA expects a condensed Software Description Document without detailed test protocol submission, but traceability and testing summaries are still expected.

FDA reviewers are not looking for perfect software with zero defects. They are looking for a demonstrably rigorous process and evidence that you have identified and managed software-related risks. A well-documented development process with appropriate risk controls will satisfy FDA even if the software has known, managed anomalies.