The following is an example SOP that fulfills global regulatory expectations for cybersecurity vulnerability tracking. It is suitable for inclusion in premarket submissions as required evidence and can also be implemented within a manufacturer’s quality system to withstand audits, demonstrate adherence to regulatory guidance, and ensure continuous compliance. This SOP defines how medical device manufacturer tracks vulnerability metrics for compliance with FDA Premarket regulations. The scope covers all software components, including third-party libraries and internally developed code. Key metrics include total vulnerabilities, percentage patched, average time to patch release, and average time to patch installation across deployed systems. A Vulnerability Metrics Tracker records component details, version, CVE or defect ID, dates identified, patch release dates, and deployment timelines. Each new vulnerability triggers an entry, updated as patches are released and deployed. This process ensures traceability, regulatory compliance, and continuous oversight of software vulnerability management.

Purpose

The purpose of this document is to describe the Standard Operating Procedure (SOP) for tracking vulnerability metrics for [System Name].

Scope

The scope of this Standard Operating Procedure are vulnerabilities identified in software components of [System Name].

References

Internal References

• [Template – Vulnerability Metrics Tracker]
• [SOP – Cybersecurity Risk Management Plan]

External References

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, Guidance for Industry and Food and Drug Administration Staff, [DATE].

Summary

In compliance with FDA Premarket Regulations ([DATE]), [Organization Name] captures the following metrics related to vulnerabilities in software contained within [System Name]:

• Total vulnerabilities – the total number of vulnerabilities identified in software used on the system. This can include 3^rd party components such as open-source libraries or operating systems, or software developed by [Organization Name]. This includes vulnerabilities that have been patched in software since the release of the system / software version, for historical purposes.
• Percentage of patched vulnerabilities – the percent of vulnerabilities in the list which have been patched.
• Average time to patch (TTP) release – the average time for patched vulnerabilities, between the identification of the vulnerability and the release of a verified and validated patch for the system which addresses the vulnerability.
• Average time to patch (TTP) install – the average time between the availability of a patch verified and validated patch to address the vulnerability, and when [80%] of fielded systems have the patch applied.

To track these metrics, a Vulnerability Metrics Tracker is maintained, which lists each software component in the system, and any vulnerabilities identified in the software component. Data for each vulnerability includes:

• System Component – the system component aligned to the Software Bill of Materials and Threat Model, which contains the impacted software component.
• Software Package – the name of the software component containing the vulnerability.
• Software Version – the version number of the affected software component.
• Vulnerability ID – the Common Vulnerability Enumeration (CVE) or other unique identifier for the vulnerability.
• Date Identified – the date on which [Organization Name] became aware of the vulnerability.
• Patch Release Date – the date on which a verified and validated patch has been released for the system, which is ready for installation.
• TTP Release (days) – the number of days between Date Identified and the Patch Release Date.
• Patch Deployed Date – the date on which [80%] of systems have been updated with the patch.
• TTP Install (days) – the number of days between release of the patch, and the Patch Deployed Date.

Procedure

1. When a software vulnerability in a software component of [System Name] is identified, a new record in the Vulnerability Metrics Tracker shall be created. Add a new row to the Vulnerability Tracking sheet of the Vulnerability Metrics Tracker excel document, and record the following information:

1. System Component – identify the component of the system which is impacted by the vulnerability.

1. Software Package – the software package name affected by the vulnerability. Note that the software package should be identical to the software package name identified in the system’s Software Bill of Materials (SBOM).
2. Software (SW) Version – the affected software version. Note that the software version should be identical to the software version reported in the Software Bill of Materials (SBOM).
3. Vulnerability ID
   1. If the vulnerability is a Common Vulnerability Enumeration (CVE), record the CVE ID as the Vulnerability ID.
   2. If the vulnerability was identified via an alternative source, and a [JIRA ID or other software defect management system identifier] has been generated, record that ID as the Vulnerability ID.
4. Date Identified – the date on which the vulnerability was identified. Note that vulnerability identification can occur through a variety of means, including vulnerability scanning of the SBOM or reports from 3^rd parties).
5. Patch Release Date, TTP Release (days), Patch Deployed Date, and TTP Install (days) fields should be set to “N/A”

2. When a verified and validated patch for the system has been released, and is available for installation on systems affected by the vulnerability, record the following information in the Vulnerability Metrics Tracker for the vulnerability:

1. Patch Release Date – the date on which the patch was made available for installation on affected systems.

1. TTP Release (days) – the number of days from the Date Identified to the Patch Release Date.

3. When [TBD %] of systems have been patched, record the following information in the Vulnerability Metrics Tracker for the vulnerability:

1. Patch Deployed Date – date on which the required percentage (above) of systems have been patched.

1. TTP Install (days) – the number of days from the Patch Release Date to the Patch Deployed Date