Getting Started with IEC 62304: A Practical Guide for Software Teams

IEC 62304:2006+AMD1:2015 (Medical device software -- Software life cycle processes) is the internationally recognised standard governing the development and maintenance of software used in medical devices or as a medical device. Whether you are building firmware for an implantable device, a diagnostic imaging application, or a standalone software as a medical device (SaMD), IEC 62304 provides the framework that regulators and Notified Bodies expect you to follow. For software teams coming from a general technology background, the standard can initially seem bureaucratic, but understanding its intent and structure transforms it from a compliance burden into a practical engineering discipline.

At its core, IEC 62304 is a process standard, not a product standard. It does not tell you what your software must do or how it must perform. Instead, it specifies the processes you must follow during software development, maintenance, risk management, configuration management, and problem resolution. The standard is structured around a software development lifecycle that encompasses planning, requirements analysis, architectural design, detailed design, implementation, integration and integration testing, system testing, and release. Each phase has defined activities and outputs, but the standard is deliberately lifecycle-model-agnostic. You can implement IEC 62304 with a waterfall, V-model, agile, or hybrid approach, provided you can demonstrate that the required activities and documentation are addressed.

The single most important concept in IEC 62304 is software safety classification. The standard defines three safety classes: Class A (no injury or damage to health is possible), Class B (non-serious injury is possible), and Class C (death or serious injury is possible). The safety classification applies to software systems and software items, and it directly determines the rigour of documentation and process requirements. Class A software requires the least documentation, with requirements for software development planning, requirements analysis, and testing, but without mandating detailed architectural or unit-level documentation. Class B adds requirements for software architecture documentation and verification of software architecture. Class C applies the full set of requirements, including detailed design documentation and unit-level testing. Correct classification is therefore critical: over-classification wastes resources, while under-classification exposes you to regulatory risk.

Determining the correct safety class requires a risk-based approach that considers the software's contribution to hazardous situations. This analysis must be performed in conjunction with the overall device risk management process governed by ISO 14971. A key principle is that hardware risk controls can reduce the software safety classification. For example, if a software failure could theoretically cause serious injury but an independent hardware safety mechanism prevents the hazardous situation from occurring, the software item may be classified as Class B rather than Class C. This interplay between software classification and system-level risk management is often poorly understood, leading either to unnecessary over-classification or to inadequately justified classification reductions.

Software development planning is the foundation upon which IEC 62304 compliance is built. The software development plan must address the processes, tools, methods, and standards that will be used throughout the lifecycle. It must define the deliverables for each phase, the criteria for transitioning between phases, and the configuration management and change control procedures. For teams using agile methodologies, the development plan should describe how iterative development maps to IEC 62304 activities. This is not about abandoning agility, but about making the mapping explicit. Many successful medical device software teams operate with two-week sprints while maintaining full IEC 62304 compliance by integrating documentation activities into their sprint workflows.

Requirements management under IEC 62304 demands traceability from software requirements through architecture, detailed design, and test cases. Each software requirement should be traceable to a system requirement and ultimately to the risk analysis. This bidirectional traceability matrix is one of the most scrutinised artefacts during Notified Body audits and FDA software reviews. Common pitfalls include requirements that are too vague to be testable, missing traceability links, and requirements that do not adequately address safety-related functionality. We recommend establishing your requirements management tooling and traceability conventions early, as retrofitting traceability into an existing codebase is significantly more expensive than building it in from the start.

The standard requires verification at multiple levels: unit testing, integration testing, and system testing. For Class C software, unit-level testing is explicitly required, and the tests must demonstrate that the software items meet their detailed design specifications. For Class B software, integration testing against the software architecture is required. All classes require system testing against the software requirements. A common mistake is to conflate testing with verification. IEC 62304 is clear that verification encompasses not only testing but also code reviews, static analysis, and other techniques appropriate to the risk level. Many organisations find that a combination of automated unit tests, static analysis tools, peer code reviews, and formal system-level testing provides robust coverage while remaining practical to maintain.

Configuration management and problem resolution are supporting processes that underpin the entire lifecycle. Configuration management must ensure that software items, their versions, and their relationships are identified and controlled. This extends to SOUP (Software of Unknown Provenance), which encompasses all third-party libraries, open-source components, and operating systems used in the device. For each SOUP item, you must document the title, manufacturer, version, and any known anomalies that could affect the safety or performance of your device. With modern software relying on dozens or even hundreds of open-source dependencies, SOUP management requires systematic tooling and ongoing monitoring for newly disclosed vulnerabilities.

The relationship between IEC 62304 and cybersecurity standards deserves particular attention. While IEC 62304 addresses software lifecycle processes, it does not comprehensively address cybersecurity. IEC 81001-5-1 (Health software and health IT systems safety, effectiveness and security) is emerging as the key standard for cybersecurity in medical device software, and it is designed to work alongside IEC 62304. Additionally, IEC 62443 (Industrial communication networks -- Network and system security) is relevant for networked medical devices. Regulators increasingly expect manufacturers to demonstrate a systematic approach to cybersecurity that covers threat modelling, secure design principles, vulnerability management, and security update procedures. Integrating cybersecurity activities into your IEC 62304 lifecycle from the outset is far more efficient than bolting them on as an afterthought.

For software teams beginning their IEC 62304 journey, we recommend the following approach: Start by establishing your software safety classification with a documented rationale linked to your risk management file. Next, create a software development plan that honestly describes your actual processes rather than aspiring to processes you do not follow. Build traceability into your toolchain from day one, whether through dedicated ALM tools, or through disciplined use of requirements management in your issue tracker. Adopt a SOUP management process that includes a registry of all third-party components and a procedure for monitoring and evaluating security advisories. Finally, remember that IEC 62304 compliance is not a one-time achievement but an ongoing discipline. Your processes must be maintained, your documentation must be kept current, and your team must be trained on the requirements. When implemented thoughtfully, IEC 62304 strengthens your development process, reduces defects, and builds the evidence base that regulators need to grant market access.