Questionnaire “Cybersecurity for Medical Devices - Technical

Documentation”
Version 1, dated 21st of March, 2023

1. 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. It makes no claim to completeness or
mandatory application.
• This document covers assessments of Technical Documentation for MDR / IVDR.
Not all requirements of MDR, IVDR and MDCG 2019-16 are covered in this
document.
• 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). It replaces the previous version “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”.
• Compliance to IEC 81001-5-1 is not expected, however recommended, prior to the
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.
References:
• Regulation (EU) 2017/745 (MDR), dated 5 April 2017
• MDCG 2019-16 - Guidance on Cybersecurity for medical devices, Rev. 1, 2020-07
• IEC 62304:2006-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

2. System Description
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
2. Stat An Is an Yes, see:- Software development plan-
1 e of appropriate appropriate Software architecture
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
the system system diagram
Art diagram must available?
(SOT be available.
A)
2. IEC ‘All products Note: a complete Potential cyber security risks and IT-
2 810 have a threat system diagram security concerns have been taken into
01- model specific should include account within the framework of the
5-1 to the current the following:1. existing FMEA risk analysis, following the
cl. development All medical ISO 14971 standard for risk management
7.2 scope. devices incl. in medical devices.
Characteristic their interfaces
s (where (e.g. bluetooth,
applicable): wifi, ethernet),
correct flow utilized
of categorized protocols (e.g.
information HL7, DICOM,
throughout HTTPS, MQTTS,
the system, custom) on
trust those interfaces
boundaries, and their
data stores, implemented
internal/exter technical
nal specification
communicatio (e.g.
n protocols implemented
etc.’ protocol
version) incl. the
type of data
being
transferred (e.g.
personal health
information,
therapeutic
commands,
updates, remote
access) on those
interfaces.2. All
human machine
interfaces
within the
system (e.g.
screens,
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
keyboards).

3. Security Risk Management

