Maps to
ISO 14971: §4.1
IEC 62304: §4.3
IEC 81001-5-1: §4.2
Requirement text
The manufacturer shall establish a process for managing risks associated with security using threat modelling. The process shall use threat modelling to identify vulnerabilities, estimate and evaluate associated threats, control those threats, and monitor the effectiveness of security risk controls, taking into account intended use and use environment. The manufacturer shall establish criteria for risk acceptability. Security risk management should incorporate outcomes of threat modelling activities and follow industry best practice. Residual risk associated with a vulnerability that remains in the system shall be documented, along with respective compensating 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 process for managing risks associated with security SHALL be established.
- •The process SHALL use threat modelling to identify vulnerabilities.
- •The process SHALL estimate and evaluate associated threats.
- •The process SHALL control identified threats.
- •The process SHALL monitor the effectiveness of security risk control measures.
- •Intended use and use environment SHALL be taken into account.
- •Criteria for risk acceptability SHALL be established.
- •Outcomes of threat modelling activities SHALL be incorporated into security risk management.
- •Residual risk associated with remaining vulnerabilities SHALL be documented.
- •Compensating controls for residual risk SHALL be documented.
Common gaps
Security risk management siloed from safety risk management
majorOrganizations attempt to handle cybersecurity risks within their existing ISO 14971 process without establishing a distinct security risk management process. While integration points are necessary, cybersecurity risks require different assessment methods (CVSS, exploitability) and different expertise than safety risks. Conflating safety severity with cybersecurity exploitability leads to inaccurate risk assessments.
Evidence signals
- •
FILE_EXISTS
(Threat.*Model|Security.*Risk|Risk.*Management.*Plan|STRIDE|PASTA|Vulnerability.*Register|Security.*Risk.*Register)
- •
CONTENT_MATCH
Does this document describe a security risk management process using threat modelling to identify vulnerabilities, evaluate threats, and document residual risk with compensating controls?
Audit defense
Our security risk management process (Doc ID: [your document ID]) uses threat modelling to systematically identify, evaluate, and control security threats for [your product]. Residual risks and compensating controls are documented in the security risk register, satisfying clause 4.2 and aligned with ISO 14971 4.1.