When a critical CVE drops, the clock starts immediately. Your team has hours, not days, to assess, test, and deploy a patch—or document why you're accepting the risk. I've worked through dozens of emergency patch cycles, and the difference between a smooth rollout and a weekend outage usually comes down to having a clear timeline and a repeatable testing workflow already in place.
The industry has converged on a handful of standard SLAs for critical vulnerabilities, and most compliance frameworks now bake those timelines into their audit criteria. Understanding what's expected and how to meet it without introducing new problems is table stakes for any team running production infrastructure.
What counts as critical?
Not every CVE is an emergency. Critical usually means a remotely exploitable vulnerability that requires no authentication and affects a widely deployed service. Think RCE in OpenSSH, a privilege escalation in the kernel, or an authentication bypass in your web server.
Most organizations follow CVSS scoring as a starting point. A score of 9.0 or higher typically triggers the critical SLA. But context matters more than the number. A critical SQLi in your public-facing app is more urgent than a kernel bug that requires local access when you're running a hardened cloud environment with no shell users.
Your own asset inventory should tag which systems are internet-facing, which handle customer data, and which are isolated behind layers of defense. That metadata tells you how fast you need to move when a new CVE lands.
Industry-standard SLAs
Most security frameworks expect critical vulnerabilities patched within 24 to 72 hours of a patch becoming available. The tighter end of that range—24 hours—usually applies to internet-facing systems with known active exploits in the wild. The 72-hour window is more common for internal systems or when the vendor patch needs additional validation.
Here's what I see in practice:
- 24 hours: Externally accessible services, active exploitation confirmed, proof-of-concept code public.
- 48 hours: Internet-facing but not yet exploited, or high-value internal targets like domain controllers and database servers.
- 72 hours: Internal systems, or cases where the patch itself has a history of instability and needs extra testing.
- 7 days: High-severity (not critical) issues, or critical issues that require coordinated maintenance windows.
PCI DSS historically said 30 days for critical vulnerabilities, but that's outdated. Modern interpretations and other frameworks like NIST, CIS, and SOC 2 all push for the faster timelines above. If you're still working on a 30-day cycle, you're behind.
The real timeline: from disclosure to production
A 48-hour SLA doesn't mean you have 48 hours to start looking at the problem. It means the patch is live in production within 48 hours of the vendor releasing it. Here's how that time actually breaks down:
Hour 0-2: Notification and triage
Your vulnerability scanner, vendor mailing list, or monitoring service flags the CVE. Someone on the team confirms it applies to your environment and checks whether a patch exists. If active exploitation is confirmed, you escalate immediately and may skip some later testing steps.
Hour 2-6: Initial assessment and testing
Pull the patch into a staging or test environment that mirrors production. Run your standard test suite—unit tests, integration tests, and any smoke tests that cover the affected component. For a kernel patch, that might mean booting a test VM and confirming services start. For a web server update, hit your critical endpoints and check logs for errors.
Hour 6-12: Deploy to canary or subset
Roll the patch to a small subset of production—a single web server behind your load balancer, one worker node in your Kubernetes cluster, or a low-traffic region if you run multi-region. Monitor error rates, CPU, memory, and application-specific metrics. If the canary is stable for an hour or two, proceed.
Hour 12-24: Full production rollout
Deploy everywhere else. For a fleet of servers, automate it. For a smaller setup, SSH in and update node by node, watching logs as you go. Document what you deployed and when.
Hour 24-48: Post-deployment validation
Confirm the vulnerability is actually closed by re-running your scanner or testing the exploit path manually. Check that monitoring didn't pick up any new anomalies. Update your incident ticket and notify stakeholders.
That's the happy path. In reality, you'll hit problems—maybe the patch breaks a third-party integration, or your staging environment isn't configured the same way as production. Build slack into your process for those surprises.
Testing workflow that doesn't slow you down
Speed and safety aren't opposites if your testing workflow is already wired into your deployment process. The teams that consistently hit their SLAs have a few things in common.
Infrastructure as code and config management
If you're applying patches by hand, you'll never scale. Tools like Ansible, Puppet, or even a well-organized shell script library let you push updates to dozens or hundreds of nodes in parallel. Your playbooks should already handle the common tasks: update package lists, apply patches, restart services, and verify they came back up.
Here's a minimal Ansible example for updating a package and restarting the service:
- name: Apply critical security patch
hosts: web_servers
become: yes
tasks:
- name: Update OpenSSH
apt:
name: openssh-server
state: latest
update_cache: yes
when: ansible_os_family == "Debian"
- name: Restart SSH
service:
name: ssh
state: restarted
- name: Wait for SSH to come back
wait_for:
port: 22
delay: 5
timeout: 60
Run that against a test group first, then production. If a node fails the wait_for check, Ansible stops and you investigate before proceeding.
Automated smoke tests
Your CI/CD pipeline probably already has a test suite. The same tests that run on every commit should run after every patch deployment. If your app is a web service, hit the health endpoint, log in as a test user, and perform one critical transaction. If it's a database, run a query and check replication lag.
These don't have to be exhaustive. You're looking for obvious breakage—HTTP 500s, connection refused, or processes that fail to start.
Staged rollouts and rollback plans
Never patch everything at once. Deploy to one node, then a canary group, then the rest. Keep the previous package version cached locally so you can downgrade quickly if something breaks.
On Debian-based systems, apt keeps old .deb files in /var/cache/apt/archives/ by default. On RHEL/CentOS, yum history lets you undo transactions:
yum history list
yum history undo <transaction_id>
If you're running containers, rollback is even easier—just redeploy the previous image tag.
Logging and metrics
You can't validate a patch if you don't know what normal looks like. Before you start patching, take a snapshot of key metrics: request latency, error rates, CPU and memory usage. Compare those to the same metrics an hour after the patch. If something spiked, dig into logs before rolling out further.
I've caught regressions this way that wouldn't have shown up in functional tests—an NGINX patch that increased memory usage by 20%, a kernel update that doubled context switch rates. Both were fixable, but only because we were watching the right numbers.
What if you can't patch in time?
Sometimes the patch isn't ready, or it breaks something you can't work around in 48 hours. You still have to do something. Document your decision and implement compensating controls.
Compensating controls might include:
- Blocking the vulnerable service at the firewall if it's not business-critical.
- Restricting access to a VPN or IP allowlist.
- Enabling additional logging and monitoring to detect exploit attempts.
- Applying a vendor-provided workaround, like disabling a specific feature or config option.
Update your risk register and set a deadline for applying the actual patch. Compliance audits will ask why you missed the SLA, and "we were busy" isn't an acceptable answer. "We blocked external access and scheduled the patch for the next maintenance window" is.
Organizing your patch pipeline
If you're still patching reactively—waiting for a CVE to drop and then scrambling—you're always going to be behind. Build a regular patching cadence for non-critical updates so your tooling and runbooks stay sharp.
Most teams I know run monthly or quarterly patching windows for everything that isn't critical. When a critical CVE comes in, you're just accelerating a process you've already practiced. Your Ansible playbooks are tested, your rollback procedure is documented, and your team knows who does what.
Keep a patch log. Record what you patched, when, and what version you deployed. A spreadsheet or a ticketing system works fine. When an auditor asks, you can point to a dated record instead of trying to reconstruct it from memory.
Frequently asked questions
Q: What if the CVE affects a service I can't easily patch, like a legacy application?
Isolate it. Put it behind a reverse proxy, restrict access by IP, and monitor it closely. If you can't patch it, at least make it harder to reach.
Q: Do I need to patch test and development environments on the same timeline?
No, but patch them soon after. If dev and staging drift too far from production, they stop being useful for testing. Aim for a one-week lag at most.
Q: How do I prioritize when multiple critical CVEs drop at once?
Start with internet-facing services, then move to anything that handles authentication or sensitive data. If two CVEs have the same exposure, patch the one with public exploit code first.
Q: Should I reboot after every patch?
Kernel patches and some library updates require a reboot to take effect. Application-level patches usually just need a service restart. Check the vendor advisory or test it—if lsof shows the old library still loaded in memory, restart the process.
Build the muscle before the crisis
The 48-hour SLA feels achievable when you've already practiced the workflow a dozen times on lower-severity patches. You know your tooling, your team has clear roles, and your staging environment is an accurate reflection of production. When a critical CVE lands, you're executing a familiar playbook under time pressure, not inventing the process on the fly.
Patch often, even when it's not urgent. That keeps your systems current and your response sharp when it matters.