Problem resolution (Clause 9) and change management (Clause 6) obligations — legacy software that enters active use must follow the same defect and change governance as newly developed software.
Clause 4.4.4 is entirely new in A1:2015. Permits objective evidence substitution for re-performing development activities — a practical concession for retrospective documentation generation.
Execution evidence for each planned gap closure activity, confirmation that problem resolution covers the legacy software, and that any software changes went through Clause 6.
Maps to
IEC 62304: §4.4.4 Gap closure activities
Requirement text
The manufacturer shall establish and execute a plan to generate the deliverables identified in the gap analysis. Where available, objective evidence may be used to generate required deliverables without performing activities required by clauses 5.2, 5.3, 5.7, and Clause 7. The plan must address the use of the problem resolution process for handling problems detected in the legacy software and its deliverables in accordance with Clause 9. Changes to the legacy software shall be performed in accordance with Clause 6.
Why this clause exists
Gap closure ensures the legacy software compliance path does not terminate at documentation of gaps — it requires active remediation. The clause permits objective evidence to substitute for fully re-executing lifecycle activities (for example, using existing test logs to construct compliant test records rather than re-running all tests), which recognizes the practical constraint that retrospective execution of every development activity is often infeasible. The requirement to address Clause 9 (problem resolution) in the gap closure plan is essential: legacy software has an existing defect population that must be systematically managed, not treated as outside scope simply because the software predates formal processes. The Clause 6 requirement for software changes guards against the gap closure plan inadvertently becoming a vehicle for undocumented modification of the legacy software under the guise of generating missing deliverables.
What changed
Clause 4.4.4 was introduced entirely by Amendment 1 (2015). As with clauses 4.4.2 and 4.4.3, there was no equivalent in IEC 62304:2006. The gap closure clause operationalizes the gap analysis by requiring an executable plan, while the permission to use objective evidence in place of re-performed activities is a significant practical concession acknowledging retrospective lifecycle execution constraints.
Common gaps (what we see in audits)
- Gap closure plan established but not executed — The gap closure plan exists as a document but activities have not been completed. Auditors verify both establishment and execution of the plan — a plan with open items and no evidence of execution does not satisfy clause 4.4.4.
- Problem resolution process not explicitly addressed for legacy software — The gap closure plan generates documentation deliverables without addressing how detected problems in the legacy software will be handled. Clause 4.4.4(b) specifically requires the plan to address problem resolution per Clause 9 — omitting this leaves legacy software without a governed defect management path.