1. What Is a SOUP Assessment?

A SOUP assessment is a structured evaluation of any pre-existing software component used in a medical device. SOUP — Software of Unknown Provenance — refers to software developed outside your organisation’s quality management system. That doesn’t mean the software is obscure or untrusted. PostgreSQL, TensorFlow, OpenSSL, the Linux kernel — all of these are SOUP. The point is that they weren’t built under your QMS, and IEC 62304 requires you to formally document what each component must do, what risks it introduces, and how you’ve verified it meets your requirements.

Components that require assessment include open-source libraries, commercial off-the-shelf (COTS) SDKs, operating systems and middleware, hardware drivers and BSPs, legacy in-house code developed before your QMS was established, and AI/ML model components. If the software lives in your device and you didn’t develop it under your own quality processes, it’s SOUP.

2. Why It Matters for FDA and EU MDR Submissions

Incomplete SOUP documentation is among the most frequent causes of FDA deficiency letters and EU MDR technical file rejections by Notified Bodies. The consequences reach well beyond paperwork: delayed market entry, expensive remediation rounds, and in some cases complete re-documentation of the software file — weeks of senior engineering and regulatory affairs time that most teams can’t afford mid-submission.

Reviewers look for specific evidence at each stage of the SOUP lifecycle. A missing CVE reviewer name and date, or requirements that don’t trace to test cases, is enough to generate a finding. Here’s how the major frameworks map to SOUP:

“We were scrambling to put SOUP documentation together before an FDA submission. This template saved us at least two days of work and the auditor had zero questions about our SOUP section.”

— Quality Engineer, Class II Device Manufacturer

3. SOUP in the SaMD Era

Software as a Medical Device has fundamentally changed the scale of the SOUP problem. A traditional hardware device might incorporate one or two commercial SDKs. A modern cloud-connected diagnostic platform may depend on dozens of open-source libraries, containerised services, third-party APIs, and pre-trained AI models — each requiring its own documented assessment.

The IMDRF SaMD framework classifies software-only devices across two dimensions: the state of the healthcare situation (critical, serious, or non-serious) and the significance of information provided (treat or diagnose, drive clinical management, or inform clinical management). The resulting risk category directly shapes how thorough each SOUP assessment needs to be. For high-risk SaMD — an AI-based diagnostic system in an ICU monitor, for example — regulators expect substantially more depth than for a basic data-logging application.

4. What IEC 62304 Actually Requires

IEC 62304 addresses SOUP across four primary clauses. Many teams focus solely on clause 7.1.2 — the anomaly assessment — and miss equally binding requirements in 5.3.3, 5.3.4, and 6.1.

5. How to Conduct a SOUP Assessment: Step by Step

A complete SOUP assessment covers eight stages. Each maps to regulatory requirements, and each needs documented evidence — not just a checkbox.

6. Open Source, COTS, and AI/ML: What Changes?

The IEC 62304 framework applies uniformly to all SOUP types, but the evidence sources and risk considerations differ significantly depending on what you’re assessing.

Open-Source Libraries

Open-source SOUP gives you full source code access — a real advantage for anomaly review. You can inspect code directly, search public issue trackers, and monitor CVEs at the project level. The tradeoffs are real, though: licence obligations (particularly GPL copyleft provisions) can create complications for proprietary code, there’s typically no formal QMS at the community level, and the volume of community-discovered security vulnerabilities can be high. Confirming that licence obligations are managed — especially copyleft contamination risk in a dual FDA + EU MDR context — needs to be explicit in the assessment.

Commercial Off-the-Shelf (COTS) Software

COTS vendors often have a more mature QMS — potentially ISO 13485 certified — but source code is rarely accessible, limiting you to black-box assessment. The SLA evaluation becomes especially important here: you need documented contractual assurance that the supplier will notify you of critical bugs, security patches, and End-of-Life plans within defined timeframes. An SLA without bug and vulnerability notification requirements is insufficient under FDA OTS guidance.

AI/ML Components

Pre-trained models and foundation model APIs introduce challenges that don’t exist for conventional libraries. The assessment must cover training data provenance, the model version and inference environment, and — critically — whether the model changes behaviour post-deployment. Adaptive AI models are a specific regulatory concern: IMDRF guidance indicates that change control for AI/ML must be substantially more rigorous than for static software components.

Legacy In-House Code

Code written by your own team before your QMS was established also qualifies as SOUP — and this is frequently overlooked. The assessment approach is identical to any external component. Familiarity with the codebase doesn’t exempt it from documentation requirements.

7. CVE Cybersecurity Review: The Section Most Teams Fail

The CVE review is the most commonly incomplete section in SOUP documentation packages. Teams either don’t know the right database to search, search the wrong version, or conduct the review once and never revisit it — all of which generate audit findings.

The authoritative source is the National Vulnerability Database at nvd.nist.gov. Every assessment must document a search for the exact version of the component. A search by product name alone isn’t sufficient — a vulnerability may be present in version 1.3.2 but patched in 1.3.3, and your documentation must confirm which applies to your device.