It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
3. MDC ‘The security Is a security risk Yes, see:- Risk management plan- Risk
1 G risk analysis table- Risk management report
201 management available?
9-16 process has
cpt. the same
3.2 elements as
the safety risk
management
process, all
documented
in a security
risk
management
plan. The
process
elements are
security risk
analysis,
security risk
evaluation,
security risk
control,
evaluation of
residual
security risk
and
reporting.’
3. MDC ‘Threat Does the Potential cyber security risks and IT-
2 G Modelling security risk security concerns have been taken into
201 techniques assessment account within the framework of the
9-16 are a contain an existing FMEA risk analysis, following the
cpt. systematic appropriate and ISO 14971 standard for risk management
3.4a approach for systematic in medical devices.
ndIE analyzing the threat model?
C security of an Note: STRIDE is
810 item in a a systematic
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
01- structural threat modelling
5-1 way such that technique, since
cl. vulnerabilities it evaluates
7.2 can be threat
identified, categories
enumerated interface by
and interface.
prioritized, all
from a
hypothetical
attacker’s
point of
view.’AND‘(…)
Employ
activities to
ensure that all
products have
a threat
model specific
to the current
development
scope.’
3. MDC ‘Threat Is the threat Yes, see risk table.
3 G modelling model complete
201 typically and correct
9-16 employs a (e.g. discussing
cpt. systematic all applicable
3.4 approach to threats for all
identify attack relevant attack
vectors and vectors)?
assets most
desired by an
attacker.’AND
- ‘Establish
activities
which identify
and document
any
vulnerabilities
, threats and
associated
adverse
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
impacts
affecting
confidentialit
y, integrity,
availability of
assets.-
Consider
intended use
and the
intended
environment
of use.’
3. IEC - Establish Is the risk pre- Yes, see:- Risk table- Risk management
4 810 activities to and post- report
01- estimate risk mitigation
5-1 of appropriately
cl. vulnerabilities estimated?Note
7.3 .- Risk 1: quantitative
estimation risk assessment
should is
consider acceptable.Note
adverse 2: security risk
impact of is a combination
vulnerability of exploitability
to security- and
Estimation severity.Note 3:
can be alteration or
supported by disclosure of
using patient data can
vulnerability lead to harm.
scoring-
Scoring
system can be
based on a
likelihood/sev
erity scheme
used by the
manufacturer
for other
risks-
Evaluate
estimated
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
risks-
Determine if
risk is
acceptable or
not (based on
scoring)-
Inform
product risk
management
process
3. MDC ‘When a Are security Yes, see:- Risk table- Risk management
5 G security risk mitigations (if report
201 or control any) that might
9-16 measure affect safety
cpt. could have a appropriately
3.2 possible discussed?
impact on
safety and
effectiveness,
then it should
be included in
the safety risk
assessment.’
3. MDC ’Where there Do risk control Yes, see:- Risk table- Risk management
6 G is an impact solutions have report
201 on safety or the correct
9-16 effectiveness, order or
cpt. manufacturer priority?Note:
3.3 s shall select according to
the most MDR/IVDR, the
appropriate auditee shall
risk control always
solution, in implement
the following security
order of measures within
priority:a) the device
Eliminate or rather than
reduce risks delegating
as far as security via IFU
possible to the user or
through safe admin of the
design and device.
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
manufacture;
b) Where
appropriate,
take adequate
protection
measures,
including
alarms if
necessary, in
relation to
risks that
cannot be
eliminated;c)
Provide
information
for safety
(warnings/pr
ecautions/con
tra-
indications)
and, where
appropriate,
training to
users.For
security, a
similar
approach can
be taken:a)
Eliminate or
reduce
security risks
as far as
feasible
through
secure design
and
manufacture;
b) Where
appropriate,
take adequate
protection
measures,
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
including
security
notifications if
necessary, in
relation to
risks that
cannot be
eliminated;c)
Provide
information
for security
(warnings/pr
ecautions/con
tra-
indications)
including
information
on measures
that the user
is required to
take in the
operating
environment
to reduce the
likelihood of
exploitation.
3. IEC - Determine Are risk control Yes, see:- Risk table- Risk management
7 810 whether measures / report
01- security risk counter
5-1 control measures
cl. measures are appropriate?
7.4 appropriate
for reducing
security risks
to an
acceptable
level (based
on security
risk
acceptance
policies)- If
risk controls
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
are deemed
appropriate:
appropriate
mitigations
selected-
Determine
whether
mitigations
result in new
risks or
increased
other risks,-
Select
mitigations
implemented,
effectiveness
of the
implemented
measures
verified
3. MDC ‘Key concepts Is the security Yes, see:- Risk table- Risk management
8 G involved in IT concept of the report- Software development plan
201 security device under
9-16 specifically evaluation
cpt. for medical appropriate?
2.1a devices are
ndM the
DR following:-
Ann Confidentialit
ex I y of
(17. information at
4) / rest and in
IVD transit-
R Integrity,
Ann which is
ex I necessary to
(16. ensure
4)an information
dMD authenticity
R and accuracy
Ann (i.e. non-
ex I repudiation)-
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
(18. Availability of
8)an the processes,
dMD devices, data,
R and
Ann connected
ex I systems.‘AND‘
(17. Manufacturer
2) / s shall set out
IVD minimum
R requirements
Ann concerning
ex I hardware, IT
(16. networks
2) characteristic
s and IT
security
measures,
including
protection
against
unauthorised
access,
necessary to
run the
software as
intended.’AN
D‘Devices
shall be
designed and
manufactured
in such a way
as to protect,
as far as
possible,
against
unauthorised
access that
could hamper
the device
from
functioning as
intended.’AN
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
D‘The
Cybersecurity
risks are as
far as possible
reduced
without
adversely
affecting the
benefit-risk
ratio. The
device is
developed in
accordance
with the state
of the art
taking into
account the
principles of
risk
management,
including
information
security.’

