What Is IEC 62304? A Guide to Medical Device Software Compliance

Software is increasingly central to the clinical value of medical devices. It may control a physical device, process patient information, enable connectivity, support clinical decisions, or function independently as Software as a Medical Device (SaMD). As software assumes a greater role in medical technology, manufacturers need disciplined processes for managing it throughout its lifecycle.

IEC 62304 provides a framework for doing so.

The standard establishes software lifecycle processes for medical device software, connecting development and maintenance with risk management, quality, and regulatory expectations. Understanding IEC 62304 early can prevent a costly problem: reaching regulatory submission or audit readiness only to discover that critical lifecycle evidence is incomplete, inconsistent, or difficult to reconstruct.

What Is IEC 62304?

IEC 62304 is an international standard that defines lifecycle requirements for the development and maintenance of medical device software.

The standard applies to software that is itself a medical device or is an embedded or integral component of a medical device. FDA currently recognizes IEC 62304 Edition 1.1 as a consensus standard.

IEC 62304 establishes processes and tasks for managing software throughout its lifecycle. It does not prescribe a particular programming language, software architecture, development platform, or engineering methodology.

This distinction allows manufacturers to integrate IEC 62304 requirements into established development environments. The objective is a controlled, traceable process in which teams can demonstrate what was built, how associated risks were addressed, and how the software was verified.

Is IEC 62304 Required for Medical Device Software?

IEC 62304 is a consensus standard rather than a regulation. Its applicability should therefore be considered within the regulatory framework governing the specific product and market.

In the United States, FDA recognition makes IEC 62304 particularly relevant for medical device software manufacturers. Using a recognized consensus standard can provide a structured means of addressing applicable regulatory expectations, although manufacturers remain responsible for determining which requirements and standards apply to their products.

That analysis should consider:

• Intended use
• Device functionality
• Associated risks
• Regulatory classification
• Target markets
• Submission pathway

IEC 62304 is also widely relevant internationally. For manufacturers pursuing commercialization across multiple jurisdictions, establishing a software lifecycle that aligns with the standard can support a broader regulatory strategy.

How Does IEC 62304 Fit with Other Medical Device Standards and Regulations?

IEC 62304 does not operate in isolation. Medical device software exists within a larger quality and regulatory framework.

ISO 13485 establishes quality management system requirements for medical device organizations, while ISO 14971 provides a framework for medical device risk management. IEC 62366-1 may also apply where usability engineering is relevant.

In the United States, FDA's Quality Management System Regulation (QMSR), effective February 2, 2026, incorporates ISO 13485:2016 by reference into 21 CFR Part 820. Manufacturers may also need to consider FDA guidance covering premarket documentation for device software functions and cybersecurity requirements for applicable devices.

These frameworks intersect throughout development. For example, a risk control identified through risk management may generate a software requirement, which then drives implementation and verification. Effective compliance depends on maintaining these relationships rather than treating each standard as a separate documentation exercise.

What Are the IEC 62304 Software Safety Classes?

Software safety classification is a central concept within IEC 62304 because classification affects which lifecycle requirements apply.

The standard establishes three software safety classes:

• Class A: No injury or damage to health is possible.
• Class B: Non-serious injury is possible.
• Class C: Death or serious injury is possible.

Classification requires an analysis of the potential consequences associated with software failure and applicable risk controls. It should not simply be assumed from the regulatory classification of the overall medical device.

An incorrect classification can have significant consequences. Under-classification may result in insufficient lifecycle controls, while unnecessarily conservative classification can add development burden without a corresponding benefit.

Manufacturers should therefore establish and document a defensible classification rationale and reassess relevant assumptions when software architecture, intended use, or risk controls change.

What Processes Does IEC 62304 Require?

IEC 62304 organizes software lifecycle expectations around several key processes extending from initial development through postmarket maintenance.

Software Development Process

The software development process translates product needs into controlled, verified software. It encompasses development planning, requirements analysis, architecture and design, software implementation, integration, testing, and release.

