Questionnaire "Cybersecurity for Medical Devices - Audit“

(Version 1, 21.03.2023)

Preliminary remarks ............................................................................................................... 1

References ............................................................................................................................. 2
Terms and Definitions............................................................................................................. 2
Changes to last version .......................................................................................................... 2
1 General ........................................................................................................................... 3
2 Research and Development ............................................................................................ 5
3 Post Market Activities ...................................................................................................... 8
4 Vigilance Reporting ....................................................................................................... 11

Preliminary remarks

 This document was compiled by the German Notified Bodies Alliance

(Interessengemeinschaft der Benannten Stellen für Medizinprodukte in Deutschland - IG-
NB) and is intended to serve as orientation for Notified Bodies, manufacturers and
interested parties.
 This document is covering cybersecurity in regular scheduled MDR / IVDR audits.
 Created by Jan Küfner (TÜV SÜD), Dr. Abtin Rad (TÜV SÜD), Dr. Andreas Schwab (TÜV
Rheinland), Volker Sudmann (mdc medical device certification), Markus Bianchi (DNV
Medcert), Martin Tettke (Berlin Cert), Michael Bothe (DQS Med), Mark Küller (TÜV-
Verband / IG-NB)
 This document, together with the questionnaire „Cybersecurity for Medical Devices –
Technical Documentation“, replaces the questionnaire "IT security for Medical Devices“
(Version 5, 09.06.2022).
 Questions regarding the security risks of artificial intelligence can be found in latest
