Chapter 7: Security Risk Management
74 Regulatory Affairs Professionals Society
such, dealing with security risk management for SaMD is no
different than for any other software, such as embedded soft-
ware and Programmable Electrical Medical Systems (PEMS).
Manufacturers should conduct security testing, such as
fuzz testing, vulnerability scanning, and penetration testing,
on systems configured in accordance with their intended
operational use environment. This testing verifies and val-
idates not only the software but also the technical and/or
organizational measures defined for the intended operational
use environment. For completeness, such tests also should be
conducted by the manufacturer in a test environment with
administrative credentials or the security controls on the
platform and the infrastructure disabled, to understand the
SaMD impact and risks when security controls fail in each
layer of defense. The product should support the ability for
the healthcare provider to perform security testing as required
by internal policy and legal obligations.
A manufacturer needs to recognize that they might
have limited control over the platform and infrastructure on
which the SaMD operates. For instance, the SaMD might be
running on a system shared with other software applications
and other users. Furthermore, there are no warranties that the
SaMD and supporting platform and software are kept up to
date by the user, resulting in multiple versions and combina-
tions being used on the market.
One of the key differences in SaMD security compared
with embedded software and PEMS is the varying level of
responsibility for specific activities, which depends on how
the SaMD is deployed and managed. Is it sold as a soft-
ware-only product, an on-premises solution, an off-premises
solution (cloud), or a hybrid solution? For each deployment
option, specific operational responsibilities shift from the
manufacturer to the customer/user. In most scenarios, the
manufacturer and/or the user might involve third parties to
perform parts of the operational responsibilities.
Therefore, there is a need to establish and document the
security responsibility boundaries, to ensure that responsi-
bilities for establishing and maintaining the technical and/or
organizational measures provided by the SaMD, the platform,
and the infrastructure are clearly defined and documented
for the manufacturer, the user, and any integrators or service
organizations under the user’s or manufacturer’s authority.
The following are some examples of such responsibilities:
• Who provides the platform, supporting software, and
infrastructure that the SaMD operates on–for instance,
the server with operating system and supporting soft-
ware components, such as databases, authentication
services, central logging services, and endpoint protection
software?
• Who will install and configure all the software, including
the platform and supporting software?
• Who is responsible for the maintenance, such as install-
ing updates, of the SaMD?
• Who is responsible for the daily operation and main-
tenance of the platform, supporting software, and
infrastructure?
• Will the manufacturer validate the patches of the
platform and supporting software components before
the user can install them, or is this entirely the user’s
responsibility?
• If the manufacturer validates the patches, how will this
be communicated, and how often?
• If the user maintains the platform, is there a need to
validate that the software is still functioning as intended
Figure 7-1. SaMD Security
Created by Ben Kokx
74 Regulatory Affairs Professionals Society
such, dealing with security risk management for SaMD is no
different than for any other software, such as embedded soft-
ware and Programmable Electrical Medical Systems (PEMS).
Manufacturers should conduct security testing, such as
fuzz testing, vulnerability scanning, and penetration testing,
on systems configured in accordance with their intended
operational use environment. This testing verifies and val-
idates not only the software but also the technical and/or
organizational measures defined for the intended operational
use environment. For completeness, such tests also should be
conducted by the manufacturer in a test environment with
administrative credentials or the security controls on the
platform and the infrastructure disabled, to understand the
SaMD impact and risks when security controls fail in each
layer of defense. The product should support the ability for
the healthcare provider to perform security testing as required
by internal policy and legal obligations.
A manufacturer needs to recognize that they might
have limited control over the platform and infrastructure on
which the SaMD operates. For instance, the SaMD might be
running on a system shared with other software applications
and other users. Furthermore, there are no warranties that the
SaMD and supporting platform and software are kept up to
date by the user, resulting in multiple versions and combina-
tions being used on the market.
One of the key differences in SaMD security compared
with embedded software and PEMS is the varying level of
responsibility for specific activities, which depends on how
the SaMD is deployed and managed. Is it sold as a soft-
ware-only product, an on-premises solution, an off-premises
solution (cloud), or a hybrid solution? For each deployment
option, specific operational responsibilities shift from the
manufacturer to the customer/user. In most scenarios, the
manufacturer and/or the user might involve third parties to
perform parts of the operational responsibilities.
Therefore, there is a need to establish and document the
security responsibility boundaries, to ensure that responsi-
bilities for establishing and maintaining the technical and/or
organizational measures provided by the SaMD, the platform,
and the infrastructure are clearly defined and documented
for the manufacturer, the user, and any integrators or service
organizations under the user’s or manufacturer’s authority.
The following are some examples of such responsibilities:
• Who provides the platform, supporting software, and
infrastructure that the SaMD operates on–for instance,
the server with operating system and supporting soft-
ware components, such as databases, authentication
services, central logging services, and endpoint protection
software?
• Who will install and configure all the software, including
the platform and supporting software?
• Who is responsible for the maintenance, such as install-
ing updates, of the SaMD?
• Who is responsible for the daily operation and main-
tenance of the platform, supporting software, and
infrastructure?
• Will the manufacturer validate the patches of the
platform and supporting software components before
the user can install them, or is this entirely the user’s
responsibility?
• If the manufacturer validates the patches, how will this
be communicated, and how often?
• If the user maintains the platform, is there a need to
validate that the software is still functioning as intended
Figure 7-1. SaMD Security
Created by Ben Kokx