Software requirements should be sufficiently clear and testable to support subsequent development and verification. Architecture and design then translate those requirements into a technical solution before software units are implemented, integrated, and tested.

Traceability is fundamental. Requirements, risk controls, design elements, implementation, and verification evidence should form a coherent chain demonstrating that the released software is the controlled implementation of defined requirements.

Software Maintenance Process

IEC 62304 does not treat product release as the end of the software lifecycle.

Medical device software may require updates because of defects, cybersecurity vulnerabilities, changing dependencies, performance improvements, or new functionality. Manufacturers need controlled processes for evaluating feedback, analyzing proposed modifications, implementing changes, and verifying revised software.

Even a limited change can affect requirements, architecture, risk controls, cybersecurity, or previous verification evidence. These downstream consequences should be evaluated as part of maintenance.

Software Risk Management Process

Software risk management closely connects IEC 62304 with ISO 14971.

Teams need to consider how software can contribute to hazardous situations, identify relevant causes, establish appropriate controls, and verify software-based risk control measures. These relationships should remain traceable. If a software requirement implements a risk control, the organization should be able to connect that control with the requirement, implementation, and verification evidence.

Risk management should also evolve with the product. Design changes, new functionality, anomalies, cybersecurity findings, and postmarket information can alter the risk profile and require reassessment.

Software Configuration Management Process

Configuration management enables manufacturers to establish precisely what software was developed, tested, and released.

Modern medical device software may combine proprietary code with open-source libraries, commercial components, operating systems, firmware, and other dependencies. Relevant configuration items and versions should be identified and controlled, with changes appropriately managed. This discipline supports reproducibility and traceability while helping organizations determine which product versions may be affected when defects or cybersecurity vulnerabilities emerge.

Software Problem Resolution Process

IEC 62304 also establishes a systematic process for addressing software problems.

Organizations need mechanisms for documenting and investigating problems, evaluating their significance, determining corrective action, and verifying implemented resolutions. Teams should consider not only whether a defect creates an obvious malfunction but also whether it could contribute to a hazardous situation or undermine an established risk control.

Problem resolution may also interact with complaint handling, CAPA, postmarket surveillance, and cybersecurity processes within the broader quality system.

What Documentation Does IEC 62304 Require?

IEC 62304 implementation produces a body of lifecycle evidence rather than a single compliance document.

Depending on the product, software safety classification, and applicable requirements, documentation may include:

• Software development plans
• Software requirements
• Architecture and design documentation
• Software safety classification rationale
• Risk management records
• Verification and testing evidence
• Traceability records
• Configuration management records
• Problem reports
• Software release records
• Maintenance documentation

The quality and consistency of these records matter as much as their existence.

Documentation should reflect how the software was actually developed. Requirements, architecture, risks, tests, known anomalies, and released configurations should describe the same product. Creating polished documentation shortly before an audit or submission provides limited value if it conflicts with the underlying engineering evidence.

How Does IEC 62304 Address SOUP and Third-Party Software?

Modern medical device software rarely consists exclusively of internally developed code. IEC 62304 uses the concept of Software of Unknown Provenance, or SOUP. Depending on the circumstances, this may encompass commercial libraries, open-source components, operating systems, and other externally developed software.

Manufacturers need appropriate visibility into relevant components, their role within the system, and known anomalies that may affect the device.

SOUP management has become increasingly important as software supply chains grow more complex. A defect or vulnerability in a third-party component can affect a medical device even when proprietary code remains unchanged.

This area also intersects with cybersecurity practices such as maintaining a Software Bill of Materials (SBOM). Although related, SOUP documentation and an SBOM serve distinct purposes and should not automatically be treated as interchangeable.

How Does IEC 62304 Apply to Agile Software Development?

IEC 62304 does not require a traditional waterfall development model. Organizations can use Agile and other iterative methodologies as long as their processes satisfy applicable lifecycle requirements.

For Agile teams, the challenge is often maintaining regulatory evidence as the product evolves. Requirements may change across iterations, architecture may be refined incrementally, and testing may occur continuously.