For every CVE identified, record: the CVE identifier, the CVSS score and severity rating, the specific affected component, and a concrete mitigation strategy — patching, architectural isolation, input validation at the API boundary, or a documented risk acceptance with justification referenced to your ISO 14971 risk management file.

8. Safety Classification: Class A, B, and C

The safety class assigned to a SOUP item determines the depth of documentation, testing, and maintenance required throughout the device lifecycle.

The key principle is inheritance: a SOUP item inherits the safety class of the software system it is part of. A logging library embedded inside a Class C drug dosage calculation engine is Class C by default. The only exception is demonstrated architectural segregation — proof through both architecture documentation and test evidence that the SOUP’s failure cannot propagate to the safety-critical function.

Segregation claims are a consistent area of scrutiny. Regulators expect specific architectural mechanisms — container isolation, memory protection, hardware partitioning, watchdog circuits — with corresponding test results confirming they work as claimed. A narrative statement of “logical separation” without test data won’t hold up to a Class C claim.

9. Post-Market Surveillance for SOUP

SOUP assessment doesn’t end at device approval. IEC 62304 Chapter 6 and the IMDRF SaMD post-market framework both require active surveillance for the device’s full commercial lifetime. Four elements need to be defined before launch:

Monitoring Method

Define how new anomalies and CVEs will be detected. The most effective approach combines automated monitoring — NVD API alerts, vendor security mailing lists, GitHub Dependabot or equivalent — with scheduled quarterly manual reviews. Automation catches high-severity CVEs quickly; manual reviews catch softer signals like declining community activity and approaching vendor EOL dates.

Re-Assessment Triggers

Specify the events that require a full re-assessment: new CVEs above your CVSS threshold, major supplier version releases, vendor-announced EOL, newly discovered anomalies with device safety impact, and changes to the device’s intended use or software architecture that touch this SOUP component.

Update and Patch Strategy

Define the patch application policy — for example, critical security patches within 30 days, minor updates quarterly. Every version change must reference your change control SOP and trigger regression testing against the requirements defined in Section 2 of the assessment. Documenting this policy in advance is what separates mature QMS teams from reactive ones.

Obsolescence Risk

Assess at initial review whether the component is likely to become unmaintained before your device reaches end of commercial life. Where medium or high obsolescence risk is identified, document the contingency plan — candidate replacement components and estimated migration timeline — while you still have the runway to act.

10. Seven Common SOUP Assessment Failures in Audits

These are the documentation gaps that most reliably generate FDA deficiency letters and EU Notified Body findings:

• Version imprecision. Writing “latest stable,” a branch name, or a date instead of an exact version number makes CVE database lookups impossible and signals inadequate version control from the outset.
• No requirements traceability. Requirements exist but aren’t assigned unique IDs and aren’t linked to specific test cases. Auditors need to confirm every requirement has a corresponding verification record — a list alone isn’t enough.
• CVE review without evidence. No search was formally documented, the search covered the wrong version, or results were recorded without a reviewer name and date. A blanket “no vulnerabilities found” without NVD search evidence is rejected.
• Unsupported segregation claims. A lower safety class is claimed than the parent system warrants, with no architectural evidence or test data proving segregation. Especially common — and especially scrutinised — in Class C device contexts.
• Missing supplier assessment. No SLA documentation, no vendor QMS status on record, and no contractual arrangements for vulnerability notification. FDA OTS guidance explicitly requires a risk-based supplier assessment.
• One-time CVE review. The cybersecurity assessment was done once at design time with no post-market monitoring plan, no re-assessment triggers, and no assigned responsible role. For devices already on the market, this is a significant finding.
• Form structure not mapped to IEC 62304. SOUP documentation exists but doesn’t correspond visibly to the clause structure auditors check against. Homegrown templates built without regulatory expertise often have gaps that are invisible to the engineering team but immediately apparent to a Notified Body reviewer.

11. The Fastest Way to Get This Right

Working through the requirements above makes clear that a thorough SOUP assessment is manageable — but it has a lot of moving parts, and each one needs to be documented in a way that’s auditable by someone who didn’t write it. That’s where teams lose time: not figuring out what to do, but producing documentation that satisfies a regulator on first review without going back and forth through revision cycles.

The AptSkill MedTech SOUP Assessment Form structures the complete IEC 62304 lifecycle — identification through post-market surveillance — in an editable .docx template, with built-in guidance text at every section, example entries showing the expected level of detail, and a CVE review checklist aligned with NVD database output. It covers all SOUP types: open source, COTS, legacy in-house, and AI/ML components.

At $49 for a full team licence, it replaces at minimum two to three days of senior regulatory and engineering time building equivalent documentation from scratch. For organisations with multiple SOUP items per device — and most modern SaMD products have dozens — the leverage compounds with every assessment.

12. Frequently Asked Questions

→ View and download the SOUP Assessment Form Template