SOUP Management Under IEC 62304: Requirements, Process and SBOM

Table of Contents

• Introduction
• What is SOUP? Definition under IEC 62304
• Why SOUP management matters — the regulatory and safety case
• IEC 62304 requirements for SOUP — clause by clause
• The SOUP management process — step by step
  • Step 1 — Identification and documentation
  • Step 2 — Risk assessment
  • Step 3 — Verification and validation
  • Step 4 — Configuration management and change control
  • Step 5 — Ongoing monitoring throughout the lifecycle
• SOUP and cybersecurity — an increasingly critical intersection
• Common pitfalls — what auditors find
• Best practices for SOUP management
• Frequently asked questions
• Conclusions

Introduction

SOUP management under IEC 62304 is one of the most underestimated — and most frequently audited — aspects of medical device software compliance. Almost every modern medical device software system relies on third-party components: open-source libraries, commercial operating systems, cloud APIs, cryptographic modules. Each one of these is SOUP, and each one requires a structured, documented management process throughout the entire software lifecycle.

This article is part of our ongoing series on IEC 62304 medical device software. If you have not read the foundational article on software safety classification and the Software Development Plan, that is the place to start; IEC 62304 software verification covers the parallel obligations on software you develop yourself, which follow a different evidence model from the one described here.

What is SOUP? Definition under IEC 62304

SOUP stands for Software of Unknown Provenance. IEC 62304 defines it as any software item that was not developed specifically for the medical device being built, or that was previously developed but for which adequate records of its development process are not available. In plain terms: if you did not write it yourself under a controlled IEC 62304-compliant process, it is SOUP.

It is worth noting that the FDA uses a slightly different term — Off-The-Shelf, or OTS, software — but the underlying concept and the regulatory expectations are substantially similar.

Why SOUP management matters — the regulatory and safety case

The use of SOUP is not prohibited under IEC 62304. In fact, it is expected and accepted — the standard recognises that rebuilding every software component from scratch is neither practical nor economically viable. What the standard does require is that manufacturers demonstrate control over every SOUP component used in the device.

The rationale is straightforward: a failure in a SOUP component is a failure in the medical device software. If an open-source cryptographic library has a known vulnerability, or if a commercial operating system receives a breaking update, these events can directly impact patient safety. Without a structured SOUP management process, manufacturers have no mechanism to detect, assess, or respond to these risks.

From a regulatory standpoint, SOUP management is scrutinised closely during FDA premarket submissions — 510(k), De Novo and PMA, where the FDA expects a documented SOUP list as part of the software documentation package; during CE marking under EU MDR 2017/745, where Notified Bodies routinely audit SOUP documentation in technical file review; and during ISO 13485 audits, where SOUP falls under software configuration management and supplier control obligations. Gaps in SOUP documentation are among the most common findings in regulatory audits and in FDA warning letters related to software.

IEC 62304 requirements for SOUP — clause by clause

IEC 62304 has no single dedicated SOUP chapter. The requirements are distributed across several clauses, and knowing which clause demands what is the difference between a SOUP register that survives review and one that does not.

The SOUP management process — step by step

A compliant process breaks down into five activities spanning the entire software lifecycle. Four of them belong to development. The fifth does not end at release, and that is where most processes fail.

Step 1 — Identification and documentation

The first step is building a complete inventory of every SOUP component used in the software system. This inventory — the SOUP list, or in modern terminology the Software Bill of Materials — must capture for each item the software name and version number, the supplier or source (vendor, open-source repository, internal legacy system), the intended use within the medical device software, a reference to the known anomalies list, and the safety class applicable to the item.

This list must be version-controlled and updated whenever a SOUP component is added, updated or removed.

Step 2 — Risk assessment

For each identified item a risk assessment must be performed in alignment with ISO 14971. Three questions drive it: what could go wrong if this component fails or behaves unexpectedly, what is the severity of the potential harm to the patient, user or third parties, and are there risk control measures in place — architectural isolation, runtime monitoring, redundancy — that reduce the risk to an acceptable level.

The safety class of a SOUP item is typically inherited from the safety class of the software system it belongs to. A component integrated into a Class C software system is generally treated as Class C, unless specific architectural segregation justifies a lower classification — and that segregation, as under clause 5.3.5, has to be demonstrated rather than asserted.

Step 3 — Verification and validation

Unlike software developed under a controlled IEC 62304 process, SOUP components come without a pre-existing verification package. Manufacturers must therefore design and execute their own verification strategy for each item, demonstrating that it performs as required within the specific medical device context.

This typically includes integration testing to verify that the SOUP interacts correctly with the surrounding software, functional testing against the specified functional and performance requirements, review of the supplier’s publicly available test results, certifications or quality documentation where available, and static analysis of the known anomaly list against the device’s risk profile.

Step 4 — Configuration management and change control

Every SOUP item must be placed under formal configuration control. Any change — update, patch, version upgrade — goes through a defined change control process covering four things: an impact assessment asking whether the new version introduces new anomalies or changes behaviour in safety-relevant ways; re-verification that the updated component still meets its specified functional and performance requirements; an update to the SOUP list and the SBOM; and documentation of the decision to accept or reject the change.

Step 5 — Ongoing monitoring throughout the lifecycle

SOUP management does not end at product release. IEC 62304 requires manufacturers to monitor components continuously throughout the product’s commercial lifetime: tracking security advisories and vulnerability disclosures from vendors and open-source communities, monitoring the CVE database for newly discovered vulnerabilities, evaluating whether newly disclosed anomalies pose an unacceptable risk and initiating corrective action when they do.

End-of-life situations belong here too. When a component is no longer supported, the manufacturer must assess the impact and plan a migration strategy — before the lack of support becomes a vulnerability with no available patch.

SOUP and cybersecurity — an increasingly critical intersection

The intersection of SOUP management and cybersecurity has become one of the most important — and most regulated — areas in medical device software development. With the increasing connectivity of medical devices, SOUP components represent one of the largest attack surfaces available to malicious actors.

Regulatory bodies are responding accordingly. The FDA’s 2023 cybersecurity guidance for medical devices explicitly requires manufacturers to submit an SBOM as part of premarket submissions, enabling rapid identification of vulnerable components when new security threats emerge. The EU’s NIS-2 Directive and the Cyber Resilience Act impose similar transparency obligations on software supply chains.

Vulnerability monitoring. Manufacturers must continuously monitor the CVE database and vendor security advisories for newly disclosed vulnerabilities in SOUP components. When one is identified, a documented evaluation must determine whether it poses an unacceptable risk to the medical device and, if so, what corrective action is required.

Patch management. Security patches must be evaluated and applied through the formal change control process. The key challenge is balancing the urgency of security patching against the regulatory overhead of re-verification — a documented patch management procedure is what makes that balance defensible rather than improvised.

Software Bill of Materials. The SBOM is the practical tool that makes cybersecurity monitoring feasible at scale. Without a complete, up-to-date SBOM it is impossible to know which components are affected when a new vulnerability is disclosed. The standardised formats — CycloneDX and SPDX — are increasingly required by regulators and should be adopted from the start of the project.

Supply chain security. Manufacturers must verify the integrity and authenticity of components obtained from external sources: verifying checksums or digital signatures, using official distribution channels, and documenting supplier evaluation as part of the purchasing process under ISO 13485. For the broader cybersecurity framework, see IEC 81001-5-1 and medical device cybersecurity testing.

Common pitfalls — what auditors find

Five failures recur across regulatory audits with enough frequency to be worth checking your own file against directly.

Best practices for SOUP management

Start at the architecture phase, not at the end of development. Every architectural decision to use a third-party component should immediately trigger identification and risk assessment. Retroactively documenting SOUP at the end of a project is expensive, error-prone, and almost always leaves compliance gaps.

Use automated Software Composition Analysis. Tools of this kind scan codebases and dependency files, identify all components including transitive dependencies, and flag known vulnerabilities as they are disclosed. Manual SBOM maintenance does not scale beyond a small codebase.

Adopt a standardised SBOM format from day one. CycloneDX and SPDX are the two widely recognised formats and are explicitly referenced in FDA guidance. A standard format simplifies regulatory submissions and works with vulnerability scanning tools out of the box.

Integrate anomaly evaluation into the risk management file. SOUP anomalies should not live in a separate document. They belong traced to the ISO 14971 risk management file, with explicit documentation of whether each has been assessed and whether it requires a risk control measure.

Define clear criteria for version updates. Not every new version requires immediate action, but the decision to update or not must be documented. A simple decision matrix — severity of new anomalies, availability of fixes, regulatory impact — makes the process manageable and auditable.

Frequently asked questions

What is SOUP under IEC 62304?

SOUP stands for Software of Unknown Provenance. IEC 62304 defines it as any software item that was not developed specifically for the medical device being built, or that was previously developed but for which adequate records of its development process are not available. Operating systems, open-source libraries, commercial off-the-shelf components, cloud service APIs and legacy internal code all qualify. The FDA uses a different term, Off-The-Shelf software, with substantially the same meaning.

Is using SOUP allowed under IEC 62304?

Yes. The standard does not prohibit SOUP — it expects it, recognising that rebuilding every component from scratch is neither practical nor economically viable. What it requires is that the manufacturer demonstrates control over every SOUP component: identification, risk assessment, verification, configuration management and ongoing monitoring.

Which IEC 62304 clauses apply to SOUP?

There is no single SOUP chapter. The requirements are distributed: clause 5.3.3 for functional and performance requirements, 5.3.4 for the hardware and software environment, 5.3.5 for segregation, 5.5.4 for evaluation of known anomalies, 6.1 for maintenance across the lifecycle, and clause 8 for configuration management.

Do transitive dependencies need to be documented as SOUP?

Yes, and overlooking them is the most common identification failure. Many manufacturers document only the obvious components — the operating system, a major library — while the libraries those libraries depend on go unrecorded. A single package can pull in dozens of transitive dependencies, each of which is technically SOUP. Automated software composition analysis is the practical way to find them all.

What is the difference between a SOUP list and an SBOM?

In practice they are the same inventory seen from two regulatory traditions. The SOUP list is the IEC 62304 term for the record of third-party components with their name, version, supplier, intended use, known anomalies and applicable safety class. The Software Bill of Materials is the modern, machine-readable expression of that inventory, in a standardised format such as CycloneDX or SPDX, and it is what the FDA expects in premarket submissions.

Does SOUP management stop when the product is released?

No, and treating it as a development-phase activity is a significant compliance gap and a genuine patient safety risk. IEC 62304 requires monitoring throughout the product’s commercial lifetime: tracking vendor advisories and vulnerability disclosures, monitoring the CVE database, evaluating whether newly disclosed anomalies pose unacceptable risk, and managing end-of-life situations with a migration plan.

Why must SOUP versions be documented exactly?

Because the anomaly list, the vulnerability profile and the functional behaviour of a component are all version-specific. The known anomalies of version 1.2.3 of a library are not those of version 1.3.0. Documenting a component without its exact version makes the anomaly evaluation unverifiable and is not compliant.

Conclusions

SOUP management under IEC 62304 is not a bureaucratic formality — it is one of the most practically impactful activities in medical device software development. Every third-party component integrated into a medical device is a potential source of safety failures and security vulnerabilities, and the standard’s requirements exist precisely to ensure that manufacturers maintain meaningful control over these risks throughout the entire product lifecycle.

The five-step process outlined here — identification, risk assessment, verification, configuration management and ongoing monitoring — provides a practical framework for building a compliant and audit-ready system. Combined with a well-maintained SBOM and a proactive cybersecurity monitoring process, it forms a robust foundation for long-term regulatory compliance.

As medical device software grows in complexity and connectivity, the importance of SOUP management will only increase. Manufacturers who invest in solid SOUP processes today will be better positioned for regulatory submissions, faster to respond to newly disclosed vulnerabilities, and ultimately better equipped to protect the patients who depend on their devices.

Related articles

• IEC 62304: The Complete Guide to the Medical Device Software Standard
• IEC 62304 Software Verification and Validation: Requirements by Safety Class
• IEC 81001-5-1: Cybersecurity for Health Software
• Medical Device Cybersecurity Testing
• Software Bill of Materials (SBOM) for Medical Devices
• ISO 14971 Risk Management