By AptSkill MedTech | IEC 62304 Compliance | Reading time: 9 min
Walk into almost any medical device software team mid-project and ask “do you have any SOUP?” and you will get one of two answers. Either a confident “yes, we have a list,” or a slightly uncertain “I think so — it’s the third-party stuff, right?”
Both answers hide the same problem: most teams do not have a precise, working definition of what SOUP actually is. And without that, they either over-document things that don’t need it, under-document things that do, or — most expensively — discover the gap during an audit.
This article gives you a clear, practical definition of what counts as SOUP under IEC 62304, walks through the grey areas that routinely trip teams up, and explains exactly what documentation each SOUP item requires.
The IEC 62304 Definition — and What It Actually Means
IEC 62304 defines SOUP as:
“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 off-the-shelf software) or software previously developed for which adequate records of the development processes are not available.”
Two distinct categories sit inside that definition, and teams often miss the second one entirely.
Category 1 — Off-the-shelf software: Any software your team did not write specifically for this device. This is the intuitive part. Open-source libraries, commercial SDKs, operating systems, database engines, communication stacks — these are all SOUP.
Category 2 — Software without adequate development records: Software your own organisation wrote, but for which you cannot produce proper development documentation. Code written before your QMS was in place. Software inherited from an acquired company. A module ported from a non-medical product. If you cannot show that it was developed under an IEC 62304-compliant process, it is SOUP — even if your own engineers wrote every line of it.
This second category is the one that surprises teams. It means SOUP is not just about where the software came from. It is about whether you can demonstrate how it was developed.
What Definitively Counts as SOUP
To remove ambiguity, here is a concrete list of software types that are SOUP under IEC 62304:
Operating systems. Windows, Linux, Android, macOS, FreeRTOS, VxWorks — if your team did not develop it, it is SOUP. This applies even if the OS vendor markets it as “safe” or “validated.” Unless you have a formal contract giving you access to their IEC 62304-compliant development records, it is SOUP.
Open-source libraries. NumPy, TensorFlow, OpenSSL, SQLite, Qt, Boost, zlib — any open-source component is SOUP. Being able to read the source code does not change this. Open-source is third-party software that was not developed under your QMS. Access to code is useful for anomaly investigation, but it does not confer IEC 62304 compliance on the library itself.
Commercial SDKs and middleware. Third-party signal processing toolkits, imaging libraries, communication middleware, GUI frameworks. Commercial licensing does not exempt these from SOUP requirements. What matters is the provenance of the development process, not the licensing model.
Hardware drivers provided by chip manufacturers. Even when a microcontroller vendor supplies a BSP (board support package) or peripheral driver library as part of their development kit, those components are SOUP. They were not developed for your device.
Cloud service APIs and platform components. AWS SDKs, Azure IoT libraries, Google Cloud APIs — if your device software calls these interfaces, the client-side libraries are SOUP.
Legacy code your organisation developed before IEC 62304 was in place. If you cannot produce the requirements, design documents, test records, and review evidence that IEC 62304 demands, that code is SOUP regardless of who wrote it or when.
Code from a prior project ported into a new device. Even if the previous project was IEC 62304-compliant, once that software is incorporated into a new device context without full re-development under the new project’s QMS, it typically needs to be treated as SOUP and assessed accordingly.
What Does NOT Count as SOUP
Understanding the boundaries in both directions matters. The following are commonly misidentified as SOUP when they are not:
Software your team developed under your current IEC 62304-compliant QMS for this project. Your own software items, developed with proper requirements, design, implementation, and testing records, are not SOUP. They are first-party software items subject to the standard’s normal development requirements.
Software development tools. IDEs, compilers, debuggers, static analysis tools — these are not SOUP. IEC 62304 does not classify development tools as SOUP; they are covered under separate requirements for the software development environment.
Hardware firmware embedded within a component, with no accessible software interface. If a component contains software that executes internally and your device software cannot directly interact with or influence it, it typically falls outside the SOUP definition. The question is not whether software exists inside a component, but whether your device software treats it as a callable software item.
Third-party software developed under IEC 62304 where you have contractual access to the documentation. If a supplier developed their software under an IEC 62304-compliant process and your contract gives you access to the relevant development records, this software is not technically SOUP — you have the provenance. In practice, this situation is rare, and if you cannot confirm it contractually, default to treating it as SOUP.
The Grey Areas Teams Fight About Most
“We only use a tiny part of the library — do we still need to assess all of it?”
Yes. You assess the SOUP item at the version level, not the function level. If you link against a library, you are incorporating that library into your device. The fact that you call only two of its functions does not limit your exposure to defects in other parts of the codebase — and an auditor will know this. Document the full library as the SOUP item, and define your functional requirements in terms of what you need it to do.
“Our OS vendor says their product is ‘certified’ — does that mean it’s not SOUP?”
Not automatically. The critical question is: certified against what, and do you have access to the documentation? Some real-time operating systems — QNX Safety OS, for example — are developed and certified with IEC 62304 compliance explicitly in mind. If the vendor can provide documentation demonstrating their development process meets the standard and your contract includes access to it, you may have grounds to treat it as non-SOUP. But verify this carefully. Marketing language about “safety certification” often refers to functional safety standards (like IEC 61508) rather than IEC 62304 specifically, and the two are not the same.
“We wrote this code ourselves five years ago — surely it’s not SOUP?”
If it predates your IEC 62304 QMS, or if you cannot retrieve the development records for it (requirements documents, design documents, unit test results, review records), then under the standard’s second definition, it is SOUP. The practical question to ask is: could you produce evidence in an audit that this software was developed in accordance with IEC 62304? If the answer is no, document it as SOUP.
“We’re using an AI model as a component — is that SOUP?”
This is an increasingly common question and the answer is: almost certainly yes. Pre-trained models developed by third parties (whether open-source or commercial) are software items not developed under your QMS. They carry additional complexity because their anomaly behaviour can be difficult to characterise. As regulators publish more specific guidance on AI/ML in medical devices, the SOUP assessment framework is the starting point for documenting their use — and the requirements become more nuanced, not less.
“Our subcontractor wrote this module for us specifically — is it SOUP?”
Not necessarily, but this depends entirely on your contract and their QMS. If the subcontractor developed the software under an IEC 62304-compliant process and you have contractual access to their development records, it is not SOUP. If they did not, or if you cannot obtain the records, treat it as SOUP. The safer approach is to write IEC 62304 compliance requirements into subcontracting agreements from the start. Retrofitting this is painful.
What You Must Document for Every SOUP Item
Once you have correctly identified your SOUP items, IEC 62304 specifies what must be documented for each one. This is not a suggestion — these are audit requirements.
Identification (mandatory for all classes): Name, version number, vendor or source, license type. The version number must be exact and traceable. “Latest stable release” is not an acceptable identification.
Functional requirements (mandatory for Class B and C, best practice for Class A): What must this SOUP do for your device? Write specific, testable requirements. “The SOUP shall provide FFT computation on arrays of up to 1 million samples with output error not exceeding 0.01%.” Not “it does signal processing.”
Performance requirements: Speed, latency, throughput, accuracy, reliability thresholds that the SOUP must meet in your device’s context.
Hardware and software prerequisites: Minimum RAM, processor architecture, operating system version, runtime environment. These are the conditions under which your verification testing will be conducted.
Known anomaly review (mandatory for Class B and C): A documented review of known bugs. For open-source components, this means checking the project’s issue tracker. For commercial components, it means reviewing vendor release notes and security advisories. The review must be version-specific.
Cybersecurity CVE assessment (mandatory for Class B and C): A search of the National Vulnerability Database (NVD) for CVEs affecting the specific version in use. If critical CVEs are found, document your mitigation strategy.
Safety class determination with rationale: Class A, B, or C — and a written explanation of why. “Failure of this component results in incorrect display of patient vital signs. Classified as Class B.”
Verification approach: How will you confirm the SOUP meets your requirements? Because you treat it as a black box, this means interface testing — inputs, outputs, and behaviour under defined conditions.
Post-market surveillance plan: Who monitors this SOUP after market release? By what method? How often? What triggers a re-assessment? What is the update strategy?
Why Getting This Right Matters Beyond Audit Compliance
The documentation discipline around SOUP is not bureaucratic box-ticking. It exists because SOUP items are a genuine source of patient risk that many teams underestimate.
Software design errors were the most common root cause in device recalls identified in FDA data. A significant proportion of those errors trace back to third-party software components that were insufficiently understood, inadequately tested in the device context, or not monitored after release.
When a SOUP item is properly assessed, your team understands exactly what it needs to do, knows its known failure modes, has tested it against your specific requirements, and has a plan for responding when new vulnerabilities emerge. That is not just a compliance posture — it is sound engineering practice.
Bringing It All Together: The SOUP Inventory
The practical starting point for any medical device project is a complete SOUP inventory — a list of every software item in your device that meets either branch of the IEC 62304 definition. Building this inventory early (not at submission time) gives you time to assess each item properly, identify any gaps, and make informed decisions about which components to use.
For each item in the inventory, you then need a completed SOUP assessment covering all the sections described above. A consistent, structured template for this assessment ensures nothing is missed across items and across team members — and gives auditors a clean, navigable document that demonstrates you have managed the risk.
Ready to Document Your SOUP Items Properly?
If you are building your SOUP inventory and need a structured assessment document that covers every IEC 62304-required section, the AptSkill SOUP Assessment Form gives you an audit-ready template as an instant .docx download.
It includes pre-written guidance for each section, worked examples showing the level of detail auditors expect, a built-in CVE cybersecurity review checklist, and a Class A/B/C classification section with space for your rationale. One-time purchase, full team license, $49.
Download the SOUP Assessment Form Template →
AptSkill MedTech publishes practical compliance guides for medical device engineers and regulatory affairs professionals working with IEC 62304, EU MDR, and FDA software requirements.