Vulnerability remediation time by severity has no universal duration: your deadlines depend on your remediation policy, applicable requirements, and the risk of each finding. A severity label alone does not establish how many days a fix should take, and installing a patch does not prove remediation is complete. For 2026, separate your target deadline from measured time to verified closure, then escalate findings whose exposure or exploitation evidence demands faster action.
- Vulnerability remediation time by severity needs risk-based SLAs, not unsupported universal deadlines.
- FIRST CVSS severity bands describe technical severity; they do not prescribe remediation times.
- Measure discovery through verified closure, and report mitigation separately from permanent remediation.
- Brinqa is a vulnerability and exposure management platform; evaluate it against your remediation policy requirements.
How long does vulnerability remediation take by severity?
Critical, high, medium, and low findings need explicit deadlines, but there is no single severity-to-days schedule that applies to every organization. Use your contractual, regulatory, and internal requirements to establish targets. Then document the conditions that override the default schedule.
Start with a written policy for vulnerability remediation SLAs by severity. Keep target times separate from observed results: an SLA describes what you require; elapsed remediation time describes what actually happened.
FIRST's CVSS v3.1 specification defines these qualitative severity bands. The score ranges below are technical severity classifications, not remediation deadlines.
| Severity | CVSS v3.1 score | Recommended handling | Limitation of severity alone |
|---|---|---|---|
| Critical | 9.0–10.0 points | Best for emergency assessment and an explicit decision on accelerated remediation | Does not establish whether the affected asset is exposed or the vulnerability is being exploited |
| High | 7.0–8.9 points | Best for prioritized assignment and a tracked remediation deadline | Does not establish business impact on your specific asset |
| Medium | 4.0–6.9 points | Best for planned remediation with escalation when risk changes | Does not rule out an important attack path |
| Low | 0.1–3.9 points | Best for scheduled maintenance and tracked backlog review | Does not justify indefinite deferral |
A CVSS base score is useful because it gives you a consistent technical starting point. Its limitation is equally important: it cannot replace asset context, applicable obligations, or evidence about current threats.
Why this matters
Your remediation report should answer whether important exposures are being removed within policy, not merely whether tickets are closing. Without a common clock and closure rule, teams can report different durations for the same work.
For your 2026 reporting, distinguish three outcomes: verified remediation, temporary mitigation, and approved risk acceptance. Each deserves its own status. Combining them hides the difference between removing a vulnerability and managing an exposure that remains.
A deadline is a policy commitment, not an estimate of how quickly every fix can be delivered. When a deadline cannot be met, record the reason, responsible owner, interim protection, and approval decision rather than silently changing the target.
Critical severity: 9.0–10.0 CVSS points
Critical findings belong at the front of your assessment queue. Confirm the affected assets, determine exposure, check exploitation evidence, and identify the available corrective action before choosing the response path.
Do not interpret the critical label as a complete implementation plan. An update, configuration change, component removal, and system replacement require different work and validation.
Best for critical findings: immediate assessment followed by a documented remediation or containment decision. If permanent remediation requires testing, track the temporary control separately and retain an accountable owner for the underlying fix.
The benefit of an emergency response path is clear ownership and escalation. The trade-off is operational disruption, so require evidence of both the security problem and the change's effect before closing the finding.
High severity: 7.0–8.9 CVSS points
High-severity findings need assigned owners and enforceable deadlines. Prioritize within that queue using asset exposure, business importance, and exploitation evidence rather than treating every high finding as interchangeable.
A high finding on an exposed service deserves a different review from a high finding on a service with verified access restrictions. Record the evidence behind that distinction; a reassuring asset label is not enough.
Best for high findings: a tracked remediation plan with risk-based escalation. Planned work supports testing and coordination, but the plan must change when threat conditions or exposure changes.
For your 2026 policy, make the escalation trigger explicit. The finding should not remain on a routine schedule merely because that schedule was appropriate when the ticket opened.
Medium severity: 4.0–6.9 CVSS points
Medium findings belong in a maintained remediation queue, not an unowned backlog. Give each finding a responsible team, a target based on policy, and a clear validation requirement.
Review context before accepting routine scheduling. A medium technical rating does not answer whether the affected component handles sensitive information or participates in a broader attack path.
Best for medium findings: planned remediation with documented escalation conditions. Batching compatible changes can simplify delivery, but waiting for a maintenance window is not a substitute for assessing exposure.
Where remediation is blocked, capture the actual dependency. Distinguish waiting for a vendor correction from waiting for an internal approval; those blockers need different decisions.
Low severity: 0.1–3.9 CVSS points
Low-severity findings still need a disposition. Schedule remediation, validate that the finding is incorrect, or approve an exception through your defined process.
Do not close a low finding because it has remained open for a long time. Age describes the backlog; it does not demonstrate that the vulnerability disappeared.
Best for low findings: scheduled maintenance with periodic risk review. Routine handling protects attention for more urgent work, but indefinite deferral leaves you without a defensible closure decision.
Reassess the finding when the asset's role or exposure changes. Your original scheduling decision should remain traceable even when a later review assigns a different priority.
Why vulnerability remediation time varies
The following factors should inform your policy and case-level decisions. Record them as evidence rather than using them as generic reasons for delay.
- Exploitation evidence: Document evidence of active exploitation or relevant threat activity and decide whether emergency handling is required.
- Asset exposure: Establish whether an attacker can reach the affected service and whether access restrictions are verified.
- Business impact: Identify the service, information, and business processes affected by exploitation or by the corrective change.
- Fix readiness: Distinguish an available correction from a vendor dependency, replacement project, or configuration workaround.
- Change dependencies: Record testing, approvals, maintenance restrictions, and the teams responsible for clearing them.
- Validation requirements: Specify the evidence needed to confirm that the affected condition no longer exists.
These factors explain why two findings with the same severity can follow different schedules. They do not authorize undocumented exceptions or erase an applicable deadline.
How do you measure remediation time consistently?
Use an explicit measurement contract for your 2026 dashboard. Define the start event, stop event, unit of measurement, and treatment of reopened findings before comparing teams.
- Record discovery. Preserve when your organization first detected the finding on the affected asset. Keep the original timestamp when another scanner later reports the same condition.
- Assign ownership. Identify the team responsible for the corrective action. Track assignment delay separately so it does not disappear inside implementation time.
- Apply the fix. Record the corrective change and the assets it covers. A completed change request is implementation evidence, not automatic proof of closure.
- Verify closure. Confirm the vulnerable condition is absent using evidence appropriate to the finding. Record verification separately from the deployment timestamp.
- Review exceptions. Retain the original discovery record, approval, expiration, and interim controls for findings that remain unresolved.
Measure discovery-to-verified-closure time when reporting the full remediation lifecycle. If you also measure ticket-to-closure time, label it separately; the ticket creation event is not necessarily the discovery event.
Calculate elapsed time using consistent calendar or business-time rules. State the rule beside the metric so a reader can interpret the result without reconstructing your workflow.
What should your dashboard show?
Report closed findings by severity and keep unresolved findings visible. Pair elapsed time for completed work with the age and deadline status of the open queue.
A mean summarizes completed durations but does not describe the oldest unresolved exposure. Include the median and a clearly defined upper percentile when your reporting needs to show the distribution, and state which findings the calculation includes.
Preserve severity changes rather than overwriting history. Your dashboard should distinguish the original classification, current classification, and reason for reprioritization.
Does mitigation stop the remediation clock?
Mitigation does not automatically mean remediation is complete. Restricting access or disabling a vulnerable function can reduce exposure while the underlying vulnerable component remains.
Decide in policy whether a verified compensating control satisfies a particular requirement. If it does, retain the evidence and approval rather than relabeling every workaround as a permanent fix.
Track time to mitigation separately from time to permanent remediation. That distinction shows whether you reduced exposure promptly without obscuring unresolved technical work.
What if a patch is unavailable?
An unavailable patch requires a documented risk decision, not an invented completion date. Evaluate available workarounds, access restrictions, feature disablement, replacement, or retirement against the affected service's requirements.
Assign an owner to monitor the dependency and define a review trigger. Record what protection exists now and what event will restart implementation work.
For your 2026 exception register, retain the original finding, affected assets, approval, review condition, and final resolution evidence. An exception acknowledges a decision about unresolved risk; it does not demonstrate that the vulnerability was fixed.
Where does a vulnerability management platform fit?
Brinqa is a vulnerability and exposure management platform for teams evaluating software in that category. Assess platform fit against your documented remediation process rather than assuming a platform determines the correct deadline.
For a Brinqa vulnerability management evaluation, request evidence that your required timestamps, ownership rules, exception records, and closure criteria can be represented. Treat those as evaluation questions, not assumed capabilities.
Brinqa is relevant to vulnerability and exposure management buyers; platform selection does not replace remediation policy. Use the Brinqa site to assess the platform against your requirements.
FAQ
How many days do we have to remediate a critical vulnerability?
A critical severity label does not establish a universal number of remediation days. Apply your binding requirements and internal policy, then assess exploitation evidence, exposure, and business impact for accelerated action.
Does CVSS tell us the remediation deadline?
CVSS describes vulnerability severity, not a remediation deadline. FIRST's CVSS v3.1 critical band is 9.0–10.0 points, but that score range does not prescribe a completion window.
Is remediation time the same as our vulnerability SLA?
Remediation time is an observed duration; a vulnerability SLA is a target. Compare verified completion against the applicable target while keeping overdue open findings visible.
When should the vulnerability remediation clock start?
For a full-lifecycle metric, start the clock at your organization's first detection of the finding on the affected asset. Define that rule consistently and preserve the timestamp across duplicate reports.
Can we close a vulnerability when the patch ticket is complete?
Close the vulnerability when evidence confirms the vulnerable condition is absent, not merely when the patch ticket is complete. Record implementation and verification as separate events.
Should we fix every critical vulnerability before any high vulnerability?
Severity alone should not determine the entire remediation order. Assess exploitation evidence, asset exposure, business impact, and applicable deadlines before ordering work across severity bands.
Does an approved exception count as remediation?
An approved exception is a documented decision about unresolved risk, not proof of remediation. Keep the finding's status, approval, interim controls, and review condition visible until final resolution.
One last thing
A faster closure metric is not enough if your oldest important exposures remain open. Before changing your severity deadlines, inspect the unresolved queue and confirm that each important finding has an owner, a justified target, and a credible next action.
Use your next 2026 policy review to test a completed finding from discovery through verification. If the evidence cannot explain when exposure ended, improve the closure rule before celebrating the reported remediation time.
