Set remediation timelines from two inputs: how dangerous the vulnerability is right now, including evidence of exploitation, and how important the affected asset is. Write the targets into policy, measure how often you meet them, and keep a separate faster path for actively exploited issues.
Why one severity number fails
A single score treats a flaw on a test server the same as the same flaw on a customer-facing payment service. NIST's patch management guide makes this point about metrics: a statement like "10 percent of assets are unpatched" means little unless you know how important those assets are and how severe the vulnerabilities are.
The same logic applies to deadlines. A grid of asset importance against vulnerability importance gives more defensible answers than one column of days.
A simple grid
Define your own categories, then fill in targets you can meet.
| Vulnerability importance | Low asset | Moderate asset | High asset |
|---|---|---|---|
| Low | Next routine cycle | Next routine cycle | Next routine cycle |
| Medium | Routine cycle | Routine cycle, shorter | Short, scheduled |
| High | Short, scheduled | Short | Fast |
| Critical or exploited | Fast | Fast | Emergency path |
The words in the cells become numbers in your own policy. This post deliberately gives no day counts, because the right numbers depend on your operations, contracts and the rules that apply to you.
Use public exploitation evidence
CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation. For US federal civilian agencies, Binding Operational Directive 22-01 sets catalog due dates, and NIST notes that other organizations may choose to use the catalog voluntarily to prioritize patching. Treating catalog membership as a trigger for your fast path is a reasonable, explainable rule. Our post on KEV, EPSS and CVSS compares those signals.
Decide when the clock starts
Pick one and state it: time since public disclosure, time since detection in your environment, or time since a fix became available. Different starts give very different numbers, and mixing them makes trend lines meaningless.
Measure, then adjust
Track the percentage fixed within target, plus median and average time, per cell of your grid. If a cell misses constantly, either the target is unrealistic or the process is broken. Change one, document why, and note the date. Adjusting honestly is more defensible than missing quietly.
NIST also advises offering flexibility on routine patches while forcing installation once a grace period ends, so deadlines have teeth.
Link deadlines to automation
Gates in the pipeline can block a release when a finding exceeds its deadline, which makes the policy self-enforcing. Safeguard policies, gates and guardrails can encode these rules, and reachability analysis helps decide which findings need the fast path because the vulnerable code is actually exercised.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a fresh disclosure appears alongside the assets it touches, the two inputs to the grid above.
Quick check
Should our deadlines match a federal directive?
Only if you choose to. The directive binds federal civilian agencies. Private organizations may use it as a reference, and should set targets from their own risk assessment and obligations.
What if we keep missing a target?
Look at cause. Fix the process, or lengthen the target with a recorded rationale, rather than leaving a number that is routinely missed.
Sources
- NIST SP 800-40 Rev. 4, sections 3.5 and 3.6
- CISA BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
