Per IEC 62304 clause 3.29, SOUP is a software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as OTS - off-the-shelf software), or a software item previously developed for which adequate records of the development processes are not available. Common examples: operating systems, compilers, open-source libraries, third-party SDKs, and firmware components.

Why it matters

IEC 62304 clauses 5.3.3, 5.3.4, 7.1.2, and 7.1.3 impose specific obligations: identify the SOUP item (title, version, manufacturer), specify functional and performance requirements, document hardware and software requirements, evaluate anomaly lists published by the SOUP supplier, and address SOUP-related hazards in the risk file. FDA's 2023 Cybersecurity in Medical Devices guidance and Section 524B further require every SOUP component to appear in the SBOM (SPDX or CycloneDX), be monitored for vulnerabilities throughout the device lifecycle, and have a coordinated disclosure and patch plan. Notified Bodies routinely audit SOUP evaluation as part of QMS surveillance.

Common pitfalls

•Listing SOUP only in the SBOM but not evaluating anomaly lists or writing SOUP-specific requirements. IEC 62304 requires both.
•Treating an internally reused legacy component as 'in-house' when development records are inadequate - it is SOUP by definition.
•Not re-evaluating SOUP after a version bump. Any SOUP change triggers a change impact analysis under IEC 62304 clause 6.
•Missing SOUP in Class C software items where clause 5.3.4 requires additional performance requirements and hardware requirements to be specified.
•Assuming an FDA-cleared SOUP inherits regulatory status - it does not; the device manufacturer remains responsible.

Sources

IEC 62304:2006/AMD1:2015 · ISO
FDA Cybersecurity in Medical Devices (2023) · FDA
MDCG Software Guidance · MDCG

Open full page

Select term B to compare.

Why compare MedTech terms side by side?

MedTech terminology is full of pairs that look interchangeable but carry very different regulatory, clinical, and commercial consequences. Picking the wrong framework, pathway, or standard early in a project can add months to a submission, invalidate clinical evidence, or trigger an audit finding. Side-by-side comparison is the fastest way to surface those differences before they become costly mistakes.

Each comparison on this page pulls from the same vendor-neutral, sourced definitions used throughout the MedTech Terms glossary. You see the one-line summary, the formal definition, why it matters in practice, common pitfalls, and the primary sources (FDA guidance, EU MDR/IVDR articles, ISO/IEC standards, MDCG documents, IMDRF principles) that back each entry. That makes the comparison defensible in regulatory strategy memos, design reviews, and submission narratives.

Common comparison patterns

Regulatory pathway choice - 510(k) vs PMA, 510(k) vs De Novo, Abbreviated vs Special 510(k).
Quality systems - QSR vs ISO 13485, QMSR vs QSR.
Software classification - SaMD vs SiMD, Locked vs adaptive AI.
EU frameworks - MDR vs IVDR, CE Mark vs UKCA.
Cybersecurity artifacts - SPDX vs CycloneDX SBOM, CVE vs CVSS.
Post-market actions - Recall vs field action, Removal vs correction.

How to use this tool

Pick term A and term B from the dropdowns, or click a preset above. The URL updates with both slugs so you can bookmark or share the exact comparison with a colleague, a notified body reviewer, or your regulatory consultant. Click Open full page on either side for the complete entry, including FAQs, related terms, and the full citation list. If you are not sure which term to start with, browse the Categories view or the A-Z index.

MedTech Terms is a vendor-neutral community resource sponsored by Blue Goat Cyber. Definitions are written for educational use and are not legal or regulatory advice.