How Quickly Should Critical Vulnerabilities Be Patched?

Why "critical" alone is not a priority

A CVSS score tells you how severe a vulnerability is in theory. It does not tell you how dangerous it is to your environment. A 9.8 vulnerability in a library running on an isolated lab machine is less urgent than a 7.5 in a VPN gateway that every remote employee touches.

Effective prioritization combines the vendor severity with context you already have:

• Exposure. Is the affected system internet-facing, or reachable only from a restricted internal segment?
• Exploitation status. Is there public proof-of-concept code, or confirmed active exploitation in the wild?
• Asset criticality. Does the system hold customer data, run production workloads, or control authentication for everything else?
• Compensating controls. Is the vulnerable feature disabled, behind a WAF rule, or otherwise mitigated while you test the patch?

Realistic SLA tiers

Most mature patch programs converge on a tiered model. The exact numbers vary, but the shape is consistent: a small class of emergencies measured in hours, a critical tier measured in days, and everything else measured in weeks or maintenance windows.

The table below shows a defensible starting framework. Adjust the numbers to your staffing and change-control reality — a deadline nobody can meet is worse than a slower one people actually hit.

The emergency lane: mitigate first, patch second

When a vulnerability is being actively exploited and the affected system is exposed, waiting for full regression testing is not a plan. Neither is blindly pushing an untested patch to production at 2 a.m. The emergency lane has two steps, and the first one buys you time for the second.

Step 1: mitigate

• Disable the vulnerable feature or component if it is not essential
• Restrict network access to the affected system or port
• Apply vendor workarounds, WAF rules or configuration changes
• Increase logging and monitoring on the affected assets

Step 2: patch and verify

Apply the vendor fix, verify it took hold (version check plus a rescan, not just a green checkbox from the deployment tool), and confirm the mitigation can be safely removed. Then document the timeline — it feeds your compliance evidence and your next post-incident review.

If your emergency process currently depends on whoever happens to read the advisory email, that is a gap worth closing. The warning signs in five signs your IT environment is not fully managed often show up first in exactly this lane.

What actually slows patching down

Organizations rarely miss patch SLAs because they do not care. They miss them for predictable, structural reasons:

• No asset inventory. You cannot patch what you have not found. Unknown shadow systems are where old vulnerabilities live longest.
• Fear of breaking production. Without test rings or rollback plans, every patch feels like a gamble, so it gets deferred.
• Manual workflows. Patch Tuesday handled by hand does not scale past a few dozen machines.
• Ownership gaps. When "everyone" owns patching, no one does. SLAs need a named owner per asset class.
• Third-party applications. OS patching is usually solved; browsers, PDF readers and line-of-business apps are where coverage quietly stops.

Each of these has an operational fix: continuous discovery, ring-based deployment, automation through an endpoint management platform, explicit ownership, and a third-party patching catalog. This is the core of what a managed patch management service is built to remove.

Balancing speed against stability

The tension between "patch now" and "do not break anything" is real, and pretending otherwise destroys credibility with the teams who have to execute. The resolution is structure, not willpower:

• Deployment rings. Pilot group first, then a broad ring, then everything else. Problems surface on a small population, not on payroll day.
• Rollback plans. Know how to uninstall or revert before you deploy. A patch with no rollback path gets a higher testing bar.
• Exceptions with expiry dates. Some systems genuinely cannot be patched on schedule. Record the exception, the compensating control, and a review date — never leave it open-ended.
• Different bars for different tiers. Emergency-tier patches get abbreviated testing and heavier monitoring; standard-tier patches get the full cycle.

Measuring whether it is working

A patch SLA you never measure is a hope, not a control. Track a small set of metrics and review them monthly: percentage of assets within SLA by tier, mean time to patch for critical vulnerabilities, exception count and age, and coverage of your asset inventory.

We cover the metric definitions, dashboard design and reporting cadence in how to measure patch compliance. If you want a quick external snapshot of where your program stands today, the security posture score calculator is a useful starting point.

The business case for faster patching

Patch speed is not an IT vanity metric — it is a direct reduction in the window during which a known weakness can be used against you. Attackers operationalize public exploits quickly after disclosure; every day a critical vulnerability sits unpatched on an exposed system is a day you are relying on luck rather than process.

The argument lands with leadership when it is framed in terms they already manage:

• Insurance and contracts. Cyber insurance questionnaires increasingly ask about patch cadence and time-to-remediate. Weak answers raise premiums or block coverage — see preparing for a cyber insurance questionnaire.
• Incident cost asymmetry. The cost of a controlled patch cycle is predictable and small. The cost of responding to a breach of an unpatched, known vulnerability is neither — and it is the hardest kind to explain afterward.
• Audit and compliance. Documented SLAs with measured compliance turn patching from a claim into evidence.
• Staff time. Automation and a managed service convert unpredictable emergency scrambles into a steady, budgetable operating cost.

Pairing patch SLAs with continuous scanning and remediation tracking — a formal vulnerability management program — closes the loop between "we know about it" and "it is fixed and verified."