> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withdovetail.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SOUP List
> Document third-party software components with risk assessments ensuring safe integration and regulatory compliance.
## Summary
The Software of Unknown Provenance (SOUP) List documents all third-party software components, libraries, and off-the-shelf software used in your medical device. This document provides risk assessments, version control, and requirements for each SOUP item to ensure safe integration and regulatory compliance.
## Why is SOUP List important?
SOUP components represent potential **points of failure** in your medical device that are outside your direct control. Regulatory authorities require comprehensive documentation of all third-party software because these components can introduce **unknown risks** to patient safety. The SOUP list demonstrates that you have systematically identified, assessed, and controlled risks associated with external software dependencies.
Without proper SOUP documentation, you cannot demonstrate that your device is safe or that you understand all potential failure modes. The SOUP list also enables **ongoing monitoring** for security vulnerabilities and updates that might affect your device's safety and effectiveness throughout its lifecycle.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **IEC 62304:2006**:
* All SOUP must be **identified and documented** with risk assessments
* **Functional and performance requirements** must be specified for medium/high-risk SOUP
* Must demonstrate **systematic evaluation** of SOUP risks
* **Version control** and change management required for all SOUP
**Special attention required for:**
* Cybersecurity vulnerabilities in SOUP components
* FDA Software as Medical Device guidance compliance
* Software Bill of Materials (SBOM) requirements
* Ongoing monitoring and update procedures for SOUP
Under **EU MDR 2017/745** and **IEC 62304:2006**:
* SOUP must be managed according to **IEC 62304** software lifecycle processes
* **Risk management** per ISO 14971 required for all SOUP components
* Must demonstrate **systematic approach** to SOUP identification and control
* **Cybersecurity requirements** per MDR Article 17 apply to SOUP
**Special attention required for:**
* SOUP classification impacts software safety classification
* Data protection requirements (GDPR) for SOUP handling personal data
* Post-market surveillance obligations for SOUP vulnerabilities
* Notified body assessment of SOUP risk management
## Guide
### Understanding SOUP
**Software of Unknown Provenance (SOUP)** is any software that your team did not create or that wasn't created specifically for your medical device but is nonetheless part of your medical device. SOUP includes:
* **Third-party libraries and frameworks** (React, NumPy, TensorFlow)
* **Off-the-shelf software** (operating systems, databases, authentication services)
* **Cloud services** that are integral to your device's medical functionality
* **Open source components** and commercial software packages
### SOUP vs Non-SOUP Determination
Not all third-party software is SOUP. Software is only considered SOUP if it is **used as part of your medical device** to achieve the intended medical purpose. For example:
**SOUP Examples:**
* Authentication service that controls access to patient data
* Machine learning library used for medical diagnosis
* Database storing critical patient information
* Communication protocol for medical device connectivity
**Non-SOUP Examples:**
* Marketing website hosting service
* Development tools not included in the final product
* Administrative software for billing or scheduling
* Non-medical notification systems
### SOUP Risk Classification
Classify each SOUP component based on potential patient impact:
**Low Risk**: SOUP malfunction is unlikely to lead to patient or user harm
* Example: UI styling libraries, non-critical logging components
**Medium Risk**: SOUP malfunction has potential to lead to reversible patient or user harm
* Example: Data validation libraries, communication protocols
**High Risk**: SOUP malfunction has potential to lead to irreversible patient or user harm
* Example: Medical calculation algorithms, critical data storage systems
### Documentation Requirements
For **all SOUP items**, document:
* **SOUP ID**: Unique identifier for tracking
* **Software Item**: Which part of your architecture uses this SOUP
* **Name and Version**: Exact version numbers (must be pinned, not auto-updating)
* **Manufacturer/Source**: Who developed or maintains the SOUP
* **Description**: What the SOUP does in your system
* **Risk Level**: Low, medium, or high based on patient impact
* **License**: Legal terms governing SOUP use
For **medium and high-risk SOUP**, additionally document:
* **Functional Requirements**: What the SOUP must do for your device to function
* **Performance Requirements**: Speed, accuracy, or capacity requirements
* **System Requirements**: Hardware and software needed to support the SOUP
### Version Control and Monitoring
**Pin all SOUP versions** to prevent automatic updates that could introduce unknown risks. Establish monitoring procedures:
* **High-risk SOUP**: Review every 6 months for vulnerabilities and updates
* **Medium-risk SOUP**: Review annually
* **Low-risk SOUP**: Review every 2 years
Monitor security advisories, vulnerability databases, and manufacturer notifications for all SOUP components.
## Example
**Scenario**: You're developing a diabetes management app that processes glucose readings, provides insulin dosing recommendations, and stores patient data. You need to identify and assess all SOUP components used in your system.
### SOUP List
| SOUP ID | Software Item | SOUP Name | Version | Manufacturer | Description | Risk Level | License | Requirements |
| -------- | ------------- | ---------------- | ------- | ----------------------------------- | ----------------------------------- | ---------- | ------------------ | --------------------------------------------------------------------------------------------------------------------- |
| SOUP-001 | Mobile App | React Native | 0.72.4 | Meta | Cross-platform mobile app framework | Low | MIT | UI rendering and navigation functionality |
| SOUP-002 | Backend | Express.js | 4.18.2 | OpenJS Foundation | Web application framework | Medium | MIT | HTTP request handling, API routing, requires Node.js runtime |
| SOUP-003 | Backend | bcrypt | 5.1.0 | Kelvin Sherlock | Password hashing library | High | Apache-2.0 | Secure password hashing for user authentication, must provide cryptographic security equivalent to 256-bit encryption |
| SOUP-004 | Database | PostgreSQL | 15.3 | PostgreSQL Global Development Group | Relational database system | High | PostgreSQL License | Patient data storage with ACID compliance, backup and recovery capabilities, encryption at rest |
| SOUP-005 | Backend | jsonwebtoken | 9.0.2 | Auth0 | JWT token implementation | High | MIT | Secure user session management, token expiration handling, cryptographic signature validation |
| SOUP-006 | Mobile App | React Navigation | 6.1.7 | React Navigation Contributors | Navigation library for React Native | Low | MIT | Screen navigation and routing functionality |
| SOUP-007 | Backend | Helmet.js | 7.0.0 | Adam Baldwin | Security middleware for Express | Medium | MIT | HTTP security headers, XSS protection, requires Express.js compatibility |
### Risk Assessment Summary
**High-Risk SOUP (3 items)**: These components handle critical security functions (authentication, data storage) and medical calculations. Failure could lead to data breaches or incorrect medical recommendations.
**Medium-Risk SOUP (2 items)**: These components handle data processing and security but have lower direct patient impact. Failure could disrupt service but is unlikely to cause direct patient harm.
**Low-Risk SOUP (2 items)**: These components handle user interface functions. Failure would affect usability but not patient safety or data security.
## Q\&A
A SOUP list requires a complete inventory of all third-party dependencies, documenting versions and licenses. Start with your package manager files (package.json, requirements.txt, etc.) to identify dependencies. Include off-the-shelf software and cloud services that are integral to your medical device functionality. Perform a risk assessment for each component based on potential patient impact if the SOUP fails.
Third-party software can be integrated as a medical device system module, listed as a supplier, and added to architecture documentation. Create specific subsystem requirements for third-party components and maintain your current device classification. Document all third-party software in your SOUP list with appropriate risk assessments.
SOUP (Software of Unknown Provenance) is any third-party software used in your medical device, while Off-The-Shelf (OTS) software refers to commercially available software packages. OTS becomes SOUP when it's used as part of your medical device to achieve the intended medical purpose. Not all OTS is SOUP - only the components that contribute to medical functionality.
All SOUP versions must be pinned to prevent automatic updates. When updates are needed, treat them as design changes requiring impact assessment, testing, and documentation updates. Evaluate security patches promptly but implement them through your change control process. High-risk SOUP updates require more extensive verification than low-risk updates.
Document all SOUP components with their **name, version, source, and functional purpose**. Include risk classification based on potential impact if the SOUP fails. For medium and high-risk SOUP, specify functional and performance requirements, system dependencies, and verification approaches. Maintain the SOUP list as a living document updated with each software release.
Establish ongoing monitoring procedures based on risk level. Subscribe to security advisories from SOUP manufacturers, monitor vulnerability databases (CVE, NVD), and use automated scanning tools where appropriate. High-risk SOUP requires quarterly review, medium-risk annual review, and low-risk biannual review. Document all vulnerability assessments and remediation actions.