Risk Management SOP - Include Security Risk Management?

[TomQA]

Hello,
Our current Risk Management SOP is based on ISO 14971 and described the "Safety Risk Management" process. Should we also indicate in this same procedure the "Security Risk Management" process, as described for instance in "AAMI TIR57:2016/(R)2019 - Principles for medical device security—Risk management", and its interaction with "Safety Risk Management" ?

 

[Ed Panek]

Yes and No. For our product, we do add cyber security risks. We also have a separate QMS section dealing with office network cybersecurity that the user of our product may not be interested in, but an investor might be.

 

[TomQA]

Good point.
Yes this is an SOP dedicated for Product Risk Management.

 

[Ed Panek]

I would suggest a strong cybersecurity presentation in any regulatory submission, especially FDA and MDD MDR.

Integrating these two processes in your SOP would provide a comprehensive approach to risk management, covering both safety and security aspects.

 

[Parul Chansoria]

Hi @TomQA. Some suggestions:

1. Include all product related security pointers in your Risk Management SOP or "Safety Risk Management" process, and if your company makes (or plans to make in the future) different kinds of products, some to which security requirements may apply and others to which the security requirements may not apply, it would be wise to define the scope of the security elements of the Risk Management SOP.

2. There will be peripheral risk requirements (not directly product) but related to network, etc., for that it is better to have a separate SOP and your Risk Management SOP can point to this other security SOP, as applicable. This will help keep scope and applicability segregated, while still meeting all the requirements as a whole.

Best,
Parul Chansoria

 

[QuinnM]

Hi,
Our product is medical device software, SaMD, So we include the cyber security risks in the risk management plan. A cyber security issue could influence or product.
Best regards,
Ted

 

[Tidge]

Hello,
Our current Risk Management SOP is based on ISO 14971 and described the "Safety Risk Management" process. Should we also indicate in this same procedure the "Security Risk Management" process, as described for instance in "AAMI TIR57:2016/(R)2019 - Principles for medical device security—Risk management", and its interaction with "Safety Risk Management" ?

I would NOT directly include (cyber)security in the SOP for "14971" compliance. From memory, AAMI TIR57 suggests establishing a parallel process (essentially identical) to the 14971 process, and then 'linking' them (as appropriate) when security design decisions impact the risk profile of safety concerns and vice versa. I like this approach for medical device manufacturers.

On the surface, maintaining two parallel document sets may appear to be increasing the work load and increasing the number of documents. I think the advantages to keeping them separate are:

1) Cybersecurity is a rapidly changing landscape... such that even documenting how security risks are addressed may come under scrutiny, forcing radical changes to those documents. Documenting safety (in the context of 14971) is an area where people are relatively comfortable reviewing slightly different files, and there are consensus approaches to default to.

2) Cybersecurity has a radically different concept of harms than Safety does. Inviting the two different types of harms to live in the same SOP is inviting trouble, IMO.

3) The outputs of a cybersecurity risk management process could be leveraged in ways that the outputs of a safety risk management plan would not be. My experience has been that safety risk management files are almost exclusively only used internally, and are only occasionally reviewed by external groups such as regulatory authorities or their representatives. A well-constructed suite of security risk management files should allow a manufacturer to rapidly answer questions from prospective customers... such as when a customer won't buy the product unless the manufacturer fills out an MDS2 form or answers a prospective customer's questions.

Point 3 is a long-winded way of saying that in the area of cybersecurity: there is no consensus approach that the medical device isn't itself inherently risky or that it isn't introducing security risks. With safety, there is a common understanding (enforced by following established consensus standards) that a device approved by regulatory authorities is safe. I would segregate the areas where consensus exists from the area where there is no stable consensus. Tailor the security risk management process to satisfy its needs, and feed it into safety risk management as necessary.