Contains Nonbinding Recommendations
6
In the premarket context, in order to demonstrate a reasonable assurance of safety and 
effectiveness for certain devices with cybersecurity risks, documentation outputs related to the 
ongoing requirements of the QMSR may be one source of documentation to include as part of 
the premarket submission.17 This guidance is intended to explain how such documentation that 
may be relevant for QMSR compliance can also be used to show how a sponsor or manufacturer 
is addressing cybersecurity considerations relevant to a device. For example, 21 CFR 820.10(c) 
requires that for all classes of devices automated with software, a manufacturer must comply 
with the requirements in Design and Development, Clause 7.3 and its subclauses of ISO 13485.18
As part of design and development, “[d]esign and development validation shall be performed in 
accordance with planned and documented arrangements to ensure that the resulting product is 
capable of meeting the requirements for the specified application or intended use” (Subclause 
7.3.7). Design and development validation includes validation of device software. In addition, 
Subclause 7.1 of ISO 13485 specifies that the “organization shall document one or more 
processes for risk management in product realization.” As part of the software validation 
required by Subclause 7.3.7, and risk management, including the requirements of Subclause 7.1, 
software device manufacturers may need to establish cybersecurity risk management and 
validation processes, where appropriate. See also FDA’s guidance titled “Content of Premarket 
Submissions for Device Software Functions.”
Software validation and risk management are key elements of cybersecurity analyses and 
demonstrating whether a device has a reasonable assurance of safety and effectiveness. FDA 
requires manufacturers to implement development processes that account for and address 
software risks throughout the design and development process, as discussed in ISO 13485 
regarding design and development, which may include cybersecurity considerations.19 For 
example, these processes should address the identification of security risks, the design 
requirements for how the risks will be controlled, and the evidence that the controls function as 
designed and are effective in their environment of use for ensuring adequate security. 
1. 
A Secure Product Development Framework (SPDF) may be 
one way to satisfy the QMSR
Cybersecurity threats have the potential to exploit one or more vulnerabilities that could lead to 
patient harm. The greater the number of vulnerabilities that exist and/or are identified over time 
in a system in which a device operates, the easier a threat can compromise the safety and 
effectiveness of the medical device. An SPDF is a set of processes that help identify and reduce 
the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a 
product’s lifecycle, including design, development, release, support, and decommission. 
Additionally, using SPDF processes during device design may prevent the need to re-engineer 
17 The recommendations in this guidance are not intended to suggest that FDA will evaluate an applicant’s 
compliance with the QMSR as part of its premarket submission under section 510(k) of the FD&C Act in our 
determination of a device’s substantial equivalence, as this is not a requirement for such decision under section 
513(i) of the FD&C Act. This guidance is intended to explain how FDA evaluates the performance of device 
cybersecurity and the cybersecurity outputs of activities that are part and parcel of QMSR compliance, and explain 
how the QMSR can be leveraged to demonstrate these performance outputs.
18 References to clauses and subclauses in this guidance are to clauses and subclauses of ISO 13485:2016, unless 
otherwise specified. 
19 See Subclause 7.3 of ISO 13485.