Teams must ensure this pace does not compromise traceability, risk management, configuration control, design documentation, or verification.

Well-designed processes can integrate lifecycle evidence into established engineering workflows, allowing compliance activities to progress alongside development instead of becoming a separate exercise immediately before submission.

What Are Common IEC 62304 Compliance Gaps?

One of the most significant IEC 62304 challenges arises when organizations consider the standard too late. A technically mature product may reach regulatory preparation with substantial engineering evidence but lack the structure necessary to demonstrate compliance efficiently.

Common gaps include:

• Incomplete or untestable software requirements
• Unsupported software safety classifications
• Missing requirements-to-test traceability
• Risk management disconnected from software development
• Architecture documentation that no longer reflects the implemented system
• Inadequate SOUP documentation
• Weak configuration management
• Inconsistent records across software versions
• Poorly documented anomalies or unresolved defects
• Cybersecurity addressed too late in development

These gaps can require significant remediation. Teams may need to reconstruct design rationale, reconcile conflicting documents, reassess risks, repeat testing, or generate missing evidence before a regulatory submission can proceed confidently.

How Can Organizations Implement IEC 62304 Without Creating Unnecessary Overhead?

Effective IEC 62304 implementation should strengthen development control without creating unnecessary process.

Organizations can begin with an applicability and gap assessment to understand how existing workflows align with the standard. Mature software teams may already perform many relevant activities but use different terminology or lack the evidence needed to demonstrate alignment.

Rather than automatically replacing established systems, teams can map applicable IEC 62304 requirements to existing processes and focus remediation on genuine gaps.

Software safety classification should be established early, risk management should remain integrated with development, and traceability should be maintained as the product evolves. Periodic reviews can identify inconsistencies while they remain manageable rather than requiring teams to reconcile years of development records immediately before submission.

Ultimately, the compliance framework should be proportionate to the product's complexity and risk while still producing clear, defensible evidence.

How Can Quality Commercial Consultants Support IEC 62304 Compliance?

Organizations developing SaMD, connected devices, AI/ML-enabled products, and other software-intensive medical technologies often possess sophisticated engineering capabilities. The challenge is ensuring their processes and technical evidence align with regulatory expectations.

Quality Commercial Consultants (QCC) helps medical device and health technology organizations identify those gaps and establish practical paths toward regulatory readiness.

QCC can evaluate existing software lifecycle processes and technical artifacts to determine where they align with applicable requirements and where remediation may be necessary. Support can include software lifecycle and documentation reviews, regulatory gap assessments, QMS compliance planning, risk management alignment, traceability reviews, cybersecurity documentation, AI/ML compliance support, and regulatory submission preparation.

For organizations approaching an FDA submission, QCC can also help translate complex engineering evidence into organized regulatory documentation. This may involve identifying missing evidence, mapping existing documentation to submission expectations, resolving inconsistencies, and supporting responses to FDA Additional Information requests.

The objective is not to impose unnecessary infrastructure on organizations with effective engineering systems. QCC works with existing processes and artifacts to help teams focus resources on substantive compliance gaps and build the regulatory evidence necessary to support their path to market.

Build IEC 62304 Compliance into the Software Lifecycle

IEC 62304 provides medical device manufacturers with a disciplined framework for controlling software from initial development through postmarket maintenance. Its requirements connect planning, requirements, architecture, implementation, testing, risk management, configuration management, and problem resolution.

Successful implementation requires more than assembling the expected documents. The strongest compliance framework is integrated into the way software is actually developed.

When engineering, quality, risk management, cybersecurity, and regulatory activities remain aligned throughout the lifecycle, organizations are better positioned to identify gaps early, manage changes effectively, and present coherent evidence during regulatory review.

For manufacturers developing SaMD and other software-enabled medical devices, Quality Commercial Consultants can help assess existing processes, identify IEC 62304 compliance gaps, and translate technical evidence into a defensible regulatory framework. Addressing that alignment before submission can reduce remediation and support a clearer path toward regulatory readiness.