Release checklist, version identification, verification completion confirmation, and archived release artifacts — standard controlled-release practice.
Known residual anomalies must be documented and safety-evaluated before each release (clauses 5.8.2 and 5.8.3); the 2015 amendment extended the documentation of known residual anomalies (5.8.2) to Class A.
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: §820.30(h) Design transfer.
Requirement text
The manufacturer must ensure that all software verification activities have been completed and the results have been evaluated before the software is released; must document all known residual anomalies and the version of the medical device software that is being released; must archive the medical device software and configuration items, and the documentation, for at least a period of time determined as the longer of the life time of the medical device software as defined by the manufacturer or a time specified by relevant regulatory requirements; must establish procedures to ensure that the released medical device software can be reliably delivered to the point of use without corruption or unauthorised change; and, for software safety classes B and C, must also ensure that all known residual anomalies have been evaluated so that they do not contribute to an unacceptable risk, must document the procedure and environment used to create the released software, and must ensure that all software development plan (or maintenance plan) activities and tasks are complete along with the associated documentation.
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) 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)
- 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.