To evaluate and document SOUP/OTS components for MDR compliance, run seven activities on every third-party software item in the build: identify it as SOUP, record its supplier and version, write the functional and performance requirements the component must meet, analyse the hazards it can contribute to, specify the risk control measures, define how changes to the component will be controlled, and keep the whole record live through release and post-market. The legal basis is MDR Annex I Section 17. The process tool is EN 62304:2006+A1:2015 Sections 5.3, 7, and 8. The cybersecurity layer is EN IEC 81001-5-1:2022. Do the seven steps on every component and the file survives audit. Skip any one and the file does not.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 Section 5.3 requires functional and performance requirements and an environment specification for each SOUP item.
  • EN 62304:2006+A1:2015 Section 7 requires each SOUP item to be analysed for contribution to hazardous situations, with documented risk control measures.
  • EN 62304:2006+A1:2015 Section 8 requires each SOUP item to have an identifier, a supplier, a version, and controlled change history.
  • EN IEC 81001-5-1:2022 adds the cybersecurity lifecycle for third-party components: vulnerability monitoring, patching, end-of-support planning.
  • MDR Annex I Section 17 is the legal obligation that makes both standards binding for software in or as a medical device.
  • The seven steps below are what Notified Bodies look for on every SOUP item, in order, with traceable records.
  • Done in-flight, the evaluation takes minutes per component. Done retrospectively under audit pressure, it takes weeks per component.

Why this needs a structured method

Every medical software team knows they should "document their SOUP" and almost none of them have a repeatable method for doing it. The first audit exposes the gap. Some components have a paragraph of notes in a wiki, some have nothing, some have a spreadsheet row with a version number that no longer matches the build, and the cybersecurity monitoring is an alert channel someone muted two years ago. The reviewer does not argue with any individual entry. The reviewer argues with the absence of a method that produces consistent entries across the full dependency tree.

The seven-step method below is the smallest set of activities that satisfies EN 62304:2006+A1:2015 Sections 5.3, 7, and 8 together with EN IEC 81001-5-1:2022 for cybersecurity, which together operationalise MDR Annex I Section 17 for third-party software. It is designed to run per component in a few minutes once the engineering and regulatory workflow is wired together, and it is designed to produce records that a reviewer can follow without a guided tour. Post 391 covers the underlying standards in more depth; this post is the operating procedure.

Step 1 — Identify the item as SOUP/OTS

The first step is binary. For every software item in the build, decide whether it meets the SOUP definition in EN 62304:2006+A1:2015 Section 3.29: a software item already developed and generally available, not developed for the purpose of being incorporated into the medical device, or a previously developed software item for which adequate records of the development processes are not available.

In practice, any component the team did not develop under its own EN 62304:2006+A1:2015 lifecycle is SOUP. Operating system: SOUP. Compiler and language runtime when linked into the product: SOUP. Standard libraries, web frameworks, database engines, cryptographic libraries, image and DICOM libraries, machine learning runtimes, cloud SDKs, open source packages at every level of the dependency tree: all SOUP. Write the identification down once, at the level of the component and all its transitive dependencies. The identification is what justifies applying the SOUP lifecycle steps; it is also the answer to the audit question "which items in your build are SOUP?"

The output of this step is a line on the SOUP inventory for each component. Generated from the build, not hand-typed. Ideally expressed as an SBOM in SPDX or CycloneDX format, because that is the form the rest of the steps will consume.

Step 2 — Document supplier and version

For each SOUP item, record four fields: the identifier (the canonical name the supplier uses), the version (exact, pinned, matching the build), the supplier (the upstream organisation or project), and the source (where the component comes from — a package registry, a vendor distribution, a git URL and commit hash). EN 62304:2006+A1:2015 Section 8 requires the identifier, version, and supplier designation; the source location is good engineering practice and makes the record auditable.

