Release checklist, version identification, verification completion confirmation, and archived release artifacts — standard controlled-release practice.
Known residual anomalies must be safety-evaluated before each release; the 2015 amendment formalized known-defect publication and security release verification.
Release checklist completeness and the anomaly safety-impact record — common finding is releases proceeding without documented residual-anomaly evaluation.
Maps to
IEC 62304: §5.8 Software release for utilization at a system level
ISO 13485: §7.3.8 Design and development transfer
Pre-QMSR Part 820 (legacy QSR): §820.30(h) Design transfer.
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.
Why this clause exists
The software release gate is the final quality checkpoint before a software version reaches patients — the point at which the accumulated evidence from planning, requirements definition, architecture, implementation, unit verification, and system testing must be assessed as sufficient to authorize distribution. IEC 62304:2006+A1:2015 clause 5.8 requires this gate to be documented because an undocumented release decision is, from an audit perspective, no decision at all: there is no evidence of when the decision was made, who made it, what evidence they reviewed, and what the state of outstanding anomalies was at that moment. The known-anomaly safety evaluation requirement is particularly significant for rapidly iterating software products: organizations that release software with open defects without documenting the safety rationale for each open item leave themselves unable to demonstrate, in any subsequent post-market investigation, that they had a reasonable basis for releasing with those defects present. The archival requirement ensures that any released version can be reproduced exactly from source control, which is a prerequisite for investigating field issues — without build reproducibility, an adverse event investigation may be unable to determine whether a field report correlates with the released software or with a configuration artifact that cannot be reconstructed.
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)
- Release process lacks security verification checkpoint — Software 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.