Summary

This all-in-one cybersecurity SOP outlines how medical device manufacturers can meet global regulatory expectations and protect against FDA and international audit findings. Designed for use in both premarket submissions and within a manufacturer’s quality system, it governs cybersecurity activities across the full product lifecycle—from design and development through verification, validation, and postmarket monitoring. Key elements include risk management planning, threat modeling, SBOM creation, secure code analysis, vulnerability scanning, penetration testing, and traceability of mitigations. By implementing this SOP, manufacturers can demonstrate regulatory compliance, maintain defensible cybersecurity processes, and ensure continuous oversight of vulnerabilities while safeguarding patient safety.

The following is an example of a comprehensive cybersecurity SOP that aligns with global regulatory expectations. It can be included in premarket submissions as required evidence and implemented within a manufacturer’s quality system to withstand audits, demonstrate adherence to regulatory guidance, and ensure ongoing compliance. This example also highlights the challenges ELTON addresses by automating many of these cybersecurity requirements and processes, reducing the burden on manufacturers while maintaining regulatory readiness. The following SOP outlines how medical device manufacturers can meet global regulatory expectations and protect against FDA and international audit findings. Designed for use in both premarket submissions and within a manufacturer’s quality system, it governs cybersecurity activities across the full product lifecycle—from design and development through verification, validation, and postmarket monitoring. Key elements include risk management planning, threat modeling, SBOM creation, secure code analysis, vulnerability scanning, penetration testing, and traceability of mitigations. By implementing this SOP, manufacturers can demonstrate regulatory compliance, maintain defensible cybersecurity processes, and ensure continuous oversight of vulnerabilities while safeguarding patient safety.

Purpose

The purpose of this document is to describe the medical device cybersecurity program process and documentation for [Organization].

Scope

The scope of this procedure are cybersecurity activities and documentation related to design, development, verification validation, and continual post-market monitoring of medical devices developed by [Organization].

References

Internal References

External References

• Code of Federal Regulations, Part 820 – Quality System Regulation.
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, Guidance for Industry and, Food and Drug Administration Staff, September 27, 2023.
• Postmarket Management of Cybersecurity in Medical Devices – Guidance for Industry and Food and Drug Administration Staff (2016)
• AAMI TIR97: 2019 Principles for medical device security — Postmarket risk management for device manufacturers Advancing Safety in Health Technology
• NTIA: Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)

Process

Overview

The Medical Device Cybersecurity process described in this SOP guides all cybersecurity activities performed throughout the total product lifecycle of a system designed by [Organization].

Cybersecurity activities described in this SOP are intended to align with the Quality System Regulations phases described in 21 CFR part 820.30 Design Controls.

The following diagram illustrates the cybersecurity activities performed during each phase of the product lifecycle.

 Planning

Cybersecurity Risk Management Plan

Each product release shall include a Cybersecurity Risk Management Plan that defines the activities performed throughout a system’s total product lifecycle, the roles and responsibilities related to cybersecurity activities, and all cybersecurity deliverables for the product.

The Cybersecurity Risk Management Plan must include, at minimum, the following:

• A detailed list of the cybersecurity-related outputs related to the product, as produced by the cybersecurity risk management plan.
• Roles and responsibilities related to cybersecurity activities and outputs.
• Definition of the cybersecurity risk acceptance criteria for the system.
• Threat modeling of the system and a risk assessment of threats’ potential impact on patient safety.
• Creation of a Software Bill of Materials.
• Software vulnerabilities risk assessment.
• Cybersecurity testing, including a plan for periodic re-testing of the system on (at minimum) a yearly basis.
• Risk assessment of results from cybersecurity testing.
• Secure code analysis.
• Risk assessment of results from secure code analysis.
• Risk assessment of unresolved anomalies.
• Creation of a risk management report for the product’s release.
• A post-release plan for monitoring, addressing, and communicating vulnerabilities in the system.
• A post-release plan for monitoring vulnerability metrics.

Inputs to the Cybersecurity Risk Management Plan include, but are not limited to:

• Systems, software, hardware, or equivalent development plans.
• The ISO 14971-based risk management plan

Templates and SOPs used as part of this process include:

• [SOP – Cybersecurity Risk Management (this document)]
• [Template – Threat Model and Architectural Views]

Design Input Phase

Threat Modeling

Threat Modeling shall be performed to identify potential threats to the product and assist with the development of requirements (design controls) to reduce cybersecurity-related risks in the system.

