IEC 62304: Medical Device Software Compliance Guide

If you build software that runs inside, connects to, or functions as a medical device, IEC 62304 applies to you. The standard defines the lifecycle processes required for developing and maintaining medical device software, and regulatory bodies worldwide — the FDA, EU notified bodies, Health Canada, and TGA — expect compliance as part of market clearance.

This guide covers the standard itself, the 2015 amendment, software safety classification, the required lifecycle activities, how IEC 62304 relates to SaMD and FDA guidance, and a practical checklist you can use to assess your compliance posture.

What Is IEC 62304?

IEC 62304, formally titled Medical device software — Software life cycle processes, is an international standard published by the International Electrotechnical Commission (IEC). (It is distributed jointly through the ISO/IEC catalogs but, unlike ISO/IEC 27001, it is not a jointly-developed ISO/IEC standard.) It defines the minimum lifecycle activities required for the development and maintenance of medical device software.

The standard does not prescribe a specific development methodology. You can use waterfall, agile, or hybrid approaches, as long as you satisfy the process requirements at each stage. What IEC 62304 does prescribe is traceability, documentation, and risk management integration at every lifecycle phase.

IEC 62304 applies to:

• Embedded device software — firmware running on pacemakers, infusion pumps, imaging equipment, patient monitors
• Standalone medical software — Software as a Medical Device (SaMD) such as clinical decision support tools, diagnostic algorithms, and remote monitoring platforms
• Software components within a medical device system — integration middleware, device gateway software, and data acquisition modules

The standard does not apply to software used in the manufacturing process (unless that software is itself a medical device) or to general-purpose IT infrastructure, unless that infrastructure directly contributes to the safety or effectiveness of a medical device.

IEC 62304 Latest Version: 2015 Amendment 1

The original IEC 62304 was published in 2006. Amendment 1, published in 2015 (IEC 62304:2006/AMD1:2015), introduced several significant changes:

Legacy software provisions. The amendment added guidance for bringing existing software that was developed outside of IEC 62304 into compliance. This is particularly relevant for organizations that have mature software products predating the standard.

Clarified SOUP requirements. SOUP (Software of Unknown Provenance) — third-party libraries, open-source components, operating systems — received expanded treatment. The amendment clarified that SOUP items must be identified, their anomalies tracked, and their risk contributions assessed.

Software safety classification refinement. The amendment clarified that software safety classification applies at the software system level and can be refined at the software item level. This means a Class C system can contain Class A and Class B items, reducing documentation burden on lower-risk components.

Expanded configuration management. The amendment strengthened requirements around configuration management, including change control for both the software and its development environment.

The current edition to reference in your quality management system is IEC 62304:2006+AMD1:2015 (also published as the consolidated edition IEC 62304:2006+AMD1:2015 CSV).

Software Safety Classification: Class A, B, and C

IEC 62304 classifies medical device software into three safety classes based on the potential for harm. The classification determines how rigorous your lifecycle processes must be.

How to Determine Your Safety Class

Safety classification is not a standalone decision. It is derived from the risk management process defined in ISO 14971 (Application of risk management to medical devices). The workflow is:

1. Identify intended use and intended use environment for the software system.
2. Identify hazards that the software could contribute to, using the risk analysis process from ISO 14971.
3. Evaluate the severity of harm from each identified hazard.
4. Determine whether external risk control measures (hardware interlocks, user verification steps, redundant systems) exist that would prevent the software from contributing to the hazardous situation.
5. Assign the highest applicable class based on residual risk after considering external controls.

A common mistake is to classify software as Class A by assuming that external controls will catch every failure. Auditors will challenge this assumption aggressively. If your argument for Class A depends on a user noticing and correcting a software error, you need evidence that the user can reliably do so under realistic clinical conditions.

Classification at the Software Item Level

The 2015 amendment allows decomposition of the safety class at the software item level. A Class C software system might contain:

• Class C items — the dosage calculation module in an infusion pump
• Class B items — the user interface rendering engine
• Class A items — the logging subsystem (assuming it does not affect safety-critical data)

This decomposition must be justified through the risk management process. The boundaries between items of different classes must be clearly defined in the software architecture, with appropriate segregation (e.g., separate processes, memory isolation, or defined interfaces that prevent lower-class items from corrupting higher-class ones).

Software Development Lifecycle Requirements

IEC 62304 defines lifecycle processes across seven areas. The depth of each activity scales with the software safety class.

1. Software Development Planning

Every IEC 62304 project begins with a software development plan. This plan defines:

