IEC 62304

By CHASE Team

Last edited: September 9, 2026

IEC 62304 is the international standard defining lifecycle processes for medical device software. It covers software that is itself a medical device and software that is embedded within one, and it sets out what must be done during development and maintenance to give reasonable assurance that the software is safe.

The standard is deliberately process-focused rather than prescriptive about technology. It does not tell teams which language, architecture or methodology to use. It requires that whatever they do is planned, documented, traceable and verified, which means it can be satisfied by agile teams as readily as by traditional waterfall projects, provided the documentation genuinely reflects how the work happened.

Software safety classification

  • 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 is made on the harm that could result from failure, after external risk control measures are taken into account, and it drives how much rigour is required. Class C, for instance, demands detailed design documentation and unit level verification that Class A does not.

Lifecycle processes

The standard covers software development planning, requirements analysis, architectural design, detailed design, implementation, integration and system testing, and release. Alongside these sit maintenance, configuration management, problem resolution and software risk management, all of which continue for as long as the product is on the market.

SOUP and third party code

Software of unknown provenance (SOUP) is any component not developed for the device under this standard, which in practice covers most open source libraries, operating systems and frameworks. Each item must be identified with its version, its functional and performance requirements documented, its known anomalies reviewed for safety relevance and its ongoing vulnerabilities monitored. Teams that adopt dependencies casually often find this the most painful gap to close retrospectively.