Version control, document control, and change approval before implementation — core QMS document-control practice.
All configuration items, including SOUP with exact version and vendor data, must be formally identified; reproducibility of any released version is required.
SOUP list currency versus last dependency change — and build reproducibility evidence showing the exact release artifact can be reconstructed from version control.
Maps to
IEC 62304: §8 Software configuration management process
ISO 13485: §4.2.3 Medical device file, §4.2.4 Control of documents, §7.5.8 Identification, §7.5.9 Traceability
Pre-QMSR Part 820: §820.40 Document controls.
Requirement text
The manufacturer must establish a scheme for the unique identification of configuration items and their versions to be controlled according to the development and configuration planning specified in 5.1; document, for each SOUP configuration item being used (including standard libraries), the title, the manufacturer and the unique SOUP designator; document the set of configuration items and their versions that comprise the software system configuration; change the configuration items identified to be controlled only in response to an approved change request; implement the change as specified in the change request, identify and perform any activity that needs to be repeated as a result of the change, and verify the change; maintain records of the relationships and dependencies between the change request, the relevant problem report and the approval of the change request; and retain retrievable records of the history of controlled configuration items including system configuration.
Why this clause exists
Configuration management is the discipline that makes software verification evidence credible by ensuring that the artifact verified is demonstrably the same artifact released and the same artifact that can be reconstructed if a field investigation requires it. Without configuration management, the claims made in verification records are unanchored: there is no way to confirm that the code reviewed in unit verification, the software tested in system testing, and the software installed in the device are all the same version, or that the SOUP components specified in the architecture are the actual components running in the device. IEC 62304:2006+A1:2015 clause 8 formalizes this discipline because the failure mode — a development team that tracks requirements and tests without knowing whether the code deployed to clinical sites matches any reviewed version — was a recurring finding in regulatory inspections, particularly in organizations transitioning to agile and continuous-delivery practices where frequent releases outpaced configuration control discipline. The requirement to identify SOUP items with version and vendor information as configuration items reflects the convergence of IEC 62304 and cybersecurity requirements: SOUP items that are not formally tracked cannot be assessed for CVE applicability, cannot be accurately represented in an SBOM, and cannot be monitored for vendor security advisories — meaning an undocumented transitive dependency is simultaneously a configuration management gap, a risk management gap, and a cybersecurity gap.
What changed
Amendment 1 (2015) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for identification and avoidance of common software defects (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Cloud SOUP dependencies drifting outside manufacturer control — For cloud-deployed SaMD, SOUP dependencies like cloud platform APIs, managed services, and container base images change outside the manufacturer's control. Unlike firmware, cloud SCM must account for 'version drift' in environment-level dependencies that may affect software behavior without any code change by the manufacturer.
- Build artifacts not signed or integrity-verified — Configuration management does not ensure integrity of security-relevant items. Build artifacts are not cryptographically signed, container images are pulled from public registries without integrity verification, and firmware binaries lack signing for OTA delivery. No configuration baseline document exists.