• The software development lifecycle model (waterfall, iterative, agile)
• Deliverables for each lifecycle phase
• Traceability between requirements, design, implementation, and testing
• Configuration management and change control procedures
• Tools to be used (compilers, IDEs, static analyzers, CI/CD systems) and their qualification requirements
• Risk management integration points
• Standards and coding guidelines to be followed

Applies to: Class A, B, and C

For agile teams, the software development plan can reference sprint-level artifacts (user stories, acceptance criteria, sprint reviews) as the mechanism for satisfying lifecycle requirements. The key is that you must be able to demonstrate, at any point, which requirements have been implemented, verified, and released.

2. Software Requirements Analysis

Requirements must be documented and traceable. IEC 62304 expects:

• Functional requirements derived from the device’s intended use
• Performance requirements (response times, throughput, availability)
• Interface requirements (APIs, communication protocols, data formats)
• Security requirements (authentication, encryption, access control) — increasingly important given FDA cybersecurity expectations under Section 524B; for cloud-connected SaMD, these requirements also need to satisfy HIPAA compliance safeguards
• Risk control requirements from ISO 14971 — these are specific requirements that implement risk mitigations

Applies to: Class A, B, and C

Each requirement must be uniquely identifiable and traceable forward to design, implementation, and test cases.

3. Software Architecture Design

The architecture must describe:

• Software items and their interfaces
• Separation of safety-critical and non-safety-critical components
• How the software handles faults and failures (degraded modes, error handling)
• SOUP items and their integration points
• Data flows, especially where patient data or safety-critical signals traverse component boundaries

Applies to: Class B and C

For Class C software, the architecture document is a critical audit artifact. It must demonstrate that the architecture supports the safety claims made in the risk management file.

4. Software Detailed Design

Detailed design bridges architecture and implementation. It defines:

• Algorithms and data structures for each software unit
• Interface specifications for unit-to-unit communication
• State machines and control flow for safety-critical behavior
• Database schemas and data integrity mechanisms

Applies to: Class C only (though recommended for Class B)

In practice, many teams satisfy detailed design requirements through well-documented code (clear naming, comprehensive docstrings, design decision comments) combined with targeted design documents for complex algorithms.

5. Software Unit Implementation and Verification

Implementation must follow the coding standards defined in the software development plan. Unit verification includes:

• Code review — peer review of safety-critical code
• Static analysis — automated checks for common defects (null pointer dereferences, buffer overflows, resource leaks)
• Unit testing — verification that individual units meet their design specifications

Applies to:

• Class A: Implementation only (no formal unit verification required)
• Class B: Implementation and verification
• Class C: Implementation, verification, and documented acceptance criteria for each unit

A typical CI/CD pipeline for IEC 62304 compliance runs static analysis and unit tests on every commit, with results traceable to specific software items:

# Example: CI pipeline for IEC 62304 verification
stages:
  - static-analysis
  - unit-test
  - integration-test
  - system-test

static-analysis:
  stage: static-analysis
  script:
    - cppcheck --enable=all --xml --xml-version=2 src/ 2> cppcheck-report.xml
    - clang-tidy src/**/*.cpp -checks=cert-*,bugprone-*,security-*
  artifacts:
    paths:
      - cppcheck-report.xml
    expire_in: 7 years  # Retain for device lifecycle + regulatory hold

unit-test:
  stage: unit-test
  script:
    - cmake --build build --target run_tests
    - gcovr --xml-pretty -o coverage.xml build/
  artifacts:
    paths:
      - build/test-results.xml
      - coverage.xml
    expire_in: 7 years

6. Software Integration and Integration Testing

Integration testing verifies that software items work correctly when combined. Requirements include:

• Integration test plans that define the order and method of integration
• Test cases that exercise interfaces between software items
• Regression testing when components are modified
• Verification of SOUP item integration

Applies to: Class B and C

7. Software System Testing

System testing verifies the complete software system against the software requirements specification. This includes:

• Functional testing of all requirements
• Performance testing under expected and boundary conditions
• Security testing (penetration testing, fuzz testing, vulnerability scanning)
• Usability testing where applicable
• Testing in the intended deployment configuration

Applies to: Class A, B, and C (scope varies by class)

Software Maintenance

IEC 62304 does not end at release. Maintenance requirements include:

• A software maintenance plan
• Problem and modification analysis (evaluating the impact of reported issues and requested changes)
• Regression analysis and testing for every modification
• Configuration management of released software versions

