Maps to
QMSR / ISO 13485: §820.30(h)
ISO 13485: §7.3.8
IEC 62304: §5.8
Requirement text
Before releasing a software version, the manufacturer shall ensure that all verification activities are complete, known residual anomalies are evaluated for safety impact, the released version is uniquely identified, and the software is archived in a retrievable form.
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
- •Required for all software safety classes (A, B, and C)
- •All planned verification activities must be confirmed complete before release.
- •Known residual anomalies (bugs) must be documented and evaluated for patient safety impact.
- •The released software version must be uniquely identified (e.g., semantic version tag in git).
- •The complete set of files constituting the released software must be documented and archived.
- •A release checklist must be completed and approved before distribution.
- •Delivery mechanisms must ensure software integrity from archive to end-user installation.
Common gaps
Release process lacks security verification checkpoint
moderateSoftware releases proceed without a documented security verification step. Cloud service releases deployed via CI/CD (often weekly) frequently lack security release notes or documented assessment of security-relevant changes included in the release.
Evidence signals
- •
FILE_EXISTS
Release.*Checklist|Release.*Notes|Checklist.*Release|Unresolved.*Anomal|Known.*Defect
- •
CONTENT_MATCH
Does this document confirm completion of all verification activities before release, document and evaluate known residual anomalies for safety impact, and specify the unique version identifier for the released software?
Audit defense
Software release for [your product] requires completion of our Checklist Software Release (Doc ID: [your document ID]) confirming all verification activities are done and known anomalies are safety-evaluated. Each release is tagged in git with a semantic version, and release notes document the complete release configuration.