A Threat Model shall be developed and maintained for each product release. The Threat Model decomposes the product’s architecture and documents the interactions between elements of the system  into architectural diagrams (or views), including:

• Global System-Level View(s)
• Multi-Patient Harm View(s)
• Updatability/Patchability View(s)
• Security Use-Cases(s)

The diagrams, architectural decomposition, relationships between system elements, and use cases are documented in the System’s Threat Model and Architectural Views document.

Threat Analysis using the STRIDE per-Element methodology is documented in the Threat Model Risk Assessments tab of the product’s Cybersecurity Risk Assessment.

For existing products, the previous Threat Model documentation created for that product may be used as the basis for the new release’s Threat Model.

Inputs to the Threat Modeling process include, but are not limited to:

• User Needs
• System, software, hardware, labeling, or equivalent requirements documents
• Architectural documents for the system, software, or infrastructure (e.g., cloud, on-prem)

Templates and SOPs used as part of this process include:

• [SOP – Threat Modeling]
• [SOP – Cybersecurity Risk Assessment]
• [Template – Threat Model and Architectural Views]
• [Template – Cybersecurity Risk Assessment]

Cybersecurity Risk Acceptance Criteria

Cybersecurity Risk Acceptance Criteria define the conditions by which [Organization] is willing to accept risks related to cybersecurity in the system or product.

The cybersecurity risk acceptance criteria for the release of the system shall be documented as part of the Cybersecurity Risk Management Plan. Risk acceptance criteria shall include the following:

Overall Risk Acceptance Criteria – the acceptance criteria for the product release representing all cybersecurity risks. This represents the final decision on whether the cybersecurity risks identified in the system are acceptable for release.

An example of overall risk acceptance may be that no unacceptable individual cybersecurity risks remain in the system.

Individual Risk Acceptance Criteria—Individual risk acceptance criteria depend on the nature of the risk, e.g., whether the risk may or may not impact patient safety.

For risks that could impact patient safety, the risk acceptance criteria shall be based on the cross-section of exploitability, as defined by the CVSS v3.0 standard, vs. the worst-case severity of harm that could arise from that risk. The table below provides an example.

			Severity of Harm
			Catastrophic	Critical	Major	Minor	Negligible
			5	4	3	2	1
Exploitability	Critical	5	Unacceptable	Unacceptable	Unacceptable	RBA	Acceptable
	High	4	Unacceptable	Unacceptable	RBA	Acceptable	Acceptable
	Medium	3	Unacceptable	RBA	Acceptable	Acceptable	Acceptable
	Low	2	RBA	Acceptable	Acceptable	Acceptable	Acceptable
	Negligible	1	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable

Table 1 Risk Acceptance Level

For risks that do not impact patient safety, such as those that only result in the exposure of sensitive information, risk acceptance shall be based on the CVSS rating (e.g., Critical, High, Medium, Low, None). The table below provides an example.

CVSS v3.0 Rating	CVSS v3.0 Score Range	Risk Acceptance Level
None / Low	0.0 to 3.9	Acceptable
Medium	4.0 to 6.9	Benefit-Risk Assessment Required
High / Critical	7.0 to 10	Unacceptable

Table 2 Non-Patient Safety Risk Acceptance Table

Inputs to the cybersecurity risk acceptance criteria include:

• ISO 14971-based safety risk assessment
• ISO 14081-based risk management plan

Templates and SOPs used as part of this process include:

• [SOP – Medical Device Cybersecurity]
• [Template – Cybersecurity Risk Management Plan]

Threat Model Risk Assessment

A risk assessment of threats identified during Threat Modeling shall be performed and documented as part of the release’s Cybersecurity Risk Assessment document. This risk assessment shall consider the impact to patient safety, using the product’s ISO-14971-based safety risk assessment as a source for potential sources of harm (hazardous situations and harms) to the patient, as defined in the Cybersecurity Risk Acceptance Criteria.

The Threat Model Risk Assessment shall include two phases: an initial risk assessment to prioritize threats based on potential patient-safety impact and a residual risk assessment once mitigating controls have been implemented to reduce the potential exploitability of the threat. The initial risk assessment should be completed prior to or during the development of Cybersecurity Requirements for the system, and the residual risk assessment should be completed once requirements intended as mitigations to threats have been identified.

A summary of the Threat Model Cybersecurity Risk Assessment shall be included in  the Cybersecurity Risk Management Report for the product’s release.

Inputs to the Threat Model Risk Assessment include, but are not limited to:

• System Threat Model and Architectural Views
• Cybersecurity risk acceptance criteria
• ISO 14971-based patient safety risk assessment

Templates and SOPs used as part of this process include:

• [SOP – Cybersecurity Risk Assessment]
• [Template – Cybersecurity Risk Assessment]

Requirements

For each product release, cybersecurity-specific requirements shall be developed. Cybersecurity requirements may be documented in their cybersecurity-specific requirements document or included in existing product requirements documents such as software, hardware, labeling, or systems requirements.

Cybersecurity requirements should be mapped to the Control Categories recommended in the FDA’s Cybersecurity in Medical Devices; Quality System Considerations and Content of Premarket Submissions (2023), Appendix 1. Security Control Categories and Associated Recommendations. This mapping may be documented and maintained in the Cybersecurity Risk Assessment document, Mitigations section.

Guidance for the creation of cybersecurity requirements is outside the scope of this SOP.

Inputs to Cybersecurity Requirements include, but are not limited to:

• Systems, software, hardware, or similar requirements.
• System Threat Model and Architectural Views
• Systems, software, or infrastructure (e.g., cloud or on-prem) architecture.

Design Output Phase

Software Bill of Materials

A Software Bill of Materials (SBOM) shall be created for the product’s release. The SBOM may be a single monolithic document for all software components of the system or multiple SBOMs that represent the cumulative total of software in the system.

The SBOM(s) shall be provided in a machine-readable format and conform to one of the following SBOM standards:

• CycloneDX
• System Package Data Exchange (SPDX)

SBOM(s) shall be aligned to the architectural decomposition described in the system’s threat model and architectural views document.

The Software Bill of Materials shall include, at minimum, the following baseline attributes that can be used to identify software components and their inter-relationships. The following attributes, as outlined by the NTIA’s Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) shall be provided:

• Author Name
• Timestamp
• Supplier Name
• Component Name
• Version String
• Component Hash
• Unique Identifier
• Relationship

Inputs to the Software Bill of Materials include:

• All software developed for or installed on the system or device, including operating system version(s), COTS software version(s) (e.g., MSSQL).
• For cloud-hosted architectures, any infrastructure as code deployment scripts or configuration.
• For containerized applications, the complete build manifest and container build scripts.

Templates and SOPs used as part of this process include:

• WI – Software Bill of Materials
• Template – Software Bill of Materials Report

Level of Support and End of Life

Supplemental Level of Support (LoS) and End of Support (EoS) information for each SBOM component shall be provided in human-readable format. The LoS and EoS information can be provided in a single monolithic document, or separate documents aligned with independent SBOMs.

If the SBOM format allows, LoS and EoS information may also be included in the machine-readable SBOM(s) for the system. For example, the CycloneDX specification allows for “properties” fields containing key/value pairs that could contain this information.

• Level of Support provided by the manufacturer or provider of the component. In the case of commercial software that is purchased or otherwise procured on a contractual basis, details of the level of support are provided. For open-source components or non-commercial libraries, that information is provided as available from the software producer.
• End-of-Life support for the software component. For devices that remain in service following the end of support, a disclosure shall be provided to the end-user for transferring the risks highlighting that the cybersecurity risks for end-user can be expected to increase over time.

Templates and SOPs used as part of this process include:

• [WI – Software Bill of Materials]
• [Template – Software Bill of Materials End of Support and Level of Support]

Secure Code Analysis

Secure Code Analysis is a manual or automated process where source code for an application is inspected for potential security weaknesses. Secure code analysis is intended to identify issues such as:

• Hard-coded encryption keys, passwords, API keys, or other secrets built directly into the source code.
• Use of unsafe or deprecated cryptographic algorithms such as MD5 or SHA1.
• Poor sanitization of input, for example, those that could allow for SQL injection attacks.

Secure code analysis should be performed on a regular basis (e.g., nightly, weekly, per-build), and secure code analysis findings should be remediated as soon as possible to reduce overall technical debt accrued throughout the development of the system.

A Secure Code Analysis report shall be generated from the final, or equivalent, version of the system’s source code prior to the product’s release. The Secure Code Analysis Report must contain any remaining secure code analysis findings that have not been remediated, or identified as false-positives.

Inputs to secure code analysis include, but are not limited to:

• Source code for applications, libraries, services, firmware, or other software developed by [Organization].

Templates and SOPs used as part of this process include:

• [WI – Secure Code Analysis]

Secure Code Analysis Risk Assessment

