ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62304 SOUP — software of unknown provenance — is the part of a medical device the manufacturer did not write and is still responsible for. Operating systems, runtimes, libraries, frameworks, drivers, the language’s own standard library and every dependency they pull in behind them all count. The standard’s position is simple and often misread: you cannot be excused from a requirement because somebody else wrote the code.
This guide sets out what IEC 62304 SOUP is, what the standard requires of it at each software safety class — including the obligations that bind Class A — and where teams most often fall short.
The standard defines SOUP as a software item that is either already developed and generally available and was not developed for the purpose of being incorporated into the medical device — off-the-shelf software — or was previously developed but without adequate records of its development process being available. The acronym is deliberately neutral about quality: SOUP is not bad software, it is software whose provenance the manufacturer cannot fully evidence.
| Is it IEC 62304 SOUP? | Answer | Why |
|---|---|---|
| A commercial or open-source library | Yes | Generally available; not written for this device |
| The operating system or runtime | Yes | Same |
| The language’s standard library | Yes | The standard names standard libraries explicitly in 8.1.2 |
| A transitive dependency pulled in by a library | Yes | It is a software item in the build; who chose it is irrelevant |
| Code your own team wrote years ago, with no surviving design or test records | Yes | Previously developed without adequate records |
| A component supplied by a contractor under your QMS with full records | No | Adequate development records exist; it is supplied software, controlled through purchasing |
| Your medical device software system as a whole | No | The standard’s note says a device software system cannot itself be claimed as SOUP |
Two of those rows do the damage in audits. Standard libraries are IEC 62304 SOUP even though nobody “chose” them, and transitive dependencies are SOUP even though nobody knew they were there. A dependency manifest or lock file is the only honest inventory.
The most common misconception is that SOUP management is a Class B and C concern. Two requirements bind Class A as firmly as Class C.
For each SOUP configuration item being used — including standard libraries — the manufacturer documents its title, its manufacturer and a unique designator: the version, release date, patch level or upgrade designation that identifies the exact instance in the build. A version range or “latest” is not a designator. This is Class A, B and C.
The software maintenance plan has to address how the manufacturer evaluates and implements upgrades, bug fixes, patches and the obsolescence of SOUP. Every class, every released system. A Class A app on a mobile platform that ships a new OS every year has a live obsolescence problem, and the plan has to say what the answer is.
Together these mean the SOUP register and the maintenance plan are Class A deliverables. Our guide to software safety classification lists the 57 requirements Class A owes; these two are among them.
Above Class A, four further requirements apply.
| Clause | Requirement, in our words | Class | What the record looks like |
|---|---|---|---|
| 5.3.3 | Specify the functional and performance requirements each SOUP item must meet for its intended use in this system | B, C | A short requirements section per SOUP item — what you rely on it to do, and how fast or how much |
| 5.3.4 | Specify the system hardware and software the SOUP item needs to operate properly | B, C | Processor, memory, OS and version, communication and display software, build options |
| 7.1.2 c) | Consider failure or unexpected results from SOUP as a potential cause of a software item contributing to a hazardous situation | B, C | A row in the software hazard analysis per item that uses SOUP |
| 7.1.3 | Where SOUP failure is a potential cause, evaluate at minimum the anomaly list the supplier publishes for the version in use, for anomalies that could lead to a hazardous situation | B, C | An evaluation record per SOUP version: sources checked, anomalies found relevant, actions |
Two more IEC 62304 SOUP obligations arrive indirectly. The development plan must cover configuration management including SOUP configuration items (5.1.1 d)), and the integration plan must cover integrating SOUP items (5.1.5, Class B and C). And every change to SOUP — a patch, an upgrade — is a software change under 7.4.1, analysed for new potential causes and needed controls at every class.
The IEC 62304 SOUP anomaly-list requirement, clause 7.1.3, is narrower than people fear and broader than people do. It is triggered only where SOUP failure is a potential cause of a hazardous situation — so an IEC 62304 SOUP item used for a cosmetic function may need no evaluation. But where it is triggered, the standard’s minimum is the supplier’s published anomaly list for the version in use. Release notes, known-issue lists, errata and security advisories all qualify; a vulnerability database entry is an anomaly list by another name.
The evaluation is not “have we read it”. It is: does any listed anomaly affect a function this system relies on, under conditions this system can produce, and could it be part of a sequence of events leading to a hazardous situation the risk analysis has identified? A relevant, uncontrolled anomaly becomes a software cause in the hazard analysis and needs a risk control — a workaround, an added check, a version change or a decision not to use the affected function. Our guide to IEC 62304 risk management covers the clause 7 process these evaluations feed, and ISO 14971 the file they belong in.
The IEC 62304 Toolkit carries a SOUP identification and management procedure, a SOUP requirements specification for the Class B and C content, an anomaly-list evaluation procedure and record, a maintenance plan with a per-item obsolescence table, and a SOUP register with the three identification fields as mandatory columns and a reconciliation column for every baseline. The standard’s own text is licensed by the IEC; the requirements above are paraphrased from it.
Yes. It is generally available and was not developed for your device, which is the definition. Its licence is a separate matter; its treatment under the standard is the same as any commercial library.
Yes. Identification by title, manufacturer and unique designator (8.1.2) and maintenance planning for upgrades, patches and obsolescence (6.1 f)) apply at every class. Specifying requirements for the item and evaluating anomaly lists are Class B and C.
For every SOUP item that could be a cause of a hazardous situation, at Class B and C, yes — at minimum the published anomaly list for the version you use, evaluated against your hazard analysis. For items that cannot contribute to a hazardous situation, the standard does not require it, though maintenance monitoring under clause 6 still applies.
Close. An SBOM is the machine-readable inventory regulators increasingly ask for under cybersecurity rules; the SOUP register is IEC 62304’s human-readable equivalent with the requirements, anomaly-evaluation and obsolescence columns added. Generate both from the same build manifest so they cannot disagree.
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026