version of IG-NB's "Questionnaire Artificial Intelligence (AI) in Medical Devices"
(https://www.ig-nb.de/veroeffentlichungen).
 Not all requirements of MDR, IVDR and MDCG 2019-16 are covered in this document.
Compliance to IEC 81001-5-1 is not expected prior end of its transition period.
Compliance to IEC 81001-5-1 prior its transition period is however recommended.
 In the following tables IEC 81001-5-1 is mentioned only for complementary purposes.
Questions for manufacturers are solely based on the current requirements (MDR, IVDR,
MDCG 2019-16)
 Since cybersecurity evolves on a regulatory and technological level, this document is
intended to reflect the current state of the art at the time of creation only.
 There are few cybersecurity experts today and it is likely that the situation will continue to
be a similar in the foreseeable future. Therefore it is one goal of this paper to help making

1
 conformity assessment(s) of cybersecurity aspects as efficient as possible without
compromising quality.
 The terminology used in this document is derived from the terms and definitions within the
referenced sources. E.g. cybersecurity as defined in ISO 81001-1:2021-12, cl. 3.30.
 Included in this document are references to paragraphs from the standards IEC 62034
and IEC 81001-5-1. These standards have different scopes (medical device software (IEC
62304) and healthcare software (IEC 81001-5-1)) and use different terms for similar
subjects and processes. Specific terms and their use in the context of the respective
standard are defined in clause 3 "Terms and Definitions" of the respective standard.
 The document makes no claim to completeness or mandatory application.

References

 REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE

COUNCIL of 5 April 2017 on medical devices, amending Directive 2001/83/EC,
Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council
Directives 90/385/EEC and 93/42/EEC (2017/745/EU) (MDR)
 REGULATION (EU) 2017/746 OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive
98/79/EC and Commission Decision 2010/227/EU (2017/746/EU) (IVDR)
 MDCG 2019-16 - Guidance on Cybersecurity for medical devices, Rev. 1, 2020-07
 ISO 13485:2016-03 Medical devices - Quality management systems - Requirements for
regulatory purposes
 IEC 62304:2005-05 Medical device software - Software life cycle processes
 IEC 81001-5-1:2021-12 Health software and health IT systems safety, effectiveness and
security — Part 5-1: Security — Activities in the product life cycle

Terms and Definitions

 In this document, the term medical device is frequently used. Whenever the term medical
device is mentioned, both types are meant, medical devices and in vitro diagnostic
medical devices.

Changes to last version

2
1 General

Source Requirements Questions / Comments

1. ISO 13485 – definition, documentation and communication of Has the auditee defined responsibilities and authorities for
cl. 5.5.1 responsibilities and authorities by top management cybersecurity?
– documentation of interrelations
– ensure independence and authority Has the auditee defined a person or persons responsible for
IEC 81001-5-1 – designate and document organizational roles cybersecurity within the company?
cl. 4.1.2 – designate and document personnel responsible for
activities and processes
2. ISO 13485 – only competent personnel should be performing work Has the personnel carrying out cybersecurity tasks
cl. 6.2 affecting quality appropriate education and/or work experience and/or
– basis: appropriate education, training, skills, training?
experience
IEC 81001-5-1 – established activities for identifying and providing
cl. 4.1.4 security training and assessment programs
– personnel should be assigned to the organizational
roles and duties demonstrated security expertise
– role descriptions, training profiles, training records
3. ISO 13485 – establish criteria for evaluation and selection of Are the suppliers (penetration testing laboratories, 3rd party
cl. 7.4.1 suppliers component suppliers) appropriately qualified?
– basis: specific criteria (supplier - ability to provide
product that meets requirements and performance of Note 1: Penetration testing laboratories should be accredited
the supplier, effect of purchased product on quality, where available.
proportionate to the risk)
Note 2: Supplier evaluation of 3rd party components is not
necessary when the quality of the code can fully be verified.

3
Note 3: Auditing penetration testing laboratories seems to be
not necessary. Other means for rating performance and
ability of penetration-testing suppliers (e.g. penetration test
report reviews, questionnaires) seem more plausible.

4
2 Research and Development

Source Requirements Questions / Comments

1. MDR ’For devices that incorporate software or for software that Note 1: Cybersecurity risk assessment
Annex I (17.2) are devices in themselves, the software shall should be conducted prior to the finalization
be developed and manufactured in accordance with the of specifications / cybersecurity risk
IVDR state of the art taking into account the principles of management shall be conducted at the
Annex I (16.2) development life cycle, risk management, including design input phase. (applicable for R&D
information security, verification and validation. projects that started after the release of
MDCG 2019-16 chapter 3 ‘Safety, security and effectiveness are critical aspects in MDCG 2019-16 in November 2019).
the design of security mechanisms for in vitro diagnostic
medical devices and medical devices. Therefore, there is Note 2: For legacy devices, the approach as
a clear requirement that these aspects need to be defined in 81001-5-1 appendix F may be
considered by the manufacturers from an early stage of used.
development and manufacturing process and
throughout the entire life cycle.’ Note 3: It is not acceptable to add
cybersecurity countermeasures (e.g.
encryption) at the end of a development cycle
project since this concept is following the
outdated “penetrate and patch” approach.

5
 Source Requirements Questions / Comments
MDCG 2019-16 ‘The security risk management process has the same Is a dedicated and plausible security risk
chapter 3.2 elements as safety risk management process, all assessment available for all MDR / IVDR
documented in a security risk management plan. The certified devices?
process elements are security risk analysis, security
risk evaluation, security risk control, evaluation of
residual security risk and reporting. When a security
risk or control measure could have a possible impact
on safety and effectiveness, then it should be included
in the safety risk assessment. Similarly, any safety risk
control or consideration that might have an impact on
security should be included in the security risk analysis.’
2. MDCG 2019-16 chapter 3.4 ‘Threat Modelling techniques are a systematic Note 1: Threat modelling (e.g. STRIDE)
approach for analyzing the security of an item in a should be used in security risk assessment.
structural way such that vulnerabilities can be identified,
enumerated, and prioritized, all from a hypothetical Note 2: Security risk assessment is assessed
attacker’s point of view. Risks related to data and in depth during the Technical Documentation
systems security are specifically mentioned within the Assessment (TDA). During audit, it should be
scope of the risk management process, to avoid any focused on identifying if non-sampled devices
misunderstanding that a separate process would be also have security risk management including
needed to manage security risks related to medical threat modelling.
devices. Specific methods (and requirements) are
however used for security risks.’
IEC 81001-5-1 – establish process for managing risks associated with
cl. 4.2 security
– use threat modelling for identifying vulnerabilities
– estimate, evaluate and control associated threats
– monitor effectiveness of (security) risk control
measures
– intended use and use environment

6
 Source Requirements Questions / Comments
3. MDCG 2019-16 ‘The primary means of security verification and validation Do all MDR / IVDR devices of the auditee
chapter 3.7 is testing. Methods can include security feature testing, have a recent penetration test?
fuzz testing, vulnerability scanning and penetration
testing.’ Note 1: Vulnerability scanning and
penetration testing should be done for all
medical devices.
IEC 81001-5-1 – establish activities to identify and characterize
cl. 5.7.4 weaknesses Note 2: Security test reports (including
– Establish tests that focus on discovering and penetration test reports) are assessed in
exploiting security vulnerabilities depth during Technical Documentation
Assessment (TDA). During audit, it should be
focused on identifying if non-sampled devices
also have penetration test reports.

7
3 Post Market Activities

Source Requirements Questions / Comments

1. MDCG 2019- ’During the support lifetime of the device, the Does the post-market surveillance system gather and
16 chapter 3.8 manufacturer should put in place a process to gather evaluate:
post-market information with respect to the security of the  security incidents directly related to the medical devices of
device (see also Chapter 6). This process should take the manufacturer?
into account: Note: These can be reported via complaint and feedback
1. Security incidents directly related to medical device processes.
software  the cybersecurity threat landscape?
2. Security Vulnerabilities that are related to the medical
device hardware/software and the 3rd party Note 1: The auditee should be capable of using appropriate
hardware/software used with the medical device. measures if a significant increase is detected / the auditee
3. Changes in the threat landscape, including should have appropriate threat intelligence at his/her
interoperability aspects’ disposal.
IEC 81001-5-1 – establish activities to collect and review relevant
cl. 6.2.1 sources of information about vulnerabilities Note 2: Security vulnerabilities directly related to the medical
devices of the manufacturer are discussed in the following.
2. IEC 81001-5-1 – establish activities that enable reporting of information Does the auditee have an appropriate Vulnerability
cl. 9.2 regarding vulnerabilities (from an internal/external Disclosure Program in place?
entity or via a complaint-handling system)
– reception activity: receive and track closure reports on Note 1: The Vulnerability Disclosure Program shall make it
security related issues possible for security researches etc. to submit vulnerabilities
– including (minimum) sources as security to the manufacturer securely. Information about possible
verification/validation tester, suppliers of third-party vulnerabilities shall be assessed / triaged and mitigated
components, product developers and testers, … appropriately with an appropriate timeline by the
manufacturer. Bug bounties may or may not be provided to
the security researchers.

8
 Source Requirements Questions / Comments
Note 2: The Vulnerability Disclosure Program can be
governed by the feedback process.

Note 3: Audit event logs shall be obtained and analysed

timely and appropriately.
3. IEC 62304 – establish software development plan/plans that Do all medical devices have a list of software of unknown
cl. 5.1.1 address software configuration and change provenance (SOUP) components?
management
– including SOUP configuration items Note: The list of SOUP-components can be part of SBOM /
can be the SBOM (Software Bill of Materials).

IEC 62304 – document for each SOUP configuration item used

cl .8.1.2 (including standard libraries): title, manufacturer,
unique SOUP designator
4. MDCG 2019- ‘The manufacturer should evaluate the information thus Does the auditee conduct proper security patch
16 chapter 3.8 gathered, evaluate the associated security and safety management?
risk and take appropriate measures that control the risk
associated with such security incidents or vulnerabilities. Note 1: Scanning / Checking SOUP components for
Measures may include: vulnerabilities shall be conducted in intervals commensurate
 Information to operators of medical devices on the with the risk to patient safety and or data. Checks / Scans
identified risk and possible mitigations in the operating should be documented.
environment.
 Quick fixes, e.g. network configuration changes. Note 2: Any necessary corrective action (patching, firewall
 Medical device software updates. configuration updates, etc.) should be commensurate with the
 3rd party software updates or patches.

9
 Source Requirements Questions / Comments
The measures should be implemented at the operator risk and implemented in a timely manner. Rationales for not
site in a time appropriate to the security and safety risk conducting actions should be appropriate.
determined by the manufacturer and operator.’
IEC 81001-5-1 - establish activities that enable investigation of
cl. 9.3 vulnerabilities in a timely manner to determine
applicability
- verifiability, related threats
IEC 81001-5-1 - establish activities for analysing vulnerabilities
cl. 9.4 - identifying root cause of the issue
- identifying impact on safety and effectiveness
IEC 81001-5-1 - establish activities to address security-related issues
cl. 9.5
5. IEC 81001-5-1 – establish activities for conducting periodic reviews of Does the auditee conduct at minimum an annual review of
cl. 4.1.8 the software problem resolution process the security patch management process?
– periodic reviews of activities
– examine (minimum) security-related issues managed Note 1: In case periodic review shows lack of performance of
through process (since last periodic review) the software problem resolution process working
– determine if management process was complete, appropriately, corrective measures need to be implemented.
efficient, led to resolution of security-related issues
– periodic reviews at least annually or as part of Note 2: An efficient measure to verify effectiveness of security
monitoring, measurement, analysis patches implemented can be penetration testing.

10
4 Vigilance Reporting

Source Requirements Questions / Comments

1. MDCG 2019-  The reporting tools made available to the Do all Manufacturer Incident Report (MIR) forms have an
16 Manufacturer enable the use of IMDRF codes to IMDRF code?
chapter 5.2 index.
 IMDRF Annex A codes on cybersecurity-related
device problems:
o Level 2: A1105 — Computer System Security
Problem.
o Level 3: A110501 — Application Security
Problem.
o Level 3: A110502 — Unauthorised Access to
Computer System.
IEC 81001-5-1 – establish activities for informing regulatory authorities
cl. 4.1.7 and users about vulnerabilities in a timely manner
2. MDR ‘Manufacturers shall report, by means of the electronic Is the auditee able to report trends in cybersecurity-related
Article 88 (1) system referred to in Article 92, any statistically incidents once the electronic system is available?
significant increase in the frequency or severity of
IVDR incidents that are not serious incidents or that are
Article 83 (1) expected undesirable side-effects that could have a
significant impact on the benefit-risk analysis referred to
in Sections 1 and 8 of Annex I and which have led or
may lead to risks to the health or safety of patients, users
or other persons that are unacceptable when weighed
against the intended benefits.’

11
Source Requirements Questions / Comments
MDCG 2019-  ‘Incidents that have cybersecurity related incident
16 root causes are subject to Trend Reporting under
chapter 5.8 the Medical Devices Regulations.’
 ‘Using IMDRF codes to index the cybersecurity
medical root causes related to non-serious incidents is
desirable and may be implemented into the Trend
Report’:
o C1007 — Software Security Vulnerability

12