Maps to
QMSR / ISO 13485: §820.40
ISO 13485: §4.2.4
IEC 62304: §8
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.
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.
Atomic constraints
- •All software configuration items must be identified (source code, build scripts, SOUP, test artifacts, documentation).
- •Changes to configuration items must be approved before implementation.
- •The configuration of each released software version must be fully determinable and documented.
- •A means to trace changes back to their authorization must exist.
- •SOUP items must be identified with version and vendor information.
- •Configuration status accounting must be maintained.
Common gaps
Cloud SOUP dependencies drifting outside manufacturer control
majorFor 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
moderateConfiguration 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.
Evidence signals
- •
FILE_EXISTS
SOUP.*List|Software.*Development.*Plan|Configuration.*Management|Version.*Control
- •
CONTENT_MATCH
Does this document describe the software configuration management system, identify configuration items including SOUP, define the change approval process, and explain how the exact configuration of any released version can be determined and reproduced?
Audit defense
Software configuration management for [your product] uses git with semantic version tagging, as documented in the Software Development and Maintenance Plan (Doc ID: [your document ID]). The SOUP list identifies all third-party dependencies, and each release tag allows the complete release configuration to be reproduced from source control.