General risk management obligations from clause 4.2 — hazard identification, risk control, and post-market feedback review.
Clause 4.4.2 is entirely new in A1:2015 — there was no legacy software path in IEC 62304:2006. Structures risk management for software already in production without full lifecycle records.
Evidence that post-production feedback was comprehensively assessed (not just MDRs) and that architecture integration hazards were evaluated for the current device system.
Maps to
IEC 62304: §4.4.2 Risk management activities
Requirement text
As an alternative to applying Clauses 5 through 9 of this standard, a manufacturer using the legacy software compliance path shall assess any feedback, including post-production information, on the legacy software regarding incidents and/or near incidents from both inside its own organization and/or from users, and shall perform risk management activities associated with continued use of the legacy software. These activities must address: integration of the legacy software in the overall medical device architecture; continuing validity of risk control measures implemented as part of the legacy software; identification of hazardous situations associated with the continued use of the legacy software; identification of potential causes of the legacy software contributing to a hazardous situation; and definition of risk control measures for each potential cause of the legacy software contributing to a hazardous situation.
Why this clause exists
Legacy software enters a compliance review already deployed in the field — meaning the hazard landscape is live, not theoretical. Clause 4.4.2 imposes a structured risk management pass specifically because the standard cannot assume the original development followed any recognized lifecycle methodology. Post-production feedback (incident reports, complaints, near-misses) is required as input precisely because it represents real-world evidence of failure modes that a retrospective risk analysis might otherwise miss. The architecture-integration check addresses the scenario where legacy software originally developed for a standalone device is now embedded in a networked system, changing the hazard profile without changing any line of code. Without a structured 4.4.2 review, manufacturers could claim the legacy path as a documentation shortcut while running software whose risk profile has materially changed since first deployment.
What changed
Clause 4.4, including 4.4.2, was introduced entirely by Amendment 1 (2015). The original IEC 62304:2006 had no legacy software compliance path — all software was required to follow the full Clauses 5 through 9 lifecycle regardless of its prior development history. The 2015 amendment recognized the practical reality that medical device manufacturers frequently inherit or incorporate software developed before formal lifecycle methodologies were adopted, and created the §4.4 path as a structured alternative. The risk management activities in 4.4.2 mirror the core elements of clause 4.2 (general risk management activities) but are scoped specifically to the retrospective and ongoing-use context of legacy software.
Common gaps (what we see in audits)
- Post-production feedback assessment limited to formal MDRs — Manufacturers narrow the 4.4.2(a) review to only regulatory reportable events, excluding internal complaint records, near-misses, and customer service logs. The clause requires assessment of incidents and near incidents from both inside the organization and from users — the full feedback population, not a regulatory-reportability-filtered subset.
- Architecture integration evaluation omitted when device system changes — The legacy software risk review addresses the software in isolation without evaluating its integration into the current medical device architecture. When device systems evolve (e.g., software is now networked, connected to external systems, or controlling new hardware), new hazardous situations may arise from integration that were absent in the original deployment context.