Two rules matter. Versions must be pinned to the exact version shipped, not to a floating range. An entry that says "^1.4.0" in a dependency file is not a configuration management record; the entry in the SOUP file is the resolved version that is actually in the build artefact. Transitive dependencies count. The framework at the top of the tree is SOUP, and so is every library it pulls in. The SBOM walks the full tree; the configuration management record pins every node of it.

The output of this step is a complete, current component inventory. If the build changes, the inventory changes. The link from build to inventory is automated — the cost of doing this by hand across hundreds of dependencies is the reason most files collapse under audit.

Step 3 — Document the requirements the component must meet

This is the EN 62304:2006+A1:2015 Section 5.3 step, and it is where most SOUP files are thin. The standard requires the manufacturer to specify functional and performance requirements for the SOUP item, and to specify the hardware and software environment the SOUP item requires to deliver those requirements.

The content is not a re-documentation of the upstream project. The content is: what is this component used for in this specific device, what behaviour does the device depend on, and what does the component need around it to behave that way. A short paragraph per component is usually sufficient, structured around four questions. What does the device use this component for — a concrete use, not "miscellaneous utilities." Which specific functions, APIs, or behaviours does the device depend on — named, not "general functionality." What inputs does the device pass to the component, and what outputs does it consume. What operating environment does the component assume — OS version, runtime version, hardware, network, configuration.

The output is a requirements record per component that a reviewer can trace from the device's intended use down to a specific API call on a specific version of a specific library. This is the record that makes the rest of the risk analysis possible; without it, the risk analysis has nothing to analyse.

Step 4 — Document the hazards the component can introduce

This is the EN 62304:2006+A1:2015 Section 7 step, and it is the one the Notified Body will examine hardest. The standard requires the manufacturer to identify the software items, including SOUP, that could contribute to hazardous situations identified in the EN ISO 14971:2019+A11:2021 risk file, and to document the potential causes of the contribution.

The analysis is per component and per hazardous situation, not per component alone. For each SOUP item, ask: which hazardous situations in the ISO 14971 file could this component contribute to, through which failure modes. The failure modes that have to be considered for SOUP typically include: the component crashes or stops responding; the component returns wrong or corrupted output; the component returns stale or cached output when fresh output is required; the component silently changes behaviour across versions; the component exhausts resources (memory, file handles, CPU); the component is compromised by a security vulnerability and produces unsafe or unauthorised behaviour.

A SOUP item with no plausible path to any hazardous situation is identified, stated as such, and left without a deep analysis — the standard does not require analysis of items that cannot contribute. A SOUP item with one or more plausible paths gets the full treatment: failure modes named, hazards linked, causation explained. Generic statements like "library could fail, risk low" are not an analysis; they are placeholders a reviewer will flag every time.

The output of this step is, for each relevant SOUP item, an entry in the risk management file linked by identifier to the SBOM and by hazard ID to the ISO 14971 hazard register.

Step 5 — Document the risk control measures

For each SOUP item that can contribute to a hazardous situation, EN 62304:2006+A1:2015 Section 7 requires risk control measures. Controls can live in three places: inside the SOUP (configuration or feature selection that removes the failure mode), around the SOUP (wrapper code in the first-party software that validates inputs, checks outputs, sandboxes, handles errors), or outside the software entirely (hardware interlocks, procedural controls, clinical monitoring — the ISO 14971 full hierarchy).

For each control, record what the control does, where it lives in the code or the system, how it is verified, and what residual risk remains after it is applied. The verification link matters: a control that is named but not tested is not a control. The residual risk feeds back into the ISO 14971 evaluation and, if necessary, into the decision to accept the residual risk or add further controls.

Cybersecurity controls under EN IEC 81001-5-1:2022 belong in this step too when the failure mode is security-relevant. A SOUP item that parses untrusted input from the network, handles cryptography, or processes patient data carries security risk alongside safety risk, and the controls — input validation, bounds checking, authenticated transport, sandboxing, principle of least privilege — are documented the same way.

The output is a control record per SOUP item per hazard, with residual risk, verification evidence, and traceability to the first-party code that implements the control.

