BIPI
BIPI

Your Patch Policy Says 30 Days. Reality Is 90. Here Is Why and What to Do

Cybersecurity

Every security policy claims 30-day patching for criticals. Real-world P95 across the 40+ environments we have measured sits at 60-90 days. The fix is not more pressure on operations, it is changing how you ship patches.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 15, 2024 · 7 min read

#patching#vulnerability-management#operations

Pull up your vulnerability management dashboard right now. Look at the time-to-patch P95 for criticals over the last 12 months. If you are in a regulated industry, your policy says 30 days. Your actual number is probably 60-90. We have measured this across 40+ environments and the median P95 sits at 73 days. The teams that hit 30 days consistently are doing something structurally different from everyone else.

Why 30 days does not happen

It is rarely laziness. The blockers are real:

  • Application dependencies. Patching a library breaks the app on top of it. QA cycle takes 2 weeks minimum.
  • Change windows. Many organizations only patch production during monthly windows. If a critical drops on day 3 of the cycle, it waits 27 days for the next slot.
  • Vendor delays. ISVs do not always release a compatible version on the same day as the upstream patch. Oracle, SAP, and old Java apps are notorious.
  • Regression risk. Operations remembers the time a patch took down production for 4 hours. They are not eager to repeat that.
  • Ownership ambiguity. Server is in IaaS, app is owned by the business unit, OS is owned by infrastructure, third-party agent is owned by security. Nobody patches because everyone assumes someone else will.

What actually works: ringed deployment

Stop trying to patch everything in one window. Adopt a ring model:

  1. Ring 0 (canary): 1-2% of fleet, ideally pre-prod and a few opted-in production nodes. Patch within 24 hours of release.
  2. Ring 1 (early): 10-20% of fleet, includes representative samples of every workload type. Patch within 7 days.
  3. Ring 2 (broad): 70-80% of fleet, the bulk of production. Patch within 21 days.
  4. Ring 3 (last): 1-5% of fleet. Critical systems, regulated workloads, things that need vendor approval. Patch within 30-45 days with documented exception.

A SaaS company we worked with shipped this model and went from 78-day P95 to 26-day P95 in two quarters. The trick was that Ring 0 caught regressions before they hit Ring 1, so by Ring 2 the patch was de-risked and operations resistance disappeared.

Pre-staged builds

If you build golden images, pre-stage the patched image in your image pipeline as soon as the patch releases. Auto-rebuild the image, run the test suite, and have it ready to deploy. The patch is not 'ship the patch'. It is 'ship the new image'. This works for cloud workloads, container base images, and any workload that uses immutable infrastructure.

For traditional VMs that cannot be re-imaged, in-place patching tools like Ansible, BigFix, or Tanium can pre-stage the patch package on every endpoint without applying it. When the change window opens, applying takes seconds because the bits are already local.

The CISA KEV pivot

Stop treating all criticals as equal. CISA's Known Exploited Vulnerabilities catalog flags the ones that are actually being exploited in the wild. We tier patching SLAs by KEV status:

  • On the KEV list with active exploitation: emergency patch within 7 days, override change windows
  • Critical CVSS but not on KEV: standard 30-day SLA
  • High CVSS, not on KEV, no public exploit: 60-day SLA

This focuses scarce operations capacity on patches that actually matter. Most organizations have 200-400 'critical' CVEs at any given time. Of those, 5-15 are typically on KEV. That is the patch list that demands a 7-day response.

What to tell the auditor

When the auditor asks why a critical is 60 days old, do not lie. Show the ring model, the KEV-prioritized SLA, the documented exception process, and the actual P95 trend. Auditors accept evidence-based programs that produce measurable outcomes. They reject policies-on-paper that nobody follows.

A 30-day policy that is missed 50% of the time is worse than a 45-day policy that is hit 95% of the time. Honest SLAs build trust with auditors and operations both.

Re-baseline the policy to match the program you can actually run. Then measure relentlessly. The policy is a target, the metric is the truth, and the gap between them is the project plan.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.