Documentation expectations from the normative lifecycle clauses (5.2, 5.3, 5.7, Clause 7) — these define the full deliverable set the gap analysis checks against.
Clause 4.4.3 is entirely new in A1:2015. Introduces a risk-proportionate gap analysis: missing deliverables are evaluated for risk-reduction value before generation is mandated, except for test records which are always required.
Gap table completeness (all class-required deliverables checked), risk-reduction rationale for accepted gaps, and confirmed existence of software system test records.
Maps to
IEC 62304: §4.4.3 Gap analysis
Requirement text
Based on the software safety class of the legacy software, the manufacturer shall perform a gap analysis comparing available deliverables against those required by clauses 5.2, 5.3, 5.7, and Clause 7. The manufacturer must assess the continuing validity of available deliverables, evaluate the potential risk reduction from generating missing deliverables and associated activities, and determine which deliverables to create based on that evaluation. The minimum deliverable that must be created is software system test records (see clause 5.7.5).
Why this clause exists
Gap analysis is the decision point that prevents the legacy software path from becoming a documentation exemption. Without clause 4.4.3, a manufacturer could assert legacy software compliance without ever comparing existing documentation against the normative deliverable set. The gap analysis forces a structured comparison, class-specific in its scope (Class A requires fewer deliverables than Class C), and critically requires the manufacturer to evaluate whether generating missing documentation would actually reduce risk before deciding to omit it. The minimum deliverable requirement — software system test records — reflects the regulatory principle that some evidence of functional adequacy is non-negotiable even for legacy software: a device cannot be kept on the market on the basis of historical use alone when no test records exist to demonstrate it continues to perform as intended.
What changed
Clause 4.4.3 was introduced in its entirety by Amendment 1 (2015). The original IEC 62304:2006 had no equivalent provision — gap analysis for previously developed software was not addressed. The A1:2015 legacy software path as a whole (§4.4) provides a risk-proportionate alternative for software that predates formal lifecycle compliance, with gap analysis as the mechanism to determine what retrospective documentation is actually necessary rather than requiring blanket application of all Clauses 5–9 deliverables.
Common gaps (what we see in audits)
- Gap analysis scope not adjusted for software safety class — Manufacturers apply a generic deliverable checklist rather than the class-appropriate normative set. A Class A system requires fewer deliverables than Class C; applying the full Class C list to a Class A system generates unnecessary work and obscures genuine gaps, while applying a Class A scope to a Class C system leaves critical deliverables unexamined.
- Missing deliverables waived without risk-reduction evaluation — Manufacturers identify gaps but decide not to create missing deliverables without documenting the evaluation of potential risk reduction. The clause requires that the decision to waive retrospective generation of a deliverable be supported by an explicit evaluation — not just an assertion that the software has been in use without problems.
- Software system test records absent despite mandatory minimum status — Manufacturers complete the gap analysis and accept multiple gaps without generating software system test records, overlooking that clause 4.4.3(c) makes test records the unconditional minimum deliverable. The risk-reduction evaluation that governs other gaps does not apply to this deliverable.