For SaMD products deployed as cloud services, maintenance includes managing the deployment infrastructure, monitoring for anomalies, and ensuring that updates do not introduce regressions.

Software as a Medical Device (SaMD): When IEC 62304 Applies

Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device. The term comes from the International Medical Device Regulators Forum (IMDRF) and has been adopted by the FDA, EU regulators, and other authorities.

SaMD Examples

Understanding what qualifies as SaMD — and what does not — is critical for determining whether IEC 62304 applies to your product:

Is SaMD:

• A mobile app that analyzes retinal images to detect diabetic retinopathy
• A cloud platform that uses ECG data to predict atrial fibrillation risk
• Clinical decision support software that recommends medication dosages based on patient-specific pharmacokinetic models
• An AI/ML algorithm that triages radiology studies by urgency
• A remote patient monitoring platform that generates clinical alerts based on physiological data trends

Is not SaMD:

• An EHR system (stores and retrieves data but does not perform a medical purpose independently)
• A patient portal (communication and data access, not medical decision-making)
• A fitness tracker that counts steps (wellness, not a medical purpose)
• Hospital inventory management software

The boundary is “medical purpose.” If the software analyzes, interprets, or acts on clinical data to inform diagnosis, treatment, or prevention, it is likely SaMD.

IMDRF SaMD Classification Framework

The IMDRF framework classifies SaMD based on two dimensions:

1. Significance of the information provided by the SaMD to the healthcare decision:

   • Treat or diagnose
   • Drive clinical management
   • Inform clinical management

2. Seriousness of the healthcare situation or condition:

   • Critical (death or irreversible condition)
   • Serious (intervention required to prevent permanent impairment)
   • Non-serious

These dimensions create a risk matrix:

The category (I through IV) maps to regulatory requirements. Category III and IV SaMD typically require the most rigorous IEC 62304 compliance (Class B or C software safety classification), while Category I SaMD may qualify for Class A or B.

FDA Classification of SaMD

The FDA maps SaMD to its traditional device classification system (Class I, II, III) through product-specific guidance documents and De Novo classifications. Key FDA SaMD guidance documents include:

• Clinical Decision Support Software (final, September 2022) — exemption criteria under Section 520(o)(1)(E) of the FD&C Act, distinguishing non-device CDS from regulated CDS software
• Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions (final, December 2024) — the FDA’s framework for AI-enabled medical devices, allowing manufacturers to pre-specify model updates and execute them without resubmitting
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final, September 2023) — implements Section 524B premarket cybersecurity requirements

The FDA’s 2017 guidance “Software as a Medical Device (SaMD): Clinical Evaluation,” which adopted IMDRF/SaMD WG/N41FINAL:2017, was withdrawn by CDRH on January 6, 2026 as part of a shift toward risk-based, contextual oversight rather than a single prescriptive framework. The underlying IMDRF document remains a useful reference for global SaMD work, but FDA reviewers no longer expect submissions to track to its specific recommendations. Developers should now justify clinical evidence strategies case by case against current FDA digital health guidance for their device’s intended use and risk profile.

For FDA-regulated SaMD, IEC 62304 compliance is expected in premarket submissions (510(k), PMA, De Novo). The FDA’s final guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” (September 2023), which implements Section 524B of the FD&C Act for cyber devices, adds additional requirements on top of IEC 62304 for any SaMD with network connectivity.

IEC 62304 vs FDA Guidance: From 21 CFR Part 820 to QMSR

Understanding how IEC 62304 fits within the broader FDA regulatory framework requires comparing it with other applicable regulations and standards.

21 CFR Part 820 (the Predecessor Quality System Regulation)

Part 820 was the FDA’s Quality System Regulation from 1996 until February 2, 2026, when the Quality Management System Regulation (QMSR) replaced it. It defined quality management system requirements for medical device manufacturers, including design controls (Subpart C), production and process controls, and corrective action. Any device design history file or quality system documentation created before that date references Part 820, so understanding it remains essential for legacy device support, post-market submissions referencing pre-QMSR work, and any 510(k) where the predicate device was cleared under Part 820.

IEC 62304 operated within the design control framework of Part 820 — the software development plan, requirements, architecture, and testing activities required by IEC 62304 produced the design input, design output, design verification, and design validation artifacts that Part 820 expected. The same alignment carries forward under QMSR (now referencing ISO 13485’s design control clauses).

QMSR: The Transition to ISO 13485

