Documentation Standard
IEC 62304
The software life cycle standard for medical device software: what to plan, document and verify, scaled to how much harm the software could do.
- Full title
- Medical device software — Software life cycle processes
- Current edition
- IEC 62304:2006 + Amendment 1:2015, often written “edition 1.1”
- Applies to
- Software that is a medical device or part of one, including firmware, and its maintenance after release
- Recognition
- FDA-recognized consensus standard. In the EU it is treated as the state of the art for software life cycle, although it is not yet listed as harmonised under the MDR
- Coming
- A second edition has been in development for several years. It had not been published when this page was last reviewed
In short
IEC 62304 does not say how to write software or which methodology to use. It defines the processes, activities and records a manufacturer needs, and scales them by safety class. It assumes two things are already in place: a quality management system (normally ISO 13485) and a risk management process (ISO 14971).
Software safety classes
| Class | When it applies | What it adds |
|---|---|---|
| A | The software cannot contribute to a hazardous situation, or it can but the result is not an unacceptable risk once risk controls outside the software are counted. | The baseline: planning, requirements, implementation, system testing, release, plus configuration management and problem resolution. |
| B | The software can contribute to a hazardous situation that results in unacceptable risk, and the possible harm is non-serious injury. | Architecture, unit verification, integration testing, and software risk management in full. |
| C | As B, but the possible harm is death or serious injury. | Detailed design for each unit and stricter unit verification criteria. |
Classification starts from the assumption that the software will fail. What matters is how severe the resulting harm could be and what stands between the failure and the patient. A system can be split into items with different classes if the separation between them is justified.
What it asks for
- Development planning (5.1). The plan, the life cycle model, deliverables, traceability, configuration and change management, and how third-party software is handled.
- Requirements analysis (5.2). Software requirements derived from system requirements and from risk control measures.
- Architecture and detailed design (5.3, 5.4).
- Unit implementation and verification, integration, system testing (5.5 to 5.7).
- Release (5.8). Verification complete, known residual anomalies documented and evaluated, and the released version archived so the build can be repeated.
- Maintenance (6), software risk management (7), configuration management (8) and problem resolution (9). These run for the life of the product, not only during development.
On a software project
- Classify early. The safety class sets the documentation and verification load, so decide it with the risk file at the start and record the rationale.
- Any life cycle model is allowed. Iterative and Agile approaches are compatible, provided the required activities and records are produced. AAMI TIR45 is the usual reference for Agile in this setting.
- Third-party code is SOUP. Every library, operating system or open-source component is “software of unknown provenance”: list it with its version, state what the product needs from it, review its known anomalies, and keep it under configuration management.
- Keep the trace. Requirements, tests and risk control measures must be linked. See verification, validation and traceability.
- Changes get the same rigour as new work. After release, each change is analysed, approved, verified and regression tested.
- Legacy software has its own route. Amendment 1 added clause 4.4 for software that was on the market before the standard applied: a gap analysis and a risk-based plan to close it.
Worth knowing
- The standard covers software verification. Validation of the finished device is outside its scope and sits with the quality system and device-level standards, such as IEC 82304-1 for standalone health software.
- Security is not covered in depth. IEC 81001-5-1, which sets out security activities across the same life cycle, is commonly applied alongside it.
- For an FDA submission, the FDA’s own guidance defines what software documentation to submit. A declaration of conformity to IEC 62304 can stand in for part of it.
Official sources
- IEC 62304:2006 + AMD1:2015, IEC webstore
- FDA recognized consensus standards database
- FDA guidance: Content of Premarket Submissions for Device Software Functions
A summary for orientation. It is not regulatory or legal advice, and it is no substitute for the standard or regulation itself. Requirements change: confirm the current edition before relying on anything here. Last reviewed November 2026.