IEC 62304 is the standard for the software lifecycle of medical devices. It covers development, maintenance, risk management, configuration management and problem resolution, and it treats third party code as SOUP, software of unknown pedigree or provenance, which must be justified and tested before use.
Why the standard exists
The standard was created in response to incidents such as the Therac-25 radiation overdoses, according to the summary reviewed. Our post on what happened with the Therac-25 shows the failure modes it targets: unreviewed code, reused code and poor error handling.
The processes it covers
Development. Planning, requirements analysis, architectural and detailed design, unit implementation and verification, integration and integration testing, system testing and release.
Maintenance. A maintenance plan, analysis of problems and modifications, and implementation of changes.
Risk management. Analysis of software that can contribute to hazardous situations, risk control measures, verification of those controls, and management of risk from software changes. This links to ISO 14971, the medical device risk management standard.
Configuration management. Identification of items, change control and status accounting.
Problem resolution. Preparing and investigating problem reports, using change control, keeping records, trend analysis and verifying fixes.
The standard also has a software safety classification, and the documents required depend on the class.
What SOUP means in practice
SOUP is any software you did not develop under this standard: an open source library, a commercial component, an operating system. The standard sets out a risk based decision model for when SOUP may be used, and requires testing that supports the rationale for using it.
For each SOUP item a team normally records:
- What it is, which version, and where it came from.
- What it does in the product and which safety functions might depend on it.
- Why it was chosen and what its published problems are.
- How it was tested in your context.
- How you will hear about and respond to new defects and vulnerabilities.
The sources reviewed do not spell out those fields, so treat the list as a common practice and check your own quality system and the standard text.
Inventory is the first step
You cannot assess what you have not listed. A dependency inventory with versions, generated from the build rather than remembered, gives the SOUP list a factual base.
Click through it at your own pace, or open it full screen.
Safeguard produces SBOMs and runs dependency scanning, which helps keep that list current and flags known vulnerabilities in listed components. The regulatory file still needs your own rationale and testing.
Quick check
Is open source code always SOUP?
If you did not develop it under the standard's processes, it is generally treated as SOUP. Check how your quality system defines it.
Does the standard tell me which library to choose?
No. It requires a justified, risk based decision supported by testing, not a particular choice.
Sources
Secondary summaries; the standard text is authoritative.
Last reviewed: 19 October 2026.
