FDA Submission AI Questions The FDA’s 2023 and 2025 cybersecurity guidance highlight recurring deficiencies, including missing threat models, inadequate testing evidence, unsupported software, and lack of traceability. ELTON addresses these challenges through digital...
Example SOP: Postmarket Vulnerability Management
Summary
Effective postmarket vulnerability management is essential for medical device compliance and patient safety. A robust plan requires continuous threat monitoring, vulnerability assessments, response planning, and clear communication with regulators and customers. Manufacturers must monitor sources such as the NVD, SBOM disclosures, and ISAC alerts, while performing at least annual penetration testing on fielded products. Vulnerabilities are assessed for clinical and cybersecurity impact, with controlled issues handled during normal updates and uncontrolled issues requiring expedited patches and communication. Mitigations, patch development, testing, and deployment are documented, ensuring regulatory alignment, audit readiness, and ongoing protection across the product lifecycle.
The following is an example of a postmarket vulnerability management 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. Effective postmarket vulnerability management is essential for medical device compliance and patient safety. A robust plan requires continuous threat monitoring, vulnerability assessments, response planning, and clear communication with regulators and customers. Manufacturers must monitor sources such as the NVD, SBOM disclosures, and ISAC alerts, while performing at least annual penetration testing on fielded products. Vulnerabilities are assessed for clinical and cybersecurity impact, with controlled issues handled during normal updates and uncontrolled issues requiring expedited patches and communication. Mitigations, patch development, testing, and deployment are documented, ensuring regulatory alignment, audit readiness, and ongoing protection across the product lifecycle.
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:
- Threat Monitoring and Intelligence
- Vulnerability Risk Assessment
- Response Planning
- Communications Planning
- Patch Development and Testing
- 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:
- Instructions to clearly identify the software version downloaded or otherwise obtained by the end user.
- Instructions to verify that the downloaded software is authentic.
- Instructions to apply the software patch.
- 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:
- Instructions to retrieve the software update from version-control system(s)
- Instructions to verify the software is authentic, prior to deployment.
- 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.