4. Accompanying Documentation
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
4. MDC ‘While the Are the Yes, see:- Instructions for use / user
1 G MDR and the responsibilities manual
201 IVDR provide of manufacturer,
9-16 legal integrator and
cpt. obligations users correctly
2.6a only with reflected in the
ndM regard to IFU?Note: in
DR manufacturer cases where the
Ann s, however it medical device
ex I should be relies on the
(23. noted that for operating
4.ab the provision environment to
)/ of secured provide
IVD healthcare essential IT
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
R services, it is security
Ann important to controls, this is
ex I recognize the appropriately
(20. roles and stated in the
4.1.a expectations accompanying
h) of all technical
stakeholders, documentation.
such as
manufacturer
s, suppliers,
healthcare
providers,
patients,
integrators,
operators and
regulators. All
of these
actors share
responsibilitie
s for ensuring
a secured
environment
for the benefit
of patients’
safety.’ANDTh
e instructions
for use shall
contain all of
the following
particulars:
‘for devices
that
incorporate
electronic
programmabl
e systems,
including
software, or
software that
are devices in
themselves,
minimum
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
requirements
concerning
hardware, IT
networks
characteristic
s and IT
security
measures,
including
protection
against
unauthorised
access,
necessary to
run the
software as
intended.’
4. MDC ‘The Does the Yes, see:- Instructions for use / user
2 G requirements accompanying manual- User training
201 regarding the documentation
9-16 instructions appropriately
cpt. for use are contain the
4.2 outlined in following (if
the following applicable):-
articles of Any residual
Annex I’ cybersecurity
risk
communicated
as limitation,
contraindication
, precaution or
warning-
Information
about product
installation such
as configuration
of security
features (CNFS).
Note: this does
NOT mean the
documentation /
or provisioning
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
of passwords for
assessment in
the
accompanying
documents. Also
include required
information
about any
necessary 3rd
party software
such as anti-
virus software,
firewall,
malware
detection/prote
ction (MLDP)
and minimum
requirements
for OS,
workstation,
peripherals.-
Procedures for
using the
medical device
in fail-safe mode
/ action plan for
users to follow
in case of alert
messages-
Information
about user
requirements in
terms of training
/ required
skills-
Instruction on
installing
(cybersecurity)
updates &
patches (CSUP)-
The
environment of
 It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
use (home
environment,
healthcare
facility, etc.)- A
description of
data backup
(DTBK) and
restore features-
User roles incl.
privileges-
Information
about logging

5. Lifecycle (Relevant Output Documents)

It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
5. IEC ’Document for Has the Yes, see:- SOUP
1 623 each SOUP manufacturer
04 configuration documented all
cl. item being SOUP
8.1.2 used components?
(incl. standard
libraries):
title,
manufacturer,
unique SOUP
designator.”
5. MDC ‘The primary - Is the Security verification and validation was
2 G means of penetration test performed as part of system testing. See
201 security report available system test results.
9-16 verification and
cpt. and validation appropriate?- Is
3.7a is testing. the penetration
ndIE Methods can test covering all
C include applicable
810 security attack vectors?-
01- feature Is the tester
5-1 testing, fuzz appropriately
cl. testing, skilled?- Is the
5.7.5 vulnerability tester
scanning and independent?-
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
penetration Are appropriate
testing.’AND‘ tools used?- Is
Documented enough time /
means of resources
ensuring utilized? Is
objectivity of appropriate
the test effort Fuzz Testing
for security conducted
requirements where
testing, applicable?Note
known 1: Common
vulnerability penetration
scanning and testing
penetration methodologies
testing.’ such as open-
source security
testing
methodologies
(OSSTMM),
MASTG, phased
structured
approaches such
as penetration
testing
execution
standard (PTES)
methodologies
should be
adapted as
appropriate for
the medical
device until
appropriate
standards are
available.Note 2:
The penetration
test should
consider any
special
constraints
relating to the
medical
It
e Sour Requirement( IG-NB
m ce s) Commentary Manufacturer Reference for Compliance
device(s) such
as the safety of
the patient and
others as well as
clinical
performance.No
te 3: ISO 17025
accredited test
laboratories
with
appropriate
capability and
competence for
medical device
penetration
testing should
be used once
available.