Contains Nonbinding Recommendations
11
because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, 
completely secure. Security risk management should be an integrated part of a manufacturer’s 
entire quality management system, addressed throughout the TPLC.28 The quality management 
system processes entail the technical, personnel, and management practices, among others, that 
manufacturers use to manage potential risks to their devices and ensure that their devices are, and 
once on the market, remain, safe and effective, which includes security. 
Performing security risk management is distinct from performing safety risk management as 
described in ISO 14971. The distinction in the performance of these processes is due to the fact 
that in the security context versus the safety context, the scope of possible harm and the risk 
assessment factors may be different. Also, while safety risk management focuses on physical 
injury, damage to property or the environment, or delay and/or denial of care due to device or 
system unavailability, security risk management may include risks that can result in indirect or 
direct patient harm. Additionally, risks that are outside of FDA’s assessment of safety and 
effectiveness, such as those related to business or reputational risks, may also exist. 
The scope and objective of a security risk management process, in conjunction with other SPDF 
processes (e.g., security testing), is to expose how threats, through vulnerabilities, can manifest 
patient harm and other potential risks. These processes should also ensure that risk control 
measures for one type of risk assessment do not inadvertently introduce new risks in the other. 
For example, AAMI TIR57 and ANSI/AAMI SW96 detail how the security and safety risk 
management processes should interface to ensure all risks are adequately assessed.29 FDA 
recommends that security risk management processes, as detailed in the QMSR and ISO 
13485,30 be established or incorporated into those that already exist, and should address the 
manufacturer’s design, manufacturing, and distribution processes, as well as updates across the 
TPLC. The processes in ISO 13485, as incorporated by reference in the QMSR, that may be 
relevant in this context include, but are not limited to design and development (Subclause 7.3 of 
ISO 13485), production processes (Subclause 7.5), and improvement (including corrective 
actions and preventive actions) (Subclause 8.5) to ensure both safety and security risks are 
adequately addressed. For completeness in performing risk management under Subclause 7.1, 
FDA recommends that device manufacturers conduct both a safety risk assessment and a 
separate, accompanying security risk assessment to ensure a more comprehensive identification 
and management of patient safety risks.
A device should be designed to eliminate or mitigate known vulnerabilities. For marketed 
devices, if comprehensive design mitigations are not possible, compensating controls should be 
considered. For all devices, when any known vulnerabilities are only partially mitigated or 
unmitigated by the device design, they should be assessed as reasonably foreseeable risks in the 
28 The TPLC processes include design and development, manufacturing, postmarket monitoring, delivering device 
software and firmware updates, and servicing, among others. 
29 AAMI TIR57 Principles for medical device security—Risk management describes the security risk management 
process and how the security risk management process should have links into the safety risk management process 
and vice versa. ANSI/AAMI SW96 Standard for medical device security - Security risk management for device 
manufacturers (https://doi.org/10.2345/9781570208621.ch1) describes specific requirements for managing security 
related risk across the total product life cycle utilizing the risk management framework defined by ISO 14971 
Medical devices - Applications of risk management to medical devices.
30 See 21 CFR Part 820.
