IEC 62304 §5.1 software development planning, configuration management, requirements traceability, and V&V processes already in the lifecycle.
Security activities integrated across all lifecycle phases, security update and patching processes, and tailoring record documenting any 81001-5-1 requirements not implemented with expert-reviewed justification.
SDLC plan showing security activity integration alongside IEC 62304 phases, plus tailoring record — absence of the tailoring record is a routine Notified Body finding.
Maps to
IEC 81001-5-1: §5.1.1 ACTIVITIES in the LIFE CYCLE PROCESS
ISO 13485: §7.3.2 Design and development planning
IEC 62304: §5.1 Software development planning
Requirement text
The manufacturer shall establish general life cycle activities — from conception to decommissioning — that are consistent and integrated with a commonly accepted product development process, including: configuration management with change controls and change history; product description and requirements definition with requirements traceability; software or hardware design and implementation practices such as modular design; repeatable testing verification and validation process; review and approval of all development process records; product support; and security updates and patching for health software. The manufacturer shall document the justification for not implementing requirements of this document within a given health software project, based on review and approval by personnel with appropriate security expertise.
Why this clause exists
Security activities that are not planned as part of the product development lifecycle tend to arrive late, incompletely, or not at all. A threat model performed two weeks before a release cannot identify architecture-level vulnerabilities that would require redesign; a penetration test scheduled as the last pre-release activity cannot drive meaningful remediation when the development schedule is fixed. IEC 81001-5-1:2021 clause 5.1.1 requires security life cycle activities to be established and integrated across the full lifecycle — from conception through decommissioning — specifically because early integration is what allows security findings to influence design decisions rather than producing only documentation. The planning requirement also serves an explicit tailoring function: manufacturers must document and obtain expert-reviewed justification for any requirement of the standard they do not implement for a given product. This creates a formal scoping record that an auditor can evaluate, rather than relying on unstated assumptions about which requirements apply. FDA's premarket cybersecurity guidance mirrors this structure, expecting to see evidence that security was integrated into design inputs, not appended at the design verification stage.
What changed
IEC 81001-5-1:2021 is the first standalone cybersecurity standard purpose-built for health software and medical device software. Published in December 2021, it was adapted from IEC 62443-4-1 (industrial control systems security) to address the unique safety and regulatory context of medical devices — adding health-specific requirements that account for patient safety, clinical workflows, and the manufacturer-HDO relationship.
The standard mirrors IEC 62304's lifecycle structure but adds security-specific activities at every phase — planning, development, testing, release, and maintenance. It requires security risk management to be integrated with ISO 14971 safety risk management, not treated as a separate IT concern. FDA formally recognized it as Consensus Standard 13-122 on December 19, 2022 and references it as providing one acceptable framework for satisfying the cybersecurity requirements of Section 524B(b)(2), which requires manufacturers to design, develop, and maintain processes and procedures to provide a reasonable assurance that cyber devices and related systems are cybersecure.
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028. Despite this delay, Notified Bodies and Competent Authorities universally recognize it as "state of the art" for health software cybersecurity under MDR GSPR Annex I, Section 17.2. Missing or inadequate cybersecurity documentation is already a top cause of Notified Body major non-conformities for SaMD. A December 2025 Interpretation Sheet (ISH1:2025) clarified software item classification into maintained, supported, and required software categories, affecting risk transfer and post-market obligations.
Common gaps (what we see in audits)
- Security activities not integrated into the software development plan — Security activities (threat modeling, security requirements, security testing, penetration testing) are planned as ad-hoc activities rather than integrated into the software development and maintenance plan alongside IEC 62304 lifecycle activities. This leads to security testing being deferred or skipped under schedule pressure.