FDA's 2023 premarket guidance asks for something most quality systems never tracked: numbers that show the vulnerability process actually runs. The guidance points at measures like the percentage of identified vulnerabilities patched and the time from identification to patch availability. A narrative about taking security seriously does not answer that. A tracker does.
This is the smallest SOP in the set and probably the highest signal per word. Four metrics: total vulnerabilities identified, percentage patched, average time from identification to a verified patch release, and average time from patch availability to installation across [80%] of fielded systems. One tracker holds them, one row per vulnerability, keyed to the same component and version names as the SBOM so nothing needs translating at audit time.
The two averages are the tell. A long time to patch release is an engineering capacity problem. A long time to install is a deployment design problem, and FDA reads it exactly that way. We built ELTON to keep these fields current automatically, but tooling or spreadsheet, the discipline is identical: every vulnerability opens a row, and every row eventually has to close.
Describe the standard operating procedure for tracking vulnerability metrics for [System Name].
Vulnerabilities identified in software components of [System Name], including third party libraries, operating systems, and software developed by [Organization].
[Organization] captures four metrics for vulnerabilities in software contained in [System Name]:
A Vulnerability Metrics Tracker records the data, one row per vulnerability. Each row carries: the system component, aligned to the SBOM and threat model; the software package and version, identical to the names reported in the SBOM; the vulnerability ID (the CVE where one exists, otherwise the [defect management system] identifier); the date identified; the patch release date and TTP release in days; and the patch deployed date and TTP install in days.
Create a new row in the tracker. Record the impacted system component, the software package and version exactly as the SBOM reports them, the vulnerability ID, and the date identified. Identification can arrive through SBOM vulnerability scanning, third party reports, or any other monitoring source. Set the patch release, TTP release, patch deployed, and TTP install fields to N/A.
When a verified and validated patch is available for installation on affected systems, record the patch release date and compute TTP release: the days from date identified to patch release.
When [80%] of fielded systems have been patched, record the patch deployed date and compute TTP install: the days from patch release to that date.
Keep the closed rows. History is what turns a metric into a trend, and the trend is what you will be asked to explain: not why one CVE took 40 days, but why the average is moving. A tracker that only ever holds open items answers nothing.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
FDA's 2023 premarket guidance points at measures like the percentage of identified vulnerabilities patched and the time from identification to patch availability. This example SOP tracks four: total vulnerabilities identified, percentage patched, average time to patch release, and average time to patch install across fielded systems.
Time to patch release is the mean number of days between identifying a vulnerability and releasing a verified and validated patch that addresses it. Time to patch install is the mean days between patch availability and the point where a defined share of fielded systems, 80 percent in this example, have applied it.
The two averages are the tell. A long time to patch release is an engineering capacity problem. A long time to install is a deployment design problem, and FDA reads it exactly that way. A narrative about taking security seriously does not answer the question. A tracker does.
One row per vulnerability. Each row carries the system component aligned to the SBOM and threat model, the software package and version named identically to the SBOM, the vulnerability ID (the CVE where one exists), the date identified, the patch release date with time to patch release in days, and the patch deployed date with time to patch install.
Yes. Keep the closed rows, including vulnerabilities already patched since release. History is what turns a metric into a trend, and the trend is what you will be asked to explain: not why one CVE took 40 days, but why the average is moving. A tracker that only holds open items answers nothing.