Setting Vulnerability Remediation Deadlines Your Team Can Actually Hit

A vulnerability's severity score describes how bad it could be in the worst case, not how likely it is to actually be exploited against your specific system. A critical-severity flaw in a library your code never calls is lower real risk than a medium-severity flaw sitting on a server exposed directly to the internet.

Exposure matters as much as the label: is the affected system internet-facing, does it touch sensitive data, is there already a known exploit circulating for that specific vulnerability. Two findings with the same severity score can carry very different real urgency once exposure is factored in, and a tiering system that only reads the severity field misses that distinction entirely.

Weight each finding by its real exposure using these factors:

• Whether the affected system is internet-facing, since a reachable flaw is far more urgent than one on an isolated internal host.
• Whether the system touches sensitive data, which raises the cost of a successful exploit.
• Whether a known exploit is circulating for the vulnerability, which moves it ahead of higher-scored findings with no known attacks.
• The severity score itself, treated as a worst-case description rather than a measure of likelihood.

Federal guidance offers a useful starting template: critical vulnerabilities on internet-accessible systems get remediated within 15 days, high-severity ones within 30 days, and a known exploited vulnerability with a CVE assigned in the last few years gets 14 days regardless of its formal severity score, since active exploitation in the wild outweighs a static rating¹.

Adapt those tiers to your own exposure rather than adopting them unchanged. A company with no internet-facing infrastructure at all carries a different risk profile than one running customer-facing services, and your deadlines should reflect that difference rather than a generic baseline built for a different threat model.

A continuous scanning platform like Tenable finds vulnerabilities in your infrastructure and dependencies on an ongoing basis, catching what changed since the last audit instead of waiting for the next scheduled one. An endpoint protection platform like CrowdStrike watches the devices and workloads themselves for signs of active compromise, which matters because a vulnerability that's already been exploited needs a faster response than one that's simply present and unexploited.

Neither replaces the other. Scanning tells you what could go wrong and how urgently, based on exposure and known exploitation. Endpoint monitoring tells you when something already has gone wrong on a specific machine, which changes the response from a remediation deadline to an active incident.

A tiering policy that lives in a spreadsheet nobody opens outside of a monthly review meeting doesn't actually change when things get fixed. The deadline needs to show up wherever engineers already work: a ticket with a due date in the same system as their other tickets, not a separate compliance tracker that only the security lead checks.

If a finding above your lowest tier doesn't automatically become a ticket with an owner and a due date the same day it's discovered, the tiering policy exists on paper but not in practice. The gap between a documented policy and an actually enforced one is almost always this step: whether the deadline reaches the person doing the work, or waits for someone to notice it during a review.

It's tempting to report on how much of your infrastructure gets scanned, since that number is easy to measure and easy to present as progress. Coverage tells you almost nothing about whether findings actually get fixed on time, and a team can have complete scan coverage and a growing backlog of unaddressed critical findings at the same time.

Track time from a finding's discovery to its remediation, broken down by tier, instead of coverage alone. A rising median time to close critical findings is the signal that actually predicts risk, and it usually surfaces a real problem (an overloaded team, an unclear owner, a tier that's too aggressive to be realistic) well before an incident does.