IEC 62304 is the international standard for medical device software lifecycle processes — the framework that governs how regulated medical software is planned, designed, developed, tested, released, and maintained. Software is now at the core of most modern medical devices, from connected wearables to AI-driven diagnostics and fully autonomous treatment systems. As that software becomes more complex and more critical to patient outcomes, IEC 62304 provides the structured development process that demonstrates safety, supports regulatory submissions, and aligns with global compliance expectations.
For MedTech companies, this IEC is much more than a technical guideline. It’s the foundation for building safe, compliant, and scalable medical software. But like other international standards, its true value lies in how it is applied. When implemented effectively, IEC 62304 enables teams to move faster, reduce risk, and meet global regulatory expectations with confidence.
What Is IEC 62304?
IEC 62304, formally titled Medical device software – Software life cycle processes, is an international standard developed by the International Electrotechnical Commission (IEC). It defines the processes, activities, and tasks required for the safe design, development, and maintenance of medical device software.
Unlike broader quality standards, IEC 62304 focuses specifically on the software lifecycle. It applies to:
- Software as a Medical Device (SaMD)
- Software embedded within medical devices
- Software used in the development or operation of medical systems
At its core, this IEC establishes a structured framework that spans the entire software lifecycle, from initial planning and development through post-market maintenance and ongoing updates.
In today’s environment, where software is continuously evolving through updates, integrations, and AI model changes, this lifecycle approach is essential. IEC 62304 ensures that safety is not a one-time consideration, but an ongoing commitment.
Why IEC 62304 Matters for Modern MedTech
The role of IEC 62304 has grown significantly as medical software has become more sophisticated and interconnected. Today’s solutions often rely on cloud infrastructure, real-time data exchange, and machine learning algorithms. These advancements introduce new risks that must be managed systematically.
By implementing IEC 62304, organizations can:
- Establish consistent, repeatable development processes
- Ensure traceability across requirements, design, and testing
- Reduce the likelihood of software-related failures
- Align with global regulatory expectations
- Support faster and more predictable approvals
Regulatory bodies such as the FDA and European authorities recognize this IEC as a key standard for demonstrating software safety. For companies operating in multiple markets, aligning with IEC 62304 provides a clear pathway to global compliance.
How IEC 62304 Works: A Lifecycle Approach
One of the defining characteristics of IEC 62304 is its lifecycle-based structure. Rather than focusing solely on development, it addresses the full journey of medical software.
This includes planning, design, implementation, verification, release, maintenance, and problem resolution. Each stage is governed by defined processes and documentation requirements, ensuring that safety and quality are maintained throughout.
This lifecycle approach is particularly important for SaMD, where updates and new features are common. With this IEC, every change—no matter how small—must be assessed, documented, and validated within the broader system.
Safety Classifications
A central concept within IEC 62304 is software safety classification. This classification determines the level of rigor required in development and documentation based on the potential impact of software failure.
The three safety classifications established by IEC 62304 are as follows:
- Class A – No injury or damage to health is possible due to software failure (lowest risk)
- Class B – Injury is possible with software failure, but would not be serious
- Class C – Software failure could result in serious injury or death (highest risk)
The required development processes and documentation increase significantly from Class A to Class C.
Each IEC 62304 software safety class triggers a specific set of required documentation activities. The required activities scale from Class A (lightest documentation footprint, used for software where failure cannot harm patients) to Class C (most comprehensive documentation, required for software where failure could cause death or serious injury).
| Development activity | Class A | Class B | Class C |
|---|---|---|---|
| Development planning | Required | Required | Required |
| Requirements analysis | Required | Required | Required |
| Architectural design | Not required | Required | Required |
| Detailed design | Not required | Not required | Required |
| Unit implementation | Required | Required | Required |
| Unit verification | Not required | Required | Required |
| Integration and integration testing | Not required | Required | Required |
| System testing | Required | Required | Required |
| Release | Required | Required | Required |
Based on IEC 62304:2006/AMD1:2015. Activity requirements scale with software safety class.
The class drives the entire documentation effort. Higher classes require more thorough planning artifacts, more rigorous testing, and more granular architectural decomposition — meaning IEC 62304 classification has direct implications for project budget and timeline.
In many high-impact areas—such as diabetes management systems, drug delivery, and real-time monitoring—software is classified as Class C. This means IEC 62304 must be applied with the highest level of rigor, including extensive verification, validation, and traceability.
Lifecycle Safety Components
To support this lifecycle approach, IEC 62304 is structured into key sections that define specific responsibilities and processes.
While the standard includes foundational elements like scope and definitions, the core of IEC 62304 lies in its lifecycle components:
- Software Development: Covers planning, requirements, architecture, implementation, and testing
- Software Maintenance: Defines how updates, patches, and improvements are managed post-release
- Software Risk Management: Aligns with ISO 14971 to ensure risks are identified and controlled
- Software Configuration Management: Establishes control over code, versions, and environments
- Software Problem Resolution: Provides processes for identifying, tracking, and resolving issues
Together, these components ensure that software is not only built safely but also maintained safely over time.
IEC 62304 Classes vs IMDRF SaMD Classes — Two Different Schemes
IEC 62304’s three software safety classes (A, B, C) differ from the IMDRF’s four SaMD risk classes (I, II, III, IV) — a single SaMD product can be classified under both schemes. The IEC 62304 class is determined by the potential harm a software failure could cause; the IMDRF class is determined by the significance of the information the SaMD provides to a healthcare decision and the seriousness of the patient’s healthcare situation. A Class C software safety classification under IEC 62304 typically corresponds to a Class III or IV SaMD classification under IMDRF, but the two are determined independently.
SOUP: Third-Party and Pre-Existing Software Under IEC 62304
Almost no medical device software is written entirely from scratch. It relies on open-source libraries, commercial components, operating systems, and cloud SDKs, and IEC 62304 has a specific name for all of it: SOUP, software of unknown provenance.
IEC 62304 defines SOUP (clause 3.29) as a “software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as off-the-shelf software), or software previously developed for which adequate records of the development processes are not available.” In practice, if a team pulled a component in rather than building and documenting it themselves, it is almost certainly SOUP, and the standard treats it as a first-class safety concern rather than an implementation detail.
An SBOM is an inventory. SOUP handling is a lifecycle obligation. This is the distinction most teams miss. A software bill of materials lists the components in a product, and a modern team can auto-generate one from its dependency manager in seconds. But an inventory is not a control. IEC 62304 does not ask whether you can list your components; it asks whether you have identified each one, specified what it must do and what it needs to run, and set up a way to handle its defects. A dependency list answers none of those questions on its own.
Where SOUP lives in the standard
SOUP requirements are woven throughout the IEC 62304 life cycle rather than confined to a single section. They appear principally in the software development process (Clause 5), within the architectural design activity (5.3), where the standard requires the team to identify SOUP items and to specify what each one must do and what it needs to function. Handling of defects and changes across the product’s life connects to the software maintenance process (Clause 6) and the software problem resolution process (Clause 9). Throughout, the safety implications of SOUP are assessed under the standard’s software risk management process (Clause 7), which is embedded in the device risk management required by ISO 14971.
Concretely, for each SOUP item, the standard requires a set of activities that turn a third-party component from an untracked dependency into a managed, evaluated part of the software system:
- Identification. Each SOUP item is identified and designated as a known, tracked part of the software system, with its version recorded, so it is never an invisible dependency. Under the standard’s definitions, a version is an identified instance of a configuration item, which is why SOUP identification and configuration management (Clause 8) work together.
- Functional and performance requirements. The team specifies the functional and performance requirements the SOUP item must meet for the role it plays in the device, so its expected behavior is defined rather than assumed.
- System resource requirements. The team specifies the hardware and software resources the SOUP item needs to function correctly, so the item is not relied upon outside the conditions it can actually support.
- Evaluation and ongoing handling of anomalies. The standard defines an anomaly as any condition that deviates from expectations based on requirements, design, or standards. Known anomalies in a SOUP item are assessed for their impact on device safety, and newly discovered anomalies are handled through the maintenance and problem-resolution processes throughout the software’s supported life, not only at release.
SOUP obligations scale with safety class. IEC 62304 assigns a software safety class (A, B, or C) and states that compliance means implementing the processes, activities, and tasks in accordance with that class. For Class A software, where no injury is possible, SOUP obligations are light. At Class B and Class C, where a failure can cause injury or serious injury, they bite hardest, because a defect in a third-party component can compromise the whole device just as surely as a defect in code the team wrote itself. The more a device can hurt someone, the more rigorous the standard expects to be for every component it depends on, including those the team did not write.
For teams connecting SOUP handling to their risk management, IEC/TR 80002-1 is the technical report that maps the IEC 62304 software activities onto the ISO 14971 risk process, including for SOUP. It is the bridge between identifying a component and assessing what its failure would mean for the patient, and it is where the software life cycle and the risk management file meet.
The failure mode to avoid: a team that answers “GitHub tells us our dependencies” has an inventory, not a control. Knowing what is in the software is the starting point, not the obligation. The obligation is knowing what each component must do, what resources it needs, what is already known to be wrong with it, and how you will find out when something new goes wrong. That is the difference between a dependency list and SOUP management under IEC 62304, and it is one of the first things a serious review of a device’s software will look for.
Integrating IEC 62304 with Other Standards
IEC 62304 does not operate in isolation. It is most effective when implemented alongside other key standards, particularly:
These standards are deeply interconnected. For example, IEC 62304 defines how software should be developed, while ISO 14971 defines how risks within that software should be managed. ISO 13485 provides the overarching quality framework that ties everything together.
Successfully aligning these standards is one of the biggest challenges—and opportunities—for MedTech companies. When integrated correctly, they create a cohesive system that supports both innovation and compliance.
Applying IEC 62304 in Agile Development Environments
One of the most common questions organizations have is how to apply IEC 62304 within agile or iterative development models.
Traditionally, regulatory frameworks were designed around linear, waterfall processes. However, modern software development is far more dynamic. Teams release updates frequently, integrate new features continuously, and rely on rapid iteration.
The key to aligning agile with this IEC is not to abandon agility, but to structure it.
This includes:
- Maintaining traceability across iterations
- Embedding verification and validation into each sprint
- Ensuring documentation evolves alongside the product
- Managing changes through controlled processes
When implemented correctly, this IEC can actually enhance agile development by providing clarity, consistency, and risk control.
Common Challenges in IEC 62304 Implementation
Despite its importance, many organizations struggle to implement IEC 62304 effectively.
One common issue is underestimating the level of documentation required. IEC 62304 places a strong emphasis on traceability and evidence, which can be overwhelming without the right tools and processes.
Another challenge is aligning cross-functional teams. Software engineers, quality specialists, and regulatory experts must work closely together to meet the requirements of IEC 62304. Without strong communication, gaps can emerge.
Organizations also often struggle with change management. In a fast-moving development environment, ensuring that every update is properly assessed and documented in accordance with IEC 62304 can be difficult.
Finally, integrating this IEC with risk management processes and quality systems requires a level of expertise that many teams are still developing.
Best Practices for Success
To maximize the value of IEC 62304, organizations should focus on building a scalable, integrated approach.
This starts with implementing the standard early in the development process. Waiting until later stages can lead to significant rework and delays.
It also requires investing in tools that support traceability, version control, and documentation. Digital QMS platforms and automated testing frameworks can significantly reduce compliance burdens.
Equally important is fostering a culture of quality. IEC 62304 is not just a set of processes. It is a mindset that prioritizes safety, accountability, and continuous improvement.
The Strategic Value of IEC 62304
When implemented effectively, IEC 62304 becomes a strategic advantage.
It enables organizations to:
- Build safer, more reliable software
- Reduce development risk and uncertainty
- Accelerate regulatory approvals
- Scale products across global markets
In an industry where software performance directly impacts patient outcomes, these benefits are critical.
Frequently Asked Questions About IEC 62304
What is IEC 62304?
IEC 62304 is the international standard for the medical device software lifecycle. It defines the activities required for the safe planning, design, development, testing, release, and maintenance of medical device software. The standard, published by the International Electrotechnical Commission (IEC), is recognized by major regulators, including the FDA, and is harmonized as EN 62304 under the EU Medical Device Regulation (MDR).
What are the IEC 62304 software safety classes?
IEC 62304 defines three software safety classes based on the potential harm a software failure could cause. Class A: no injury or damage to health is possible from software failure. Class B: non-serious injury is possible from software failure. Class C: serious injury or death is possible from software failure. The class drives the depth of required documentation and the rigor of testing.
Does IEC 62304 apply to SaMD?
Yes. IEC 62304 applies to Software as a Medical Device (SaMD), software embedded within medical devices (SiMD), and software used in the development or operation of medical systems. The lifecycle processes defined by the standard apply to all three categories, with class-based scaling for documentation requirements.
How does IEC 62304 work with ISO 13485 and ISO 14971?
IEC 62304, ISO 13485, and ISO 14971 are designed to work together. ISO 13485 defines the overarching quality management system (QMS) under which medical device software is developed. ISO 14971 defines the risk management framework that runs in parallel with development. IEC 62304 defines the software lifecycle processes themselves. A typical SaMD development effort applies all three concurrently — and IEC 62304 explicitly references ISO 14971 for risk management.
Can IEC 62304 be implemented in Agile development?
Yes. IEC 62304 does not mandate a waterfall development approach — it specifies which activities must occur and which artifacts must exist, not the order or cadence of work. Agile teams successfully apply IEC 62304 by maintaining traceability across iterations, embedding verification and validation into each sprint, and treating regulatory artifacts (requirements, risk files, V&V records) as living documents updated each cycle.
When should IEC 62304 be implemented in a project?
IEC 62304 should be implemented from the start of project planning, not retrofitted later. The standard’s traceability and documentation requirements are difficult and costly to recreate after the fact. Teams that build to IEC 62304 from day one — typically within an ISO 13485-certified QMS — find that submission documentation comes together as engineering work progresses, rather than in a scramble at the time of submission.
Implement IEC 62304 With a Partner Who Knows the Path
IEC 62304 implementation requires deep expertise in both software development and medical device regulation. Sequenex builds medical device software in accordance with IEC 62304 within an ISO 13485-certified QMS every day. Our team applies the standard from initial project planning through post-market maintenance, with ISO 14971 risk management running in parallel and DHF-ready documentation produced as engineering work progresses—not assembled at submission.
Whether you’re implementing IEC 62304 for the first time or optimizing it for SaMD or connected medical devices, we can help.