A cybersecurity risk assessment of each finding in the Secure Code Analysis Report shall be performed. The risk assessment  shall be documented in the Cybersecurity Risk Assessment for the product’s release, following the risks assessment process defined in SOP – Cybersecurity Risk Assessment.

A summary of the Secure Code Analysis Cybersecurity Risk Assessment shall be included in the Cybersecurity Risk Management Report for the product release.

Inputs to the Secure Code Analysis Risk Assessment include:

• Secure Code Analysis Report

Templates and SOPs used as part of this process include:

• [SOP – Cybersecurity Risk Assessment]
• [Template – Cybersecurity Risk Assessment]

Vulnerability Scanning

Scanning for vulnerabilities in 3^rd party software components of the system’s SBOM should be performed regularly throughout the development of software for the system to allow the development team(s) to identify and patch software components as soon as patches are available.

Vulnerability scanning must also be performed regularly once the software has been released, which is discussed in detail in the Vulnerability Scanning section of the Postmarket phase of this SOP.

A Software Vulnerability Report shall be generated from the final, or equivalent, version of the system’s Software Bill of Materials. The Software Vulnerability Report must contain any vulnerabilities remaining in software components of the system that have not been patched or identified as false positives. Vulnerabilities that remain in the system but are risk-assessed as acceptable must be included in the report, with the risk assessment documented in the Vulnerability Risk Assessment discussed in the next section.

Inputs to the Software Vulnerability Report include:

• Software Bill of Materials

Templates and SOPs used as part of this process include:

• [SOP – Cybersecurity Risk Assessment]
• [Template – Cybersecurity Risk Assessment]

Vulnerabilities Risk Assessment

A cybersecurity risk assessment of each vulnerability in the Software Vulnerability Report shall be performed. The risk assessment  shall be documented in the Cybersecurity Risk Assessment for the product’s release, following the risks assessment process defined in SOP – Cybersecurity Risk Assessment.

A summary of the Software Vulnerabilities Cybersecurity Risk Assessment shall be included in the Cybersecurity Risk Management Report for the product’s release.

Inputs to the Secure Code Analysis Risk Assessment include:

• Software Vulnerability Report

Templates and SOPs used as part of this process include:

• [SOP – Cybersecurity Risk Assessment]
• [Template – Cybersecurity Risk Assessment]

Design Verification and Validation Phase

Cybersecurity Testing

Testing of the system to ensure that mitigations (design controls) implemented as part of the system design have been properly implemented shall be performed. Testing shall also include “negative” tests, such as penetration testing, to test the effectiveness of these design controls. The following types of tests must be included as part of cybersecurity testing for the system.

Verification and validation of cybersecurity requirements. This is a positive testing activity, identical to the methods used to verify systems, software, hardware, etc., requirements, and shall be performed as part of the overall V&V activities of the system.

Penetration testing of the system, using the final version of the system, or a equivalent version. Penetration testing must be performed from a systems perspective, with considerations of other systems that may be integrated with the system under test, so that interfaces of the system can be properly evaluated. A penetration testing report, or equivalent document, shall be generated, including the results of the testing, the methodology followed in executing the testing, and details of the testing observations.

Vulnerability Testing, which uses static and dynamic analysis methods to identify potential vulnerabilities in a system and attempts to exploit any vulnerabilities identified during that analysis.

Resiliency and robustness (e.g., fuzz) testing. Results of these tests may be performed as part of the penetration testing of the system and as part of the penetration testing report.

Inputs to cybersecurity testing include:

• Completed software, hardware, etc., in a release or release-equivalent state, deployed as a test system, device, or environment.
• Systems, software, and hardware requirements.

Templates and SOPs used as part of this process include:

• N/A

 

Cybersecurity Testing Risk Assessment

A risk assessment of each cybersecurity testing result, such as each observation from the penetration testing report, shall be performed. The results of the cybersecurity risk assessment shall be documented in the [Product Cybersecurity Risk Assessment] in the Cybersecurity Risk Assessment tab.

A summary of the cybersecurity testing risk assessment shall be included in the [Product Cybersecurity Risk Management Report].

Inputs to the cybersecurity testing risk assessment include:

• Cybersecurity testing report(s) (e.g. pentest reports).

Templates and SOPs used as part of this process include:

• [TMP – Cybersecurity Risk Assessment]

Unresolved Anomalies Risk Assessment

