IEC 62304:2006+A1:2015
Medical device software — Software life cycle processes
Standard Introduction
IEC 62304:2006+A1:2015 is the international standard defining life cycle requirements for medical device software. Originally published in 2006 with Amendment 1 added in 2015, it establishes a common framework for software development, maintenance, and risk management applicable to standalone software medical devices (SaMD), software components of medical devices, and software used in device production.
The standard introduces a three-tier safety classification system (Classes A, B, C) based on potential harm from software failure, with increasingly stringent development requirements for higher-risk classes. It defines structured processes spanning planning, requirements, design, implementation, verification, validation, release, and maintenance. IEC 62304 integrates closely with ISO 14971 for risk management and is recognized by the FDA and referenced as a harmonized standard under the EU Medical Device Regulation (MDR 2017/745).
Software Safety Classification
Classifies medical device software into three safety classes (A, B, C) based on potential harm, with increasingly rigorous requirements for higher-risk software.
Lifecycle Process Framework
Defines structured processes for planning, requirements analysis, design, implementation, verification, validation, release, and maintenance of medical device software.
Risk-Integrated Development
Integrates with ISO 14971 risk management, requiring systematic identification and mitigation of software-related hazards throughout the entire development lifecycle.
list_alt Software Lifecycle Processes
- Software development planning
- Software requirements analysis
- Software architectural and detailed design
- Software unit implementation and verification
- Software integration and integration testing
- Software system testing and release
- Software maintenance process
- Software risk management (integrated with ISO 14971)
Who Needs to Comply?
Manufacturers of medical devices that include software, software that is itself a medical device (SaMD), and software used in the production or maintenance of medical devices. Required for regulatory submissions to FDA, EU MDR, and most global medical device regulators.
Key Requirements
Software Safety Classification
Classify software systems and items into safety classes A (no injury possible), B (non-serious injury possible), or C (death or serious injury possible). Apply class-appropriate rigor throughout development.
Software Development Plan
Create a comprehensive software development plan covering lifecycle model, deliverables, traceability, configuration management, and verification/validation strategies before development begins.
Requirements & Traceability
Define complete software requirements including functional, performance, interface, and safety requirements. Maintain bidirectional traceability from requirements through design, implementation, and testing.
Verification & Validation
Perform unit testing, integration testing, and system testing appropriate to the software safety class. Validate that the software meets user needs and intended uses in the target environment.
Software Maintenance
Establish a maintenance process to track and evaluate feedback, implement modifications (corrections, enhancements, adaptations), and manage the impact of changes on safety and performance.
Implementation Roadmap
Prepare scope, obligations and evidence model
Define the medical device software lifecycle program scope across medical device software, embedded software, standalone software, SOUP, software maintenance, risk controls, requirements, architecture, verification, release, and problem resolution. Identify applicable legal, product, customer, certification, or market-access obligations and agree how evidence will be owned, updated, and retained.
Gap analysis and risk classification
Assess current practices against IEC 62304 requirements and risk context. Review software safety classification, development planning, requirements, architecture, detailed design, implementation, verification, integration, release, maintenance, SOUP management, configuration management, and problem resolution, then prioritize gaps by market-access impact, safety or environmental risk, customer exposure, and documentation readiness.
Implement controls, testing and documentation
Deploy required controls, supplier workflows, testing or assessment activities, labeling or communication steps, and technical documentation. Build traceable evidence around software development plans, safety classification rationale, requirements traceability, architecture and design records, verification reports, SOUP evaluations, release records, anomaly logs, configuration records, and maintenance plans.
Review, maintain and respond to changes
Complete readiness reviews and corrective actions before the regulatory submission review or software lifecycle audit. Keep the program current after product, supplier, substance, design, regulatory, market, or incident changes.
Compliance Checklist
checklist Scope and obligations
checklist Controls and evidence
checklist Monitoring and maintenance
Penalties & Enforcement
No direct penalties for non-compliance with IEC 62304 itself. However, regulatory authorities (FDA, EU Notified Bodies) require conformity to IEC 62304 for medical device market access. Non-compliance can result in rejection of regulatory submissions, product recalls, and market withdrawal.
Frequently Asked Questions
Who needs IEC 62304?
expand_more
IEC 62304 is relevant for organizations whose products, services, or activities fall within medical device software, embedded software, standalone software, SOUP, software maintenance, risk controls, requirements, architecture, verification, release, and problem resolution. It is commonly driven by market access, safety, environmental, customer, or regulatory obligations.
What is the main purpose of IEC 62304?
expand_more
The practical purpose is to create a repeatable program for software safety classification, development planning, requirements, architecture, detailed design, implementation, verification, integration, release, maintenance, SOUP management, configuration management, and problem resolution. The program should make obligations visible, define accountable owners, and maintain evidence that remains current as products and rules change.
What should be done first?
expand_more
Start with scope. Identify which products, components, sites, suppliers, markets, and activities are covered before writing procedures or commissioning tests.
How long does implementation take?
expand_more
Implementation can take weeks for a narrow product family or many months for complex multi-market portfolios. Timing depends on testing, supplier evidence, technical documentation quality, and whether third-party assessment is needed.
What evidence is most important?
expand_more
Important evidence includes software development plans, safety classification rationale, requirements traceability, architecture and design records, verification reports, SOUP evaluations, release records, anomaly logs, configuration records, and maintenance plans. Authorities, auditors, customers, and test labs usually expect traceable records that connect requirements to decisions, tests, labels, and declarations.
How should suppliers be managed?
expand_more
Suppliers should provide declarations, test reports, change notifications, and traceable material or component data. High-risk suppliers need periodic review and contractual flow-down of compliance requirements.
When should the file be updated?
expand_more
Update the file after regulatory changes, design changes, supplier changes, material changes, incidents, complaints, or new market launches. Static files quickly become unreliable in product compliance.
Can this be integrated with other programs?
expand_more
Yes. IEC 62304 can share supplier management, document control, risk management, test planning, labeling review, and corrective-action workflows with related quality, safety, environmental, or product-compliance programs.
Official Documentation
IEC 62304:2006+A1:2015
External Link • iec.ch • Standard Purchase Page
ISO Standard Page
External Link • iso.org • Standard Information
FDA Medical Device Guidance
External Link • fda.gov • Software Guidance Documents