SOUP testing for medical device software

Which SOUP items need a test, and which are settled on paper?

An item gets a test when you have written a requirement against it. IEC 62304 puts that obligation at clause 5.3, Software ARCHITECTURAL design, which asks for functional and performance requirements for each SOUP item together with the hardware and software that item needs in order to work. The requirement belongs to you, so the test that answers it is an ordinary system test and lands in the ordinary place: all five subclauses of 5.7 bind at classes A, B and C in Edition 1.1, and 5.7.1 is titled "Establish tests for software requirements".

Everything else about a SOUP item is settled in the architecture record and in the risk management file. A parsing library that never touches a clinical value, sitting in an item group classified A, produces a specification entry and an anomaly evaluation and no test case of its own.

Which group an item sits in is the decision that moves the most work. Clause 4.3 item d) treats a group of software items at the classification of the highest-classified item in the group, unless the manufacturer documents a rationale in the risk management file for using a lower classification. A component placed inside the same item as your dosing logic inherits class C because of where it was placed. The class table and how the assignment is made are on the IEC 62304 testing requirements page.

What evidence stands in for development records you will never see?

Behaviour you observed and decisions you recorded. ISO 14971:2019 defines objective evidence at 3.11 as "data supporting the existence or verity of something", and that definition does not require the data to have come from the supplier. Your own test result against your own requirement is objective evidence. So is a dated record of what the vendor published and what you decided about it.

The absence of records is the defining feature of the category, and IEC 62366-1 draws the same line for user interfaces: its definition 3.15 defines UOUP, user interface of unknown provenance, as a user interface "previously developed for which adequate RECORDS of the USABILITY ENGINEERING PROCESS of this standard are not available". A component can be current and widely deployed and still be of unknown provenance, because provenance here is a question about records. The usability side of that is on the IEC 62366-1 page.

Two escape routes get reached for and neither is open. Amendment 1 added a note to definition 3.29: "A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP." And the legacy route at clause 4.4 is for software that "was legally placed on the market and is still marketed today", per definition 3.36, which a library you pulled from a registry never was. Clause 4.4.3 also fixes what a gap analysis on that route runs against: the deliverables required by 5.2, 5.3, 5.7 and Clause 7, with software system test records as the stated minimum. That list is worth reading even when the route is closed, because it names the four places a component with no history has to be answered for.

In what order does the work run?

Step 5 is the step teams schedule last and it decides the shape of steps 6 to 9. A vendor who publishes nothing has not removed the obligation at clause 7.1, so record the search you ran and the date, and treat the silence as an input to step 7.

What does a published anomaly list oblige you to do?

clause 7.1, Analysis of software contributing to hazardous situations is the clause the evaluation belongs to. It asks you to work through the known defects and decide which of them could contribute to a hazardous situation in your device. The output is a decision per anomaly, and the decision is the artefact.

A severity score published alongside the defect does not make that decision. ISO 14971:2019 says so in its own scope: "This document requires manufacturers to establish objective criteria for risk acceptability but does not specify acceptable risk levels." The criteria are yours to define and to defend, and a vendor's rating was assigned without your intended use in front of it.

Security advisories carry a further wrinkle that a single acceptability rule will get wrong. FDA's recognition record for ISO 14971 notes that the standard defines risk at 3.18 as the combination of the probability of harm and its severity, and that FDA's premarket cybersecurity guidance "explicitly states this probabilistic model does not apply to cybersecurity". FDA's note puts exploitability in its place, described there as the feasibility and technical means by which a vulnerability can be exploited, as the operative basis for security risk estimation. An advisory evaluated on a probability estimate has been evaluated on the wrong axis. How the risk file and the testing join up is set out on the ISO 14971 page.

When the component updates, who decides whether your device changed?

You do, and the granularity you chose in step 1 is what you decide with. Granularity is assigned by the manufacturer under the note to definition 3.25, so the unit in which the question can be asked is one you built. A team that recorded its inventory at the level of a package name has no smaller unit available when a patch release lands.