A report shall be generated prior to the release of the system identifying all unresolved anomalies in the release of the product. A cybersecurity risk assessment of each vulnerability in the unresolved anomalies report shall be performed and documented in the [Product Cybersecurity Risk Assessment] in the Unresolved Anomalies Risk Assessment tab.

A summary of the unresolved anomalies cybersecurity risk assessment shall be included in the [Product Cybersecurity Risk Management Report].

Inputs to the unresolved anomalies cybersecurity risk assessment include:

• Unresolved Anomalies Report

Templates and SOPs used as part of this process include:

• [TMP – Cybersecurity Risk Assessment]

Traceability

Traceability of threats to the system, such as threats from threat modeling or vulnerabilities from software vulnerability scanning, to verification and validation test cases to ensure that mitigations for those sources of threat have been implemented correctly and are effective is critical to the system’s overall cybersecurity.

Traceability of sources of threat to mitigations (design controls) shall be documented as part of the [Product Cybersecurity Risk Assessment]. Each source of threat may include one or more Control Group (a collection of one or more design controls) that acts as a mitigation for the source of threat.

Control Groups shall be documented in the [Product Cybersecurity Risk Assessment], mapped to one or more requirements in the Mitigations tab of the risk assessment.

Traceability of design controls, such as requirements, to verification and validation test cases shall be documented as part of the [requirements to verification traceability matrix].

Cybersecurity Risk Management Report

The [Product Cybersecurity Risk Management Report] shall record all cybersecurity-related activities performed during the design, development, verification, and validation of the product’s release. The risk management report includes the following:

• Description of the risk evaluation methods and process used during cybersecurity-related activities.
• Details of the risk acceptance criteria for the product’s release.
• Summaries of all risk assessment activities.
• Details of risk mitigation activities taken.
• References to design outputs, including the Cybersecurity Risk Management Plan, Threat Model, Cybersecurity Risk Assessments, Software Bill(s) of Materials, Vulnerability Report(s), Cybersecurity Testing results, and Measures and Metrics tracking.

Inputs to the cybersecurity risk management report include:

• Cybersecurity Risk Management Plan
• Threat Model and Architectural Views
• Cybersecurity Risk Assessment(s)
• Software Bill(s) of Materials and Supplemental LoS/EoL information.
• Vulnerability Report(s)
• Secure Code Analysis Report(s)
• Cybersecurity Testing Report(s)
• Measures and Metrics Report(s)

Templates and SOPs used as part of this process include:

• [TMP – Cybersecurity Risk Management Report]

Postmarket

Vulnerability Management

[Organization] shall maintain a vulnerability management plan, described below, for the product’s release. The vulnerability management process includes performing risk assessments of potential vulnerabilities in the system, developing a response plan for vulnerabilities when they are identified, and communicating with customers, regulatory agencies, and vulnerability monitoring groups regarding those vulnerabilities.

[Organization] shall follow a shared-responsibility model related to cybersecurity risks and vulnerabilities as they relate to the system as it is deployed in a customer’s environment. For example, where applicable, customers shall be responsible for monitoring systems on which [Organization] software is deployed (e.g., Windows-based PCs) for incidents such as malware or virus detection on those systems, intrusions to the customer’s network that may impact the systems on which [Organization]’ software is deployed and notifying [Organization] in the case of a suspected incident.

The vulnerability management process shall include, at minimum, the following activities:

1. Threat Monitoring and Intelligence
2. Vulnerability Risk Assessment
3. Response Planning
4. Communications Planning
5. Patch Development and Testing
6. Patch Deployment

Threat Monitoring and Intelligence

[Organization], in conjunction with its development partners, shall continuously monitor sources of threat intelligence via resources including, but not limited to:

• The National Vulnerability Database (NVD), which is managed by the National Institute of Standards and Technology (NIST)
• Vulnerability disclosures and patch notifications for software components contained each component’s Software Bill of Materials (SBOM) that are reported by the component manufacturer, 3rd party researchers, and other entities.
• Customer communications / complaints.
• Threat intelligence and disclosures as part of its membership in Health-ISAC
• 3rd party vulnerability disclosures via sources such as CISA.

[Organization] continuously monitors disclosures directly reported from third-party researchers, CISA, customer complaints, etc.

[Organization] performs a [monthly /  quarterly / yearly] review of software and systems design documentation to assess any necessary updates or patches to the system, including cybersecurity-related updates. These reviews act as another input to the vulnerability management process.

[Organization] shall perform, at minimum, annual cybersecurity testing (e.g., penetration testing) of all product configurations currently deployed to the field. Results from annual re-testing act as an input to the vulnerability management process.

