The cadence question is the whole game

Knowing a patch exists is trivial — vendors announce them, scanners flag them, the news covers the bad ones. The hard question is when: how fast does this particular fix need to land? Patch too aggressively and you turn your team into an unpaid QA department breaking production every Tuesday. Patch on a sleepy "we do updates monthly" rhythm and you leave a known, weaponized hole open for weeks while exploit code circulates. Patch cadence is the discipline of answering "by when" with a rule instead of a mood.

This is distinct from the broader work of vulnerability management that scales, which is about which findings deserve attention at all. Cadence is the next question down: for the findings that do matter, what's the clock?

Two dials set the clock: severity and exposure

A single severity rating is not enough to set a deadline, because the same CVE is a five-alarm fire on one box and a shrug on another. The deadline comes from two dials turned together:

  • Severity — how bad is the flaw itself? Remote code execution outranks a local privilege escalation outranks an information leak. Start with the CVSS score, but treat it as the floor of the conversation, not the verdict.
  • Exposure — can an attacker actually reach the vulnerable thing? An internet-facing service with no authentication is a different universe from an internal tool behind a VPN, which is different again from a library buried in a batch job nothing untrusted can invoke.

Multiply, don't add. A critical CVE on an unreachable internal box can rank below a high on your public login page, because exposure is the term that turns a theoretical flaw into a reachable one. The same reachability-first logic that drives sane finding triage drives sane patch deadlines.

A starting cadence you can actually defend

Pick concrete windows, write them down, and measure against them. A reasonable default for a small team:

  • Critical, internet-facing, or actively exploited in the wild: patch within 72 hours — and if it's a known exploited vulnerability with public proof-of-concept code, treat that as emergency change, not routine.
  • High severity, exposed: 7 days.
  • Medium: 30 days, batched into your normal maintenance window.
  • Low: quarterly, or accept the risk explicitly and write down why.

The exact numbers matter less than the fact that they exist, are published, and are tracked. A cadence nobody measures is a wish. The "actively exploited" carve-out is the one that earns its keep — when a flaw is being used in real attacks right now, the normal clock is wrong, and you want a defined emergency lane rather than an argument held under pressure.

"Actively exploited" should jump the queue automatically

Severity ratings describe the flaw in a vacuum. Real-world exploitation describes the weather. A medium-rated bug that suddenly appears in attacker toolkits has effectively been re-rated by the internet, and your process should notice. Wire in a signal — public exploited-vulnerability catalogs, threat feeds, vendor emergency advisories — that can promote a finding's urgency on its own, the same way an aging critical should escalate before anyone files a ticket. The goal is a queue where the genuinely urgent thing surfaces without a human having to be paying attention at the right moment.

Patching isn't done until it's verified

The most common patch-management lie is "we applied it." The update failed silently on three hosts, a service didn't restart, a container image got rebuilt from a stale base — and the flaw is still live on machines your dashboard swears are clean. A patch is not closed until a re-scan confirms the vulnerable version is actually gone everywhere it lived. That verified-closure rule is the same one behind a disciplined findings management workflow: resolution requires evidence, and a closed item that reappears reopens itself rather than masquerading as a brand-new finding next cycle.

Track three numbers and you'll know whether your cadence is real:

  • Mean time to patch, by severity. Rising MTTP on criticals is a capacity or ownership problem no tool fixes for you.
  • SLA-breach rate. What fraction of patches blew past their window?
  • Oldest unpatched critical. Your single worst standing exposure, named and dated.

When you genuinely can't patch in time

Sometimes the patch breaks a dependency, the vendor hasn't shipped a fix, or the maintenance window is days away and the risk is real now. "Patch immediately" stops being useful advice; what you need is a compensating control and a record. Reduce exposure another way — pull the service behind authentication, add a WAF rule, restrict the source IPs, take the box off the internet — and document the deviation as a time-boxed risk acceptance with an owner and an expiry. The difference between a mature program and a negligent one isn't that the mature one always patches on time. It's that when it can't, it knows, it compensates, and it wrote down the decision.

Patch cadence isn't about patching faster for its own sake. It's about being able to answer one question for any open vulnerability — "by when, and why that date?" — with a rule your team agreed to in calm conditions, instead of a guess made in the middle of an incident.