Manufacturers and software developers who market their products in different nations cannot rely on a single approach to regulation, which is especially true of cybersecurity for software as a medical device (SaMD) and software in a medical device (SiMD). This blog is the first in a series of installments regarding the regulatory systems in Canada, the European Union (EU), the U.K., and the U.S., which we hope will help our clients more readily adjust to these requirements despite the sometimes wildly disparate regulatory frameworks.
Cybersecurity is one of the more anxiety-producing elements of the device life cycle, and the U.S. House of Representatives is preparing to add to the FDA’s cybersecurity enforcement toolkit. While it seems likely that these components of the FDA user fee legislation will carry through, we’ll consider the regulations the FDA currently has on the books rather than speculate on what might change upon passage of the Food and Drug Amendments of 2022.
There are a number of overarching features of cybersecurity for devices, three of which we’ll consider in this blog. They are:
- The role of ISO 14971 in cybersecurity risk management;
- The question of whether cybersecurity risk management is separate from overall device risk management; and
- Whether premarket and postmarket cybersecurity policy are articulated in one rather than multiple guidance documents.
We recently gave our clients a look at the FDA’s new draft guidance for premarket cybersecurity considerations, including the draft’s perspectives on ISO 14971. The FDA’s position on the ISO standard is that 14971 is inadequate for the task of managing cybersecurity risks. In the FDA’s view, 14971’s probabilistic approach to risk management – often based on historical data for a given device or similar devices – fails to account for the deliberate nature of most cybersecurity threats.
In contrast, Health Canada sees ISO 14971 as an appropriate method of risk management for cybersecurity per its 2019 guidance for premarket cybersecurity requirements. Section 2.1.2 of the guidance states that the 2007 version of 14971 (ISO released an updated edition of 14971 in 2019) should be incorporated throughout the product life cycle, but that a developer or manufacturer should consider cybersecurity per AAMI TIR57 as well. The AAMI standard is also cited in the FDA draft, so there is at least some overlap between the two agencies’ approaches despite their disparate views of the utility of ISO 14971.
As matters currently stand in the U.K., the 2002 Medical Devices Regulations offer little insight into device cybersecurity, which may change pending the latest proposed overhaul of medical device regulation. In the meantime, NHS Digital has a 2019 guidance for protecting medical devices used in clinical settings, but National Health Service (NHS) trusts are the target audience, not industry. Ergo, there is a question as to whether compliance liability applies to manufacturers and vendors outside the scope of any obligations incurred via contracts undertaken with one or more of the trusts.
With that caveat in mind, this guidance mentions neither ISO 14971 nor AAMI TIR57. The guidance is broad and offers few specifics, and offers a number of suggestions, such as minimizing the amount of time a medical device is connected to a healthcare facility network.
The picture in the U.K. is certain to change significantly when MHRA finalizes the new regulatory regime, as suggested by the draft regulation from late last year. This consultation is remarkably exploratory in nature. There is no reference to ISO 14971, nor are there any specific proposals regarding risk other than the device’s general risk. Unfortunately, it’s nearly impossible to predict where this proposal will land on cybersecurity risk management.
The European Union’s Medical Device Coordination Group (MDCG) published a July 2020 update to its 2019 guidance on cybersecurity, which mentions 14971 only in an annex that lists standards of interest. There is no mention of AAMI TIR57, but we would point out that at 47 pages, this guidance is one of the more detailed active guidances on device cybersecurity. The guidance is applicable to products regulated under both the Medical Device Regulation (MDR) and the In Vitro Diagnostic Regulation (IVDR).
In summary, ISO 14971 is not seen by the FDA or the MDCG as a primary reference for device cybersecurity risk management, while Health Canada seems comfortable with the ISO standard as the primary driver of cybersecurity risk assessment. Again, we are hesitant to speculate as to how this question will be answered in the U.K.’s pending regulatory overhaul, but MHRA has indicated in the past that it would attempt to track its regulatory framework as closely as possible to the EU system.
FDA, Health Canada, See Cybersecurity Risk as Separate
On the question of the respective roles of overall risk management and cybersecurity risk management, the FDA’s position is clear. While the agency’s most recent draft guidance for premarket cybersecurity considerations no longer features a two-track risk management for device risk management and cybersecurity risk management, the draft does explicitly state that exploitability is a concept that is distinct from non-cybersecurity failure modes.
Health Canada’s approach seems to call out cybersecurity risk management as a separate consideration in Section 2.1.2 of the guidance, given that there are specific provisions. However, the guidance also explicitly states that manufacturers should incorporate device cybersecurity into the overall risk management process for each device, and then provides a flowchart that suggests that cybersecurity risk management be conducted in parallel with overall risk management.
Consequently, it may be assumed that developers and manufacturers that are subject to Health Canada inspections should document a somewhat distinct cybersecurity risk management process to present during those inspections. Beyond all this, Health Canada also recommends that developers and manufacturers assemble and maintain an organizational framework for cybersecurity risk management, and the net effect of all this is to suggest that Health Canada expects two distinct risk management processes.
The MDCG guidance seems to recommend that cybersecurity risk management be subsidiary to overall risk management, as seen in the statement that the cybersecurity risk management process has the same elements as safety risk management processes. These would both be documented in a single risk management plan, although that plan should account for any interplay between conventional safety risks and cybersecurity risks.
MDCG also included the statement that the risk management process explicitly encompasses system security within the scope of the overall risk management process, a notation intended to clarify that developers and manufacturers would not have to devise separate processes. However, the guidance also states that security risks call for specific methods and requirements to manage those risks. The NHS Digital guidance is distinct from general device risk management, and there is no apparent premarket liability for manufacturers and developers under this policy.
The final question in this blog, that of whether these agencies have more than one guidance to express cybersecurity risk management policy, is not a complicated one, but it does speak to the complexity of compliance. The FDA has two guidances, one each for premarket and postmarket considerations, while Health Canada and the MDCG declined to craft separate policy documents for premarket and postmarket considerations.
While there is little to be gained by speculating on how the U.K.’s regulation for cybersecurity risk will address a number of specific questions, it seems likely that it will follow suit with the MDCG and Health Canada, particularly given that the International Medical Device Regulators Forum has only one guidance for both phases of the product life cycle.
It does seem that the FDA has willingly steered a unique course on whether to separate premarket and postmarket considerations, and there seems little prospect that any of the other players in this regulatory game will follow suit. While it is encouraging that most regulatory frameworks rely on a single guidance document for cybersecurity risk management, businesses that market in multiple jurisdictions will still have a complex cross-walking process ahead of them as regulatory agencies (and legislatures) react to the seemingly limitless supply of bad cyber-actors.