The requirement to document compliance decisions with supporting rationale — a general quality management expectation that predates IEC 62304.
Clause 4.4.5 is entirely new in A1:2015. Creates a capstone record that ties the version of legacy software to the full 4.4 compliance body of evidence — version-specific, not product-level.
Version specificity of the rationale and confirmation that all referenced 4.4.2–4.4.4 outputs are complete and documented before the rationale was approved.
Maps to
IEC 62304: §4.4.5 Rationale for use of legacy software
Requirement text
The manufacturer shall document the version of the legacy software together with a rationale for the continued use of the legacy software based on the outputs of clauses 4.4.2 through 4.4.4. Fulfillment of clause 4.4 enables further use of legacy software in accordance with IEC 62304.
Why this clause exists
Clause 4.4.5 is the capstone record for the entire legacy software compliance path: it requires the manufacturer to draw an explicit conclusion from the risk management, gap analysis, and gap closure work and document that conclusion alongside the specific software version it applies to. Version specificity is not bureaucratic — it is the mechanism that prevents a 4.4 compliance determination for one version of legacy software from being silently extended to cover subsequent versions that may have been modified outside the controlled change process. The rationale requirement ensures that the legacy path is an affirmative documented decision, not a default state. Fulfillment of all 4.4 elements gives the manufacturer a defensible compliance basis when using legacy software, documented in a form that an auditor can evaluate against the supporting evidence.
What changed
Clause 4.4.5 was introduced in its entirety by Amendment 1 (2015). It is the concluding record of the legacy software compliance path that A1:2015 created wholesale. The explicit version-identification requirement is notable: it prevents the 4.4 determination from floating across versions and ensures each deployed version of legacy software has a discrete compliance record.
Common gaps (what we see in audits)
- Rationale document not version-specific — The legacy software rationale refers to the software by product name without specifying the version number. When the software is updated (even through gap closure activities), it is unclear whether the rationale applies to the updated version. Clause 4.4.5 requires the specific version to be documented.
- Rationale authored before gap closure is complete — The rationale for continued use is drafted concurrently with the gap closure plan rather than after its execution, meaning the basis for the rationale (completed 4.4.4 outputs) does not yet exist. The rationale must be based on the outputs of 4.4 — which implies those activities are concluded.