The FDA published the Quality Management System Regulation (QMSR) final rule in the Federal Register on February 2, 2024, with a two-year transition. As of February 2, 2026, the QMSR has replaced 21 CFR Part 820 by incorporating ISO 13485:2016 (and clause 3 of ISO 9000:2015) by reference. The FDA also retired the Quality System Inspection Technique (QSIT) on that date and now inspects under the updated Compliance Program 7382.850. This means:

• The FDA quality system requirements now align with the international standard ISO 13485
• IEC 62304 compliance becomes even more natural, as both IEC 62304 and ISO 13485 share the same terminology, risk management approach (ISO 14971), and lifecycle concepts
• Organizations already compliant with ISO 13485 and IEC 62304 had minimal additional work for FDA compliance at the transition

How They Fit Together

ISO 13485 provides the quality management system. ISO 14971 provides the risk management framework. IEC 62304 provides the software-specific lifecycle processes. IEC 81001-5-1 adds security-specific lifecycle processes. Together, they form a coherent system for developing safe and effective medical device software.

IEC 62304 and EU MDR

For products marketed in the European Union, IEC 62304 compliance is essentially mandatory. The EU Medical Device Regulation (MDR 2017/745) does not explicitly reference IEC 62304, but it is listed as a harmonized standard under the MDR framework. Compliance with harmonized standards provides a presumption of conformity with the corresponding MDR requirements.

Key EU MDR considerations for software:

• Annex I, Chapter II, Section 17 establishes software lifecycle requirements that map directly to IEC 62304
• Classification rules for SaMD (Rule 11 in Annex VIII) tend to upclassify software, often resulting in Class IIa or higher, which triggers notified body involvement
• Technical documentation requirements (Annex II and III) expect IEC 62304-aligned evidence of lifecycle process compliance
• Post-market surveillance requirements (Article 83-86) align with IEC 62304’s software maintenance processes

Organizations seeking both FDA clearance and CE marking benefit significantly from an IEC 62304-based quality system, as it satisfies the software lifecycle expectations of both regulatory frameworks.

IEC 62304 Compliance Checklist

Use this checklist to assess your current compliance posture. Items are organized by lifecycle phase with applicability by safety class noted.

Planning Phase

• Software development plan exists and is maintained (A, B, C)
• Lifecycle model is defined (waterfall, agile, hybrid) (A, B, C)
• Configuration management procedures are documented (A, B, C)
• Tools are identified and qualified where necessary (A, B, C)
• Risk management plan references software-specific activities (A, B, C)
• SOUP management process is defined (A, B, C)
• Coding standards are selected and documented (B, C)

Requirements Phase

• Software requirements specification is documented (A, B, C)
• Requirements are uniquely identified and traceable (A, B, C)
• Risk control requirements from ISO 14971 are included (A, B, C)
• Security requirements are defined (B, C)
• Interface requirements specify protocols and data formats (B, C)
• Requirements are reviewed and approved (B, C)

Architecture Phase

• Software architecture document describes items and interfaces (B, C)
• Safety-critical items are identified and segregated (B, C)
• SOUP items are identified with versions and anomaly lists (B, C)
• Architecture supports the safety classification decomposition (B, C)
• Architecture is reviewed against requirements (B, C)

Design and Implementation Phase

• Detailed design documents exist for safety-critical items (C)
• Code follows defined coding standards (B, C)
• Static analysis is run on committed code (B, C)
• Unit tests cover safety-critical requirements (B, C)
• Code reviews are documented (C)
• Traceability from requirements → design → code → tests is maintained (C)

Testing Phase

• Integration test plan and results are documented (B, C)
• System test plan covers all software requirements (A, B, C)
• Regression testing is performed after modifications (B, C)
• Test environment matches intended deployment configuration (B, C)
• Anomalies found during testing are tracked to resolution (A, B, C)

Release and Maintenance Phase

• Released software versions are under configuration management (A, B, C)
• Software maintenance plan is documented (A, B, C)
• Problem reports are evaluated for safety impact (A, B, C)
• Modifications follow the full lifecycle process (A, B, C)
• SOUP components are monitored for new vulnerabilities (B, C)

Compliance Roadmap for Startups

If you are a startup building a SaMD product and approaching IEC 62304 compliance for the first time, the standard can feel overwhelming. Here is a practical roadmap that front-loads the highest-value activities.

Phase 1: Foundation (Weeks 1-4)

Establish your QMS core. You do not need a 200-page quality manual on day one. Start with:

• A software development plan that describes your development methodology (likely agile)
• A risk management plan referencing ISO 14971
• A configuration management procedure (Git, branching strategy, versioning)
• A SOUP management procedure (dependency tracking, vulnerability monitoring)

