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.3 Installation activities
Pre-QMSR Part 820 (legacy QSR): §820.40 Document controls.
Requirement text
The manufacturer shall establish and maintain a software configuration management system that identifies configuration items, controls changes, tracks status, and ensures the complete configuration of each release can be determined and reproduced.
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) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
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 publishing known defects with risk assessments (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.