IEC 62304: lifecycle evidence a reviewer can follow
Assign safety classes from your hazard analysis, list third-party software, and link every problem to its change, risk and test.
In Short
- FDA lists IEC 62304 as consensus.
- Safety classes A, B and C.
- List and assess third-party code.
IEC 62304 is the international standard for medical device software lifecycle processes. FDA lists ANSI/AAMI/IEC 62304 as a consensus standard relevant to device software, and its June 2023 guidance Content of Premarket Submissions for Device Software Functions refers to it for configuration management and maintenance documentation. The standard text itself is sold by IEC and was not opened for this review, so clause-level detail below is limited to widely published structure. This guide summarises the sources named here; it is orientation, not legal advice. Sources checked 5 Oct 2026.
Where the standard sits
IEC 62304 defines lifecycle processes for medical device software: development, maintenance, risk management input, configuration management and problem resolution. It works alongside a quality management system and a risk management process such as ISO 14971; it does not replace either.
More on where the standard sits
Regulators and notified bodies use it as a reference for what a controlled software lifecycle looks like. Following it is a choice your organisation makes and documents, and auditors will expect your procedures to say how you apply it.
Software Safety Classes
The standard groups software systems into safety classes A, B and C according to the harm a software failure could contribute to after external risk controls are considered. The class decides how many lifecycle activities and how much documentation apply.
More on software Safety Classes
Record the class with the hazard analysis that supports it, and revisit it when the architecture or risk controls change. FDA's separate documentation levels in the June 2023 guidance serve a submission purpose and are decided on their own criteria.
Third-Party and Legacy Software
Most device software uses components you did not write, from operating systems to open-source libraries. The standard calls these software of unknown provenance when adequate development records are not available.
More on third-Party and Legacy Software
Keep a list with versions, the functional and performance requirements you rely on, known issues you have assessed and how risks are controlled. FDA's guidance similarly expects submissions to identify off-the-shelf software. Update the list at every release so it never trails the build.
Problem Resolution and Maintenance
Problems found in testing or in the field need a recorded process: report, investigate, assess safety impact, decide on change, verify the fix and inform users where needed. Maintenance releases go through the same configuration management and regression testing as new development.
Worked Example: Third-Party Software List for App CardioView 2.4
| Component | Version | Risk note |
|---|---|---|
| Image decoding library | 3.1.2 | Malformed input; validated by input checks |
| Mobile OS | Supported range | Update behaviour tested per release |
| Charting library | 5.0 | Display only; reviewed known issues |
- Image decoding library
- Version
- 3.1.2
- Risk note
- Malformed input; validated by input checks
- Mobile OS
- Version
- Supported range
- Risk note
- Update behaviour tested per release
- Charting library
- Version
- 5.0
- Risk note
- Display only; reviewed known issues
More on problem Resolution and Maintenance
Linking each problem report to the change request, risk assessment, code version and test record lets a reviewer follow one issue end to end without asking for screenshots or spreadsheets.
Building a Reviewable Software File
A practical software file holds the development plan, requirements, architecture, detailed design where the class requires it, verification records, the third-party software list, release notes and the problem log, each version-controlled and approved. Keep links between requirements, risks and tests current as you work, rather than assembling them before an audit.
Software Release File Checklist
More on building a Reviewable Software File
People approve each release; the file shows what they reviewed and when.
Questions
Does FDA recognise IEC 62304?
FDA lists ANSI/AAMI/IEC 62304 as a consensus standard relevant to device software lifecycle processes, and its June 2023 guidance refers to it for configuration and maintenance documentation.
Are safety classes the same as FDA documentation levels?
No. Safety classes come from IEC 62304 and scale lifecycle activities; FDA's Basic and Enhanced Documentation levels decide submission content.
What is SOUP?
Software of unknown provenance: components, often third-party, without adequate development records. Keep them listed with versions, requirements and assessed risks.
Can V5 hold the software file?
V5 can hold controlled documents, change records, CAPA and approvals. It is not a source-code or test-execution tool; your engineering tools keep those artefacts.
Practical orientation, not legal advice. Rules differ by jurisdiction; your quality and compliance team decides what applies.
Keep reading
Software as a Medical Device (SaMD): US Scope and Readiness
Predetermined Change Control Plans (21 U.S.C. 360e-4) for Medical Devices
Australia Medical Device Regulatory Readiness Guide
Brazil medical device regulatory readiness guide (ANVISA)
Canada Medical Devices Regulations (SOR/98-282) Readiness
China Medical Device Regulatory Readiness Guide 2026