Classify your software. Work with your regulatory team (or consultant) to determine your software safety class. This decision drives everything that follows. Do not default to Class C “to be safe” — overclassification creates unnecessary documentation burden that will slow you down.

Phase 2: Build Your Pipeline (Weeks 5-8)

Automate verification. Set up a CI/CD pipeline that runs:

• Static analysis (e.g., SonarQube, Coverity, or language-appropriate linters)
• Unit tests with coverage reporting
• Integration tests
• SOUP vulnerability scanning (e.g., Dependabot, Snyk, or OWASP Dependency-Check)

# Example: Automated SOUP vulnerability check
npm audit --production --audit-level=high
# or for Python
pip-audit --requirement requirements.txt --fix --dry-run

Instrument traceability. Use your issue tracker (Jira, Linear, GitHub Issues) as the traceability backbone. Requirements become issues, design decisions are documented in issue comments, implementation is tracked via branches and PRs, and test results link back to the requirement issue.

Phase 3: Process Maturity (Weeks 9-16)

Formalize design documentation. For Class B and C software, create architecture documents that describe your software items, their interfaces, and their safety classification decomposition. For Class C, add detailed design documents for safety-critical components.

Establish change control. Define how changes flow from request → risk analysis → implementation → verification → release. Pull request workflows with required reviews are a natural fit.

Conduct gap analysis. Compare your processes against the IEC 62304 clauses systematically. Identify gaps and create a remediation plan.

Phase 4: Audit Readiness (Ongoing)

Generate your Design History File (DHF). The DHF is the compilation of all lifecycle artifacts for a product. With automated pipelines and good issue tracking, most DHF content is generated as a natural output of your development process.

Conduct internal audits. Before a notified body or FDA reviewer examines your processes, conduct your own internal audit. Identify findings and demonstrate that you have a functioning corrective and preventive action (CAPA) system.

Common Pitfalls in IEC 62304 Compliance

Having worked with medical device software teams across the maturity spectrum, we see the same compliance pitfalls repeatedly.

1. Treating Documentation as an Afterthought

The most expensive compliance mistake is building the software first and writing the documentation later. Retroactive documentation is slow, inaccurate, and obvious to auditors. Integrate documentation into your development workflow so that it is a natural output of the work, not a separate effort.

2. Ignoring SOUP Management

Third-party libraries, open-source components, and OS-level dependencies are SOUP under IEC 62304. Every SOUP item must be identified, versioned, and risk-assessed. Known anomalies (bugs, vulnerabilities) must be evaluated for their impact on your device’s safety. Many teams track their own code meticulously but treat dependencies as a black box.

3. Overclassifying Software Safety Class

Classifying everything as Class C “to be safe” is a common but counterproductive strategy. Class C requires full lifecycle documentation for every software unit, which dramatically increases development time and cost. Use risk management to justify the appropriate class, and leverage the 2015 amendment’s ability to decompose safety classes at the item level.

4. Conflating IEC 62304 with a Development Methodology

IEC 62304 is methodology-agnostic. It defines what must be done, not how. Teams that interpret IEC 62304 as requiring waterfall development impose unnecessary rigidity on themselves. Agile and iterative methodologies are fully compatible with IEC 62304 — you simply need to map your agile artifacts (sprint plans, user stories, acceptance tests) to the lifecycle activities the standard requires.

5. Neglecting Maintenance Processes

IEC 62304 covers the entire lifecycle, including post-release maintenance. Teams that focus solely on initial development and neglect to establish problem reporting, impact analysis, and regression testing processes for updates will face compliance gaps when they release their first patch.

6. Missing the Connection to ISO 14971

IEC 62304 and ISO 14971 are deeply intertwined. Software safety classification comes from risk management. Risk control requirements drive software requirements. Verification activities must demonstrate that risk controls are effective. Teams that treat IEC 62304 and ISO 14971 as separate exercises miss the integration points that auditors expect to see.

IEC 62304 compliance is not a one-time checkbox. It is a system of processes that grow with your product and your organization. Starting with a clear understanding of the standard’s requirements, choosing the right safety classification, and building automation into your lifecycle processes will put you on the path to compliance without sacrificing development velocity.

For help with IEC 62304 compliance, SaMD development, or building a quality management system for medical device software:

• Healthcare Software Development — IEC 62304-compliant lifecycle processes for SaMD and medical software
• Medical Device Integration — Connecting devices to clinical systems
• FDA Medical Device Cybersecurity — Section 524B requirements and security testing