Maps to
IEC 81001-5-1: §6.1.1
IEC 62443-4-1: §DM-3
Requirement text
Establish a policy specifying timeframes for delivering and qualifying security updates, considering: a) potential impact on technical performance, safety, effectiveness, and security; b) public knowledge of the vulnerability; c) whether published exploits exist; d) volume of deployed products affected; e) availability of effective external controls.
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
- •A documented policy SHALL define timeframes for delivering security updates.
- •A documented policy SHALL define timeframes for qualifying security updates.
- •Timeframes SHALL consider potential impact on technical performance, safety, effectiveness, and security.
- •Timeframes SHALL consider whether the vulnerability is publicly known.
- •Timeframes SHALL consider whether published exploits exist.
- •Timeframes SHALL consider the volume of deployed products affected.
- •Timeframes SHALL consider the availability of effective external controls.
Common gaps
No defined timeline for security patch delivery
majorManufacturers commit to 'providing security updates' without defining severity-based timelines (e.g., critical within 30 days, high within 60 days). Without defined SLAs there is no accountability for timely patch delivery.
Evidence signals
- •
FILE_EXISTS
Security.*Update.*Policy|Vulnerability.*Response|Patch.*Management|Cybersecurity.*SOP
- •
CONTENT_MATCH
Does this document define specific timeframes for delivering or qualifying security updates, with criteria for adjusting those timeframes based on exploit availability, public knowledge, or deployment volume?
Audit defense
Our Security Update Policy (Doc ID: [your document ID]) establishes risk-tiered timeframes for delivering and qualifying security updates for [your product]. The policy explicitly addresses each of the IEC 81001-5-1 §6.1.1 factors — exploit availability, public disclosure, deployment scope, and compensating controls — ensuring update prioritization is proportionate to actual patient risk.