Upon detection of a vulnerability in a system component, within [1 business day / timeframe] the [Cybersecurity Team] will notify internal product management team members of the vulnerability and initiate the vulnerability assessment process.

Vulnerability Risk Assessment

During the vulnerability assessment, a clinical and cybersecurity risk assessment of the vulnerability is performed using the information provided in the vulnerability report, such as a CVE, third-party researcher report, or customer complaint.

The vulnerability assessment leverages the Threat Model and Architectural View and Cybersecurity Risk Assessment(s) created during the systems’ design and any updates made to those documents once the product was released. [SOP – Cybersecurity Risk Assessments] provides guidance on how to perform the risk assessment.

If the results of the vulnerability risk assessment determine that the vulnerability is controlled (acceptable), patching the vulnerability may be done as part of the normal release schedule for the product. In some cases, such as the vulnerability has a high level of visibility or a high criticality regardless of its impact on patient safety, it may be necessary to communicate with customers and regulatory agencies regarding the impact of the vulnerability on the system.

If the results of the vulnerability risk assessment determine that the vulnerability is uncontrolled (unacceptable or a risk-benefit assessment cannot justify the risk being acceptable), an expedited response plan, communications, and patch process shall be followed.

The vulnerability risk assessment shall be documented as a separate Cybersecurity Risk Assessment for the product, using [TMP – Cybersecurity Risk Assessment]. Unnecessary tabs, such as the threat model or unresolved anomalies tabs can be removed if unused.

Response Planning & Communications

Response planning for the vulnerability requires the development of a communication to customers notifying them of the presence and impact of the vulnerability on [Organization’s] system.

As part of the response plan, communication with the customer shall be established, and any potentially mitigating controls to limit the impact of the vulnerability (described below) must be communicated to the customer, along with a timeframe for a patch release to remediate the vulnerability.

For controlled vulnerabilities that do not require immediate response, a communication shall be sent within 60 days of the vulnerability’s identification.

For uncontrolled vulnerabilities, communication with customers to notify them of the vulnerability must be established within 5 business days from the vulnerabilities identification, and a schedule for patch release within 30 days.

Identify Mitigations

For each vulnerability identified that could affect the product, potential mitigations shall be identified. This applies to vulnerabilities that are both controlled and uncontrolled. Mitigations can take the form of temporary actions (e.g., disconnecting the device from the network), or design controls intended to prevent the exploitation of vulnerabilities by design (e.g., a firewall on the device preventing in-bound network connections to a vulnerable HTTP server).

Design controls that represent permanent mitigations shall be documented as part of the vulnerability risk assessment (described earlier). Temporary mitigating controls should NOT be documented in the risk assessment.

Patch Development and Testing

For vulnerabilities that cannot be sufficiently controlled through mitigations employed by the device owner, customer, or user, [Organization] shall create a [Software/Systems/Hardware Development Plan] to develop a software patch for the vulnerability.

The Development Plan must also include a review and updates of related Cybersecurity documentation including the Threat Model and Architectural Views, Cybersecurity Risk Assessment(s), Software Bill(s) of Materials, and Cybersecurity Risk Management Report.

Depending on the severity of the vulnerability or the scope of the changes required to patch the vulnerability, penetration testing may also be required prior to release of the patch. Determination of this need will be the responsibility of the [Cybersecurity Team].

Patch Deployment

For systems or devices that are intended for update by end users, clear instructions on how to download, install, and verify the patch installation will be provided. This will include:

1. Instructions to clearly identify the software version downloaded or otherwise obtained by the end user.
2. Instructions to verify that the downloaded software is authentic.
3. Instructions to apply the software patch.
4. Instructions to verify the software version of the device or system once the patch has been installed, and ensure the correct version is now running on the device or system.

For systems updated by [Organization] personnel, a clear set of instructions for each software patch will be developed for internal personnel use. This will include:

1. Instructions to retrieve the software update from version-control system(s)
2. Instructions to verify the software is authentic, prior to deployment.
3. Instructions on how to install the software patch(es) on the target system(s).

instructions to verify the software update has completed successfully and verify the new software version that is running is the correct version.

Periodic Re-Testing

Penetration testing of the release of the product shall be performed on, at minimum, an annual basis. This applies to each release of the product that is currently fielded. Once a product release no longer exists in the field, re-testing of that version is no longer required.

Re-testing shall be documented as a penetration test or similar test report, identical to the report outlined in the Cybersecurity Testing section of this document.