Your cybersecurity management plan names the numbers you committed to produce for every release of every product. FDA sets a floor of three. Running programs track seven. All of them need a timestamp created at the moment the work happens.

The guidance asks for a cybersecurity management plan in premarket submissions, and for cyber devices Section 524B(b)(1) requires one. That plan names the metrics you will track for every software release of every product, from development through the supported life of the device. FDA reads it as a commitment, and at some point someone will ask you to produce the numbers.

The guidance is explicit that this is measured performance, not a checked box. It recommends that manufacturers "track and record the measures and metrics below, and provide them in premarket submissions and PMA annual reports (21 CFR 814.84), when available."

The three FDA names

Section V.A.6 sets the floor. "At a minimum, FDA recommends tracking the following measures and metrics, or those that provide equivalent information":

  • "Percentage of identified vulnerabilities that are updated or patched (defect density)";
  • "Duration from vulnerability identification to when it is updated or patched"; and
  • "Duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known."

Averages should be provided when multiple vulnerabilities are addressed, and may be given over several time frames to show process changes working. If you have not marketed a prior version, FDA acknowledges the numbers may not exist yet but wants the metrics written into the risk management plan anyway.

The seven a running program tracks

Mature programs track seven across the same vulnerability lifecycle, and the extra four are the ones that make the FDA three defensible. Three are clocks, three are counters, one is a cadence.

The clocks. Time-to-Triage runs from the moment a vulnerability surfaces, whether from SBOM monitoring or a penetration test, to a documented decision: fix, defer or accept. Time-to-Remediation runs from identification to mitigation or patch, which is FDA's second metric. Coordinated vulnerability disclosure response timelines measure how quickly and thoroughly you handle external reports, which the management plan has to describe.

The counters. Vulnerability density is the count of unresolved findings per product, per version or per codebase, the closest thing FDA has to a hygiene score and the complement of its first metric. Patch adoption rate asks what percentage of released patches reached devices in the field, FDA's third metric. Residual risk status is the honest snapshot of what remains after mitigations, with the recorded justification for every no-fix decision.

The cadence. Frequency of periodic testing rounds out the seven. The guidance expects cybersecurity testing after release "at regular intervals commensurate with the risk (e.g., annually)," and the management plan has to list periodic security testing as an element. Every penetration test, fuzzing engagement and static or dynamic analysis run should land in one log: when it ran, what it covered, how long since the last one.

Why the spreadsheet dies

None of the seven is hard to define. Every one is hard to sustain, because each depends on a timestamped record created at the exact moment your team is busy doing the actual work. At the volume of vulnerabilities constantly surfacing against a device with a real SBOM, manual collection collapses within two release cycles. Metrics reconstructed after the fact are fiction with a date column.

Build the record into the workflow instead. The SBOM tracker logs first-detected dates as components are matched to new CVEs. The triage decision is a form with a timestamp, not an email. Patch releases link to the findings they close. Field deployment is reported by the update mechanism, or estimated with the estimate written down.

The number that matters most is not a number

A fast Time-to-Remediation spent on findings that never needed fixing is money spent proving the wrong thing. The artifact that saves you in review is the recorded reason a fix was not performed: the exploitability analysis in the architecture as built, and the compensating controls if any. If your program can produce all seven on demand, each backed by a defensible disposition, then the plan you filed and the process you run are the same document. FDA only ever reads the plan.