By AptSkill MedTech | IEC 62304 Compliance | Reading time: 8 min
If your medical device incorporates any third-party software — an open-source library, a commercial SDK, an operating system, or an off-the-shelf algorithm — you have SOUP. And if you have SOUP, you need a SOUP assessment. That much most regulatory teams know.
What catches teams off guard is not the existence of the requirement, but the depth of documentation auditors actually expect. SOUP assessment is one of the most frequently cited gaps in IEC 62304 audits, and the mistakes that trigger those findings are almost always the same ones. This article walks through what a proper SOUP assessment looks like, where teams go wrong, and how to get it right the first time.
What Is a SOUP Assessment, and Why Does IEC 62304 Require It?
SOUP stands for Software of Unknown Provenance — any software component that was not developed specifically for your medical device, or for which complete development process records are unavailable. The definition is deliberately broad. It covers:
- Open-source libraries (Python packages, JavaScript dependencies, C++ frameworks)
- Commercial off-the-shelf (COTS) software
- Operating systems and middleware
- Third-party algorithms and signal processing tools
- Legacy software incorporated from prior projects
The reason IEC 62304 demands formal assessment of these components is straightforward: you did not write them. You cannot audit their development processes, you cannot guarantee their test coverage, and you cannot control when bugs are introduced or how vulnerabilities are patched. A key risk SOUP poses is that it cannot be relied upon to perform safety-related functions, and it may prevent other software, hardware or firmware from performing their own safety-related functions.
The standard’s answer to this is not to ban SOUP — virtually every modern medical device uses it, and prohibiting it would be impractical. Instead, IEC 62304 requires manufacturers to formally document what they need the SOUP to do, assess the risks it introduces, verify that it meets those needs through testing, and monitor it throughout the device’s lifetime.
IEC 62304 considers SOUPs to be software components. Manufacturers must specify the requirements for SOUPs as they would for any other component, and test their fulfilment. In addition, manufacturers must also specify the prerequisites on which a SOUP can be based — for example, with regard to resources such as RAM and CPU, or the operating system.
The 5 Most Common SOUP Assessment Mistakes (and How to Fix Them)
1. Treating SOUP Documentation as a Checkbox Exercise
The single biggest mistake teams make is creating a SOUP list that names components and versions — and nothing else. A version number is not a SOUP assessment. It is a starting point.
What auditors actually look for is evidence that you thought critically about each SOUP item: what it needs to do for your device, what happens if it fails, how you verified it works in your specific context, and how you will know if something goes wrong after market release.
A one-line entry in a spreadsheet tells an auditor that you know the SOUP exists. A completed SOUP assessment form tells them you have managed the risk it introduces.
Fix it: For each SOUP item, document functional requirements (what it must do), performance requirements (speed, accuracy, reliability thresholds), hardware and software prerequisites, known anomalies, a cybersecurity CVE review, safety classification, and a verification approach. This is precisely what IEC 62304 Clauses 5.3.3, 7.1.2, and 5.3.4 require.
2. Skipping the Functional Requirements Definition
The IEC 62304 requires manufacturers to specify the requirements for the SOUP. You cannot rely on the SOUP vendor’s general claims — you must define what your device requires the SOUP to do. If the SOUP fails, what functionality is lost?
This is where many teams stumble. They document that they are using, say, a particular database library, but they never specify what that library must do in the context of their device. Saying “we use SQLite for data storage” is not a requirement. Saying “the SOUP shall reliably store patient records up to 1GB and return query results in under 200ms” is a requirement.
The requirement needs to be specific enough that you could design a test against it — because you will need to do exactly that in your verification strategy.
Fix it: Write at least one functional requirement and one performance requirement per SOUP item, using the format: “The SOUP shall [do X] [under conditions Y] [within threshold Z].” Reference these requirements later in your verification section.
3. Ignoring the Anomaly and Cybersecurity Review
IEC 62304 Clause 7.1.2 requires you to review known anomalies — bugs — for each SOUP item and assess their impact on your device. For open-source components, this means checking public issue trackers. For commercial software, it means reviewing vendor release notes and security advisories.
Many teams skip this entirely, or perform it once at the time of initial selection and never revisit it. Both approaches create audit findings and, more importantly, genuine patient safety risk.
Cybersecurity vulnerabilities are particularly consequential. When it comes to risk evaluation, you should consider OTS software items as any other items in your software system and make sure they are included in the software risk assessment, assessing how they can contribute to hazardous situations. A CVE in a networking library used by your device is not a hypothetical risk — it is a documented, exploitable weakness that your assessment must either mitigate or justify.
Fix it: For each SOUP item, perform and document a CVE search against the National Vulnerability Database (NVD) at the time of assessment. Record whether critical CVEs were found. If they were, document your mitigation — for example, sandboxing the component, restricting network access, or selecting a patched version. Assign a reviewer and a review cadence for post-market monitoring.
4. Misclassifying the SOUP Safety Class
IEC 62304 requires you to classify each SOUP item as Class A, B, or C based on the severity of harm that could result from its failure. This classification determines how rigorously you must document and test it.
Because SOUPs are software components, they inherit the safety class of the surrounding software system or software item. However, this safety class only regulates the scope of the documentation to be created.
Teams commonly under-classify SOUP items, either because they want to reduce documentation burden or because they have not thought carefully about failure modes. An auditor will ask: if this component fails silently, what is the worst-case outcome for the patient? If the answer involves injury or death, the classification is almost certainly Class B or C — regardless of how peripheral the component seems.
Fix it: Document your safety class determination with a rationale. Do not just assert a class — explain why. For example: “Failure of this library causes incorrect calculation of drug dosage recommendations. Classified as Class C.” The rationale is what auditors read most carefully.
5. No Post-Market Surveillance Plan for SOUP
Your responsibility for SOUP does not end at submission. You need a procedure to evaluate and implement upgrades, bug fixes, patches, and obsolescence of SOUP items. Whenever you change SOUP, you need to check whether those changes impact medical device safety and existing risk control measures.
Most teams document their initial SOUP assessment thoroughly but have no defined process for monitoring the SOUP after market release. If a critical CVE is published for a library your device uses two years post-launch, who finds out? How quickly? What is the escalation path? Without answers to these questions documented in your QMS, you have a gap — and it will surface in post-market surveillance audits.
Fix it: For each SOUP item, define a monitoring method (e.g., CVE database subscription, vendor mailing list), a responsible role, and an update strategy. Document what constitutes a trigger for re-assessment — for example, any new critical or high-severity CVE, or a major version change by the vendor.
What a Complete SOUP Assessment Covers
A properly structured SOUP assessment document includes all of the following:
Section 1 — SOUP Identification: Name, version number, vendor or source, license type. This section anchors the assessment to a specific, traceable version of the software.
Section 2 — Intended Use and Requirements (IEC 62304 Cl. 5.3.3): Functional requirements defining what the SOUP must do for your device. Performance requirements defining speed, accuracy, and reliability thresholds. Hardware and software prerequisites (minimum RAM, OS version, runtime environment).
Section 3 — Risk and Anomaly Assessment (IEC 62304 Cl. 7.1.2): Review of known bugs from vendor documentation or public issue trackers. CVE cybersecurity review with findings and mitigations. Safety class determination (A, B, or C) with documented rationale.
Section 4 — Verification Strategy (IEC 62304 Cl. 5.3.4): A description of how you will test that the SOUP meets the requirements defined in Section 2. Because you treat SOUP as a black box, verification focuses on interface testing — confirming that inputs produce the expected outputs under defined conditions.
Section 5 — Post-Market Surveillance: Monitoring method and frequency. The responsible role within your organisation. Update and patch strategy. Vendor obsolescence risk assessment.
Approvals: Sign-off fields for the roles responsible for reviewing and approving the assessment, with dates.
SOUP vs. OTS: A Common Point of Confusion
Teams working across both IEC 62304 and FDA submissions frequently encounter confusion between SOUP (the IEC 62304 term) and OTS — Off-the-Shelf Software (the FDA term). The concepts overlap but are not identical.
The FDA and IEC 62304 both recognise software developed by third parties, but their approaches differ. The FDA uses a risk-based approach to scale its demands for OTS software, while IEC 62304 is less prescriptive about specific activities, instead focusing on documentation of requirements and verification.
For FDA submissions, the 2023 guidance on Off-The-Shelf Software introduced a two-tier documentation level system (Basic and Enhanced) that replaced the previous Level of Concern framework. If you are submitting to both FDA and under EU MDR, your SOUP assessment documentation needs to satisfy both frameworks — which is achievable with a single well-structured form, but requires deliberate design.
How Teams Use a SOUP Assessment Template
Starting a SOUP assessment from a blank page is slow, inconsistent, and risks missing required fields. The consequence of a missing field is not just an audit observation — it can delay a submission by weeks while the gap is remediated.
A well-designed SOUP assessment template solves this by giving your team a pre-structured document that maps directly to IEC 62304 clauses. The template should include:
- Pre-written guidance text for each section, so engineers understand what level of detail is expected
- Example entries that show the format and specificity auditors look for
- The complete CVE review checklist
- A safety class determination section with space for rationale
- Post-market surveillance fields built in
The result is that every SOUP assessment your team produces — whether for your first device or your thirtieth — is consistent, complete, and audit-ready.
Ready to Assess Your SOUP Properly?
If you are working through IEC 62304 compliance and need a SOUP assessment document that covers every required section, the AptSkill SOUP Assessment Form is available as an instant, editable .docx download.
It covers all five IEC 62304 sections, includes pre-filled guidance and worked examples, and comes with a CVE cybersecurity review checklist built in. One-time purchase, team-wide license, $49.
Download the SOUP Assessment Form Template →
AptSkill MedTech publishes practical guides for medical device engineers and regulatory affairs professionals navigating IEC 62304, EU MDR, and FDA software compliance.