IEC 62304's SOUP duty doesn't wait for a safety class

This blog has already covered what IEC 62304's safety classification decides before a manufacturer writes a line of code: how much of the standard's own lifecycle rigor a given software item owes, sorted by how directly it could contribute to a hazard. A design history file that treats classification as the only gate a software item has to clear stops short of a separate duty the standard attaches to a different property entirely — whether the item counts as Software of Unknown Provenance, and that duty runs at Class A as readily as it runs at Class C.

SOUP is a status, not a class

IEC 62304 defines SOUP as a software item that's already developed and generally available, and that wasn't developed for the purpose of being incorporated into this particular medical device — or one for which adequate records of its own development process simply don't exist. An open-source compression library, a commercial real-time operating system, a legacy in-house module nobody kept design records for: all three qualify, regardless of how safety-critical the finished device turns out to be. Classification and SOUP status answer different questions about the same component. A Class A item — no safety-class rigor beyond the standard's baseline, because it can't contribute to a hazardous situation — can still be built entirely on a SOUP operating system, and the SOUP duty attaches to that operating system regardless of the low class sitting above it.

What the standard actually asks a manufacturer to produce

Clauses 5.3.3 and 5.3.4 require a manufacturer to specify the functional and performance requirements it's actually relying on the SOUP item to meet, and the hardware and software configuration the SOUP item needs to run as intended — not the component's full manual, just the slice of its behavior the device's own design depends on. Clauses 7.1.2 and 7.1.3 go further, into the risk file itself: for any SOUP item that could contribute to a hazardous situation, the manufacturer has to evaluate the anomalies — the known, unresolved defects — the SOUP's own supplier has published, and judge whether any of them could produce or worsen a hazard the device's risk analysis already tracks. That's an active evaluation against a real published list, not a checkbox confirming the SOUP item exists and was noted somewhere.

Where teams stop at the wrong document

This blog has already covered what a software bill of materials owes under Section 524B: a line-by-line inventory of the commercial, open-source, and off-the-shelf components a device's cyber device submission has to name. An SBOM and a SOUP evaluation can look, at a glance, like the same paperwork about the same components — but they answer different questions. The SBOM tells a reviewer what's inside the device, checkable line by line against the actual codebase. IEC 62304's SOUP clauses ask whether what's inside could hurt someone, given what its own supplier has already disclosed as unresolved about it. A device can carry a complete SBOM and an empty SOUP anomaly evaluation at the same time; finishing one document has not started the other.

A version bump reopens the evaluation

The standard treats a changed SOUP version as a new item for this purpose, not a continuation of the one already evaluated. A dependency update pulled in by a routine build, or a newer release of a third-party library adopted for an unrelated bug fix, resets the clause 7.1.2 question from scratch — the prior anomaly review doesn't carry forward just because the component's name on the shelf didn't change. A build pipeline that updates SOUP versions automatically, without a gate that reopens the anomaly evaluation, can ship a device whose risk file no longer describes the software actually running inside it.

Where this meets the file

A SOUP register needs one row per item: its name and version, the functional and hardware requirements the device relies on it to meet, and the outcome of the anomaly-list evaluation against the device's own hazards — re-opened, not just re-dated, on every version change. A register built around that structure, distinct from the SBOM's own inventory duty this blog has already covered, is previewed in the launch catalog. If your team tracks SOUP differently, the shelf takes that correction directly.