Step 6 — Define the change control approach

SOUP changes. Upstream projects release new versions, ship security patches, deprecate APIs, and occasionally disappear. The change control approach has to handle all of that without forcing a full lifecycle re-run on every minor version bump and without letting unevaluated changes reach the release.

The pattern the standards support is classified change control. Trivial changes — patch releases with only security fixes in modules the device does not use — go through a lightweight evaluation that confirms the classification and records the update. Substantive changes — minor or major version bumps, API changes, behaviour changes in functions the device depends on, changes to the operating environment — trigger a full evaluation covering requirements impact (Step 3), risk impact (Step 4), control impact (Step 5), verification impact, and regression test planning. Changes that alter the intended use or the safety behaviour of the device escalate into the change-to-the-device analysis under the broader QMS.

For cybersecurity updates, EN IEC 81001-5-1:2022 adds the vulnerability monitoring cadence. Every SOUP item on the SBOM is cross-referenced against public vulnerability sources (CVE databases, vendor advisories, distribution security lists) on a documented cadence. A new relevant vulnerability triggers a risk evaluation and, where needed, a patch, a compensating control, or a user communication. MDCG 2019-16 Rev.1 sits alongside this and makes clear the manufacturer cannot transfer cybersecurity responsibility to the upstream project.

The output of this step is a change control record and a vulnerability monitoring log, both live, both feeding back into Steps 3, 4, and 5 when anything changes.

Step 7 — Common mistakes to avoid on every component

The following mistakes appear on almost every file we see on a first pass. Catching them per component, at evaluation time, is cheaper than catching them at audit.

  • Treating the OS, runtime, or cloud platform as "not SOUP." All of them are SOUP. Every one belongs in the inventory, the requirements record, the risk analysis where relevant, the change control, and the vulnerability monitoring.
  • Unpinned versions in the SOUP record. A floating version range is not a configuration management record. The SOUP entry is the resolved version that is actually in the shipped build.
  • Requirements written at the level of "we use library X for general utility functions." That sentence is not a requirements record. Name the specific functions, the inputs and outputs, and the environment assumptions.
  • Generic risk entries copied across components. A copy-paste risk entry with the library name changed is not a risk analysis. Each entry has to be specific to the failure modes of the component in its actual role.
  • Controls named but not verified. A control that cannot be pointed at in the test evidence is not a control. The verification link is part of the record, not a footnote.
  • Vulnerability monitoring set up once and then ignored. A subscription that nobody reads is not a monitoring process. The cadence has to be defined, the responsibility has to be named, and the response has to have happened on record for real vulnerabilities that have landed.
  • Separating open source and commercial SOUP into different processes. The lifecycle activities are the same. The difference is who the supplier is and how the monitoring works, not whether the obligations apply.

The Subtract to Ship angle

The seven steps look like overhead. They are the opposite. The overhead is reconstructing the SOUP file under audit pressure across a dependency tree that has been growing unmanaged for two years. The subtraction is doing the seven steps in-flight, per component, at the moment the component is added to the build.

Subtract to Ship cuts in two places on SOUP evaluation. The first is cutting SOUP that does not earn its place. A component added for a day of convenience that carries hundreds of transitive dependencies behind it costs more to keep in the file than it saved in engineering. The evaluation activities on that component, multiplied over its dependency tree, are the real cost of the decision. Make the decision consciously. The second is scoping the medical module narrowly so the SOUP inside the regulated boundary is the smallest set honestly possible — every component outside the regulated boundary still has to be secure and well-run, but the full EN 62304:2006+A1:2015 treatment only applies to what is inside. That is the same subtraction move the lifecycle pillar describes in post 376, and the broader framework in post 065.

The test at the end of every evaluation is the same as the final test of the framework: can every SOUP item in the file, and every activity performed on it, be traced to a specific clause of EN 62304:2006+A1:2015, EN IEC 81001-5-1:2022, or MDR Annex I Section 17? If yes, it stays. If no, cut the component or cut the activity.

Reality Check — Can you run this on your current build?

  1. Can you produce a current SBOM of your device software from the build, in SPDX or CycloneDX format, in minutes?
  2. For every component in the SBOM, is there a supplier and pinned version record that matches the actual build artefact?
  3. For every SOUP item, is there a requirements record that names what the device uses it for, which specific behaviours it depends on, and the environment it assumes, under EN 62304:2006+A1:2015 Section 5.3?
  4. For every SOUP item that could contribute to a hazardous situation, is there an entry in the EN ISO 14971:2019+A11:2021 risk file linked by component identifier, with named failure modes and causation, under EN 62304:2006+A1:2015 Section 7?
  5. For every such entry, are the risk control measures documented, located in the code or the system, verified, and recorded with residual risk?
  6. Is there a change control approach that classifies SOUP updates by impact and runs the right level of re-evaluation before a change reaches release?
  7. Is vulnerability monitoring running on a defined cadence, aligned with EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1, with evidence that real vulnerabilities have been evaluated when they landed?

Any question you cannot answer with a clear yes is a per-component gap multiplied across the dependency tree, and the gap grows with every release until it is closed.

Frequently Asked Questions

How detailed does the requirements record for a SOUP item need to be under EN 62304:2006+A1:2015 Section 5.3? Detailed enough to answer four questions per component: what the device uses it for, which specific behaviours the device depends on, what inputs and outputs the interface carries, and what operating environment the component assumes. A short structured paragraph per component is usually sufficient. The test is whether a reviewer can trace from the device's intended use down to a specific function call on a specific version of the component.

Does every SOUP item need a full risk analysis? No. EN 62304:2006+A1:2015 Section 7 requires the analysis for SOUP items that could contribute to a hazardous situation identified in the EN ISO 14971:2019+A11:2021 risk file. SOUP items with no plausible path to any hazardous situation are identified and stated as such without a deep analysis. The identification itself is documented, so the reviewer can see the decision was made.

How often should vulnerability monitoring run for SOUP items? EN IEC 81001-5-1:2022 requires a documented cadence aligned with the risk of the device and the speed at which vulnerabilities are published. In practice, a daily or weekly automated cross-reference of the SBOM against CVE sources and vendor advisories, with a defined escalation path for relevant findings, is the cadence most Notified Bodies accept. The cadence has to be written down and actually followed.

Can I use a generic SOUP risk assessment template across all components? No. A generic template can be the structure of the record, but the content has to be specific to each component and its actual use in the device. Copy-paste risk entries with only the component name changed are a common audit finding and do not demonstrate the analysis the standard requires. The failure modes, the hazards they contribute to, and the controls are different for every component.

What happens if a SOUP component has no upstream support? EN IEC 81001-5-1:2022 requires an end-of-support plan. The options are to migrate to a supported alternative, to fork and bring the code under the manufacturer's own full EN 62304:2006+A1:2015 lifecycle (which ends the SOUP status), to remove the functionality, or to retire the device. An unmaintained component on a live device is a cybersecurity liability the moment the next relevant vulnerability lands, and the plan has to exist before that moment.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17, including Section 17.2 and Section 17.4. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Sections 3.29 (SOUP definition), 5.3 (software requirements analysis, SOUP requirements and environment), 7 (software risk management), 8 (software configuration management).
  3. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle (IEC 81001-5-1:2021). Cybersecurity lifecycle for third-party components.
  4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
  5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  6. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices. December 2019; Rev.1 July 2020.

This post is a category-9 how-to in the Subtract to Ship: MDR blog, focused on the per-component evaluation and documentation method that satisfies the SOUP/OTS obligations of EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022 under MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star — the harmonised standards are the tools that provide presumption of conformity, not independent authorities. For startup-specific regulatory support on SOUP evaluation, SBOM generation, and cybersecurity lifecycle implementation, Zechmeister Strategic Solutions is where this work is done in practice.