Maps to
IEC 81001-5-1: §5.8.1
Requirement text
The manufacturer shall establish an activity (or activities) to ensure that all findings from system testing have been handled by the problem resolution process (Clause 9) (5.8.1). The manufacturer shall establish an activity (or activities) for verifying that a health software or an update is not released until its security-related issues have been addressed and tracked to closure, covering: requirements, security by design, implementation, verification/validation, and security defect management (5.8.5). The manufacturer shall establish an activity (or activities) for verifying that, prior to health software release, all applicable security-related processes required by this document have been completed with records documenting the completion of each activity (5.8.6).
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 64 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-112 in December 2022 and references it as providing a framework for the Secure Product Development Framework (SPDF) required by Section 524B.
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.
Atomic constraints
- •All findings from system testing must be handled by the problem resolution process before release.
- •Health software must not be released until security-related issues in requirements have been addressed and tracked to closure.
- •Health software must not be released until security-related issues in security-by-design have been addressed and tracked to closure.
- •Health software must not be released until security-related issues in implementation have been addressed and tracked to closure.
- •Health software must not be released until security-related issues in verification/validation have been addressed and tracked to closure.
- •Health software must not be released until security defect management issues have been addressed and tracked to closure.
- •All applicable security-related processes must be completed with records prior to release.
- •Records must document completion of each security activity or process.
Common gaps
No security-specific release gate
majorThe release process includes functional verification and regulatory review but lacks a security-specific gate confirming all security requirements are verified, pen test findings resolved, and vulnerability assessment current.
Evidence signals
- •
FILE_EXISTS
Release.*Checklist|Pre.*Release.*Review|Software.*Release.*Record|Release.*Authorization
- •
CONTENT_MATCH
Does this document serve as a pre-release verification record confirming all security testing findings are closed, all security process activities are complete with records, and the software is authorized for release?
Audit defense
The Pre-Release Security Verification checklist for [your product] (Doc ID: [your document ID]) documents completion of all required security activities from requirements through defect management, confirming all findings are resolved and all process records exist prior to release authorization.