The requirements for cybersecurity of medical devices are increasingly becoming the focus of authorities and, in particular, the risk management process for risks associated with cybersecurity. Standards such as IEC 81001-5-1 or the FDA Guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” require a secure product life cycle. In addition, the MDCG 2019-16 also requires the cybersecurity of medical devices. How do these risks differ from those relating to patient safety? Can we simply and quickly expand our ISO 14971 process, or do we need a new solution to adequately cover the new risks? In this blog post you can find out what is important in the risk management process for cyber security and where you can start efficiently and quickly to close potential gaps.
What distinguishes security from safety?
The two terms “security” and “safety” can be used synonymously in some cases, however here in this context there are fundamental differences between the two. While “safety” refers to patient safety, “security” refers to product safety:
Safety – Patient safety
According to the definitions in ISO 14971, patient safety focusses on the protection and safety of the patient, but also on the protection of the user and the use environment. Risk management in accordance with ISO 14971 therefore considers risks purely from the perspective of how likely it is that a hazard will arise for the patient, user or environment. This aspect is also used to determine the severity levels, which generally range from “no impact” to “irreversible damage or death”. This explicitly excludes damage and impairment of the device itself as well as economic damage to the company.
Security – Product security / IT security
For once, product safety is not about patient safety, but about protecting the device or medical system. Here it is important to define and prioritise the assets to be protected – i.e. the parts of the system that have value. Corporate values, such as intellectual property (I.P.) or the corporate image, are also explicitly prioritised as assets worth protecting. While patient safety can be assessed via the probability of occurrence and severity, product safety is concerned with the potential of attacks resulting from the various threats and vulnerabilities of the system.
The difference between safety and security is an essential aspect in the classification and assessment of the corresponding risks. Due to the fundamentally different nature of the underlying causes, it is necessary to build up additional expertise and restructure the company’s risk management process.
Where are the requirements for a security risk management process specified?
The requirements for a security risk process originate primarily from EN IEC 81001-5-1 Section 7, as well as the above-mentioned FDA Guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” Section V.A. The latter also clearly addresses the difference between safety and security and recommends establishing a separate security risk management process. Both documents agree regarding the content. The following aspects must be fundamentally covered by a corresponding risk management process:
- Analysis and documentation of the product security environment (security context)
- Identification of vulnerabilities with the help of a threat model (threat modeling)
- Assessment and evaluation of the security risk
- Control of the risk (threat mitigation)
- Monitoring of implemented risk control measures
In general, both regulatory documents should not be considered separately, but together. IEC 81001-5-1 provides a good procedural framework for the activities required to create a secure product development framework (SPDF). The FDA requires this SPDF and also recognises IEC 81001-5-1 as a procedural framework. However, the FDA also has specific requirements for the content of the documentation to be created. It therefore supplements IEC 81001-5-1 with practical examples and best practices.
For additional practical examples, the FDA refers to other technical reports from the AAMI. The AAMI TIR57:2016 (R2013) “Principles for medical device security – Risk management” are of particular note here, as well as the AAMI TIR97:2019 (R2023) “Principles for medical device security – Postmarket risk management for device manufacturers”.
Process-related instructions based on the AAMI TIR57 and AAMI TIR 97
The AAMI TIR57:2016 (R2013) “Principles for medical device security – Risk management” describes an approach for risk management during the development process. It points out that it is advisable to define a separate process due to the different nature of the risks. The following figure from AAMI TIR57:2016 (R2023) presents the connection between the two processes:
The recommended process shows the linking of the two risk management processes. It is clear that both processes require a functional interface from the respective risk controls if it is suspected that there is an impact on the other process. Security risks with a possible influence on patient safety must therefore be considered in safety risk management and vice versa.
IMPORTANT: The risk must be duplicated and not transferred. The same risk is considered in both processes and, if necessary, control measures are defined from a security AND a safety perspective.
In addition to explaining the processes, AAMI TIR57:2016 (R2013) also provides examples of the assessment of risks using various approaches in Annex B:
- Threat-orientated
- Asset-orientated
- Vulnerability-orientated
AAMI TIR57:2016 (R2013) therefore provides a fundamental basis for the implementation of a risk management process for product safety and at the same time offers a certain degree of freedom in the choice of methodology in order to find the best possible solution for your own company structure.
Once the system has been released and observed on the market, the AAMI TIR97:2019 (R2023) “Principles for medical device security – Postmarket risk management for device manufacturers” can be consulted. The so-called “cybersecurity signals” are described here. These signals are any information that indicates a possible or confirmed vulnerability, exploit, threat or threat event that affects or could affect a medical device. If such a signal is detected, AAMI TIR97:2019 (R2023) describes in a practical way how and in what time frame a reaction should be initiated.
These reactions also include the basic processes:
- Coordinated Vulnerability Disclosure (CVD)
- Incidents Response Plan (IRP)
The CVD is described in detail in Appendix C and covers the process itself, but also the criteria for when vulnerability reports from external sources are accepted and how they should be reported back to users.
The IRP is described in Appendix E. It explains in detail how to prepare for the response, the criteria for assessing incidents and best practice responding. Appendix E makes a significant distinction between internal activities and external communication. Finally, the appendix also deals with the coordination of the necessary software releases, including the required SBOM.
To summarise, security risk management can be a major hurdle for many companies. There are many regulatory requirements and many more documents that promise best practice. But security risk management is not a summit to be climbed in a day. It is a continuous process that can be broken down into many small stages. The prioritisation of these individual steps should be justified and documented using a risk-benefit analysis. Once this has been done, nothing stands in the way of a successful journey towards a safe medical system.
Please note that all details and listings are not intended to be exhaustive, are without guarantee and are for information purposes only.