IEC 62304 names the places the decision is recorded in its clause titles: 6.2 Problem and modification analysis, 6.3 Modification implementation, 7.4 RISK MANAGEMENT of software changes, 8.1 Configuration identification and 8.2 Change control. Clause 1.4 then makes compliance a matter of inspection of all documentation the standard requires, including the risk management file. Which tests the update reopens is a separate method with its own rules, worked through at regression testing for regulated software.

A SOUP update and a test tooling update are two different obligations and get confused because both arrive as a version bump. A SOUP item is inside the thing you ship and inherits the safety class of its group. A test framework is an instrument, and it appears in a 5.7.5 record as one of "the relevant test tools". What the instrument itself has to answer for is covered at test automation in a validated environment, and the machinery that has to capture the resolved version on every run is at CI/CD for medical device software.

Where does the SOUP question stop being a testing question?

At the point where the answer is architectural. The architecture can move a component out of the class that made it expensive. Clause 4.3 a) allows a new class to be assigned once external risk control measures are in place, and it names revising the containing system architecture as one of them. No suite can produce that result, and the reclassified item is what the evidence then has to match.

The clause that names the boundary is 5.3.5, Identify segregation necessary for RISK CONTROL, marked [Class C] in Edition 1.1. Segregation is a design decision about where a component may reach, and its evidence is a design record plus a demonstration that the segregation holds.

ISO 14971:2019 supplies the order the options are considered in. Clause 7 runs 7.1 Risk control option analysis, 7.2 Implementation of risk control measures, 7.3 Residual risk evaluation, 7.4 Benefit-risk analysis, 7.5 Risks arising from risk control measures and 7.6 Completeness of risk control. Subclause 7.5 is the one a SOUP argument reaches most often: a control added to contain a defective component is itself a change that can introduce risk. ISO/TR 24971:2020 devotes an informative annex to the problem, Annex G, "Components and devices designed without using ISO 14971".

What does the work hand over?

• A SOUP inventory with the item boundary, the version, and the hardware and software each item needs.
• The functional and performance requirements written for each item under clause 5.3.
• An anomaly evaluation per item, with the source, the date read, and a recorded decision per anomaly.
• System test records for the requirements in the inventory, to the contents named at 5.7.5.
• The residual anomaly list at release, under 5.8.2.
• The segregation and risk control decisions taken instead of a test, traced into the risk management file.

Exercising a component that sits in a clinical data path needs data of that shape. We do not need production PHI to test. Environments run on synthetic and de-identified data. What is signed before an engagement touches PHI, and where project data lives while the work runs, are answered in the buyer's own words at how we work with protected health information. Assembling the inventory, the evaluations and the test records into a set a reviewer reads unaided is the work described at validation documentation.

Sources for this page. The clause numbers, clause titles, definitions 3.25, 3.29 and 3.36, and the class markers quoted from IEC 62304 Edition 1.1 were read on 2 September 2026 in the IEC first-party preview of the consolidated edition and the publisher preview of Amendment 1. The attributions to clause 5.3 and clause 7.1 stay at that level because no third-level subclause number under either was visible in a primary source. The scope sentence, the definitions at 3.11 and 3.18, and the Clause 7 and Clause 10 subclause titles of ISO 14971:2019, together with the ISO/TR 24971:2020 passages, are read in those two documents. The cybersecurity passage is quoted from FDA's recognition record for that standard. The UOUP definition is read in IEC 62366-1.

Which SOUP arguments fail on inspection?

• The inventory is generated from a manifest, so it carries versions and no functional or performance requirements of the kind clause 5.3 asks for.
• Anomaly evaluation is skipped for components with no published list, and no record shows that anyone looked.
• A vendor severity rating is copied into the file as the acceptability decision, although ISO 14971:2019 leaves the criteria for risk acceptability to the manufacturer.
• Security advisories are scored on probability, which the FDA note attached to the ISO 14971 recognition record says is the wrong basis for cybersecurity.
• A component is recorded as legacy software under clause 4.4, although it was never legally placed on the market as required by definition 3.36.
• The inventory names a package and the release notes name a module, so nobody can say which item the update touched.
• Segregation is described in an architecture diagram and never demonstrated, and 5.3.5 is marked [Class C].
• Anomalies accepted before release are absent from the residual anomaly record, which Edition 1.1 marks [Class A, B, C] at 5.8.2.