Patch cadence calendar: what patches when, on one page

Patching fails at small teams not because anyone disagrees with it, but because it has no when. "We patch when we get to it" means the scary updates happen during incidents and the boring ones never happen at all. The patch management checklist covers what to patch; this page covers the cadence — the four lanes that sort every patch by urgency, the calendar anchors that survive busy weeks, the deferral card that keeps skipping honest, and the one-page report that proves the machine is running. The whole system fits on one calendar page and costs nothing but a recurring block of an afternoon.

1. The four lanes: every patch lands in exactly one

• Lane 0 — emergency (24 hours). Actively exploited vulnerabilities (CISA KEV list hits), exposed-service CVEs with public exploits, and anything touching internet-facing auth. The rule: patch inside 24 hours, outside business hours if needed, and note in the log that you did it hot. Emergency patches are allowed to be messy; they are not allowed to be skipped. The first 30 minutes runbook takes over if the patch is a response to something already on fire.
• Lane 1 — high (7 days). CVSS 9+ on internal systems, any CVE in your identity provider, remote code execution on machines with user data. These ride the next scheduled maintenance window, never the one after that. If two lanes collide, Lane 1 pre-empts the monthly wave — the wave simply starts with them.
• Lane 2 — the monthly wave (scheduled). Everything else: routine OS updates, application releases, firmware you've been meaning to do. One wave per month, all machines, one afternoon, every machine through the same reboot-and-verify pass. The wave is the heartbeat — when the wave is reliable, Lanes 0 and 1 stay rare.
• Lane 3 — the quarterly sweep (scheduled). The things too big or too scary for the wave: the hypervisor hosts, the NAS firmware, the firewall OS, the backup server nobody dares reboot. One per quarter, with a tested snapshot or backup first — the restore test is the rehearsal for exactly this afternoon.

2. Calendar anchors that survive busy weeks

• Anchor to Patch Tuesday, not to memory. Microsoft ships the second Tuesday of the month; most vendors you care about follow within days. Your monthly wave lives on the third Tuesday: seven days of vendor dust-settling, then you sweep everything in one pass. Put it in the shared calendar as a recurring all-day event named "PATCH WAVE" — boring, visible, unmovable.
• Give the wave a window, and give the window a name. Same afternoon every month, e.g. 14:00–18:00. Named windows do two things: the team plans around them, and the change freeze policy can treat them as protected time — during the wave window, nothing else competes for the admin's hands.
• Attach the wave to existing rhythm, not to willpower. Wave Wednesday follows the weekly review; the quarterly sweep follows the quarter's drill day so the "prove you can recover" muscle is already warm. Cadence stacked on cadence survives; cadence floating alone dies in the first busy sprint.
• The 24-hour pre-wave check. The day before: read the vendor advisories, list the machines in scope, confirm you have console/physical access for the two that always need it. Fifteen minutes of prep converts wave day from archaeology into execution.

3. The deferral card: skipping is legal, silent skipping is not

• Every deferral gets four lines. What is being deferred, why (the concrete risk of patching now — vendor bug, business hours, staging test pending), when it will be patched (a date, not "soon"), and who accepted it. Written into the patch log next to the machine's name. A deferral without a date is not a decision; it is a deletion.
• Deferrals expire loudly. The card's date is a calendar entry, not a hope. On expiry the patch goes to the front of the next wave automatically, and if the deferral was Lane 1, the expiry fires the emergency lane instead. The system's integrity is the point: one honest deferral with a date is discipline; three quiet ones is a spreadsheet of lies.
• CAP the deferrals. Any machine with two live deferrals stops receiving new ones — it becomes the next wave's first target regardless of what its owner prefers. This is the rule that keeps the calendar honest on the machine everyone is scared of.

4. The vendor EOL watch: the calendar item nobody schedules

• Patching cannot save software that stopped shipping patches. The quiet catastrophe at small teams is the EOL system — the old NAS firmware, the abandoned wiki app, the printer with a 2017 codebase — that receives no updates at all. It is unpatchable, which makes it a permanent Lane 0, permanently unfixable by the cadence you just built.
• Quarterly, list it. One calendar item per quarter: walk the asset inventory and mark every system whose vendor support ends within twelve months. Each gets a written fate: replace, migrate, or accept-with-compensation (network isolation, no internet exposure). "Accept" is allowed; "ignore" is not. The vendor outage runbook and the escalation ladder are what you use when the vendor is still alive but barely.

5. The one-page evidence report

• Log every wave in three columns: machine, patches applied, result. Same one-page format every month — the log is the evidence. When an auditor, an insurer, or a customer security questionnaire asks "do you patch regularly?", you will have eleven consecutive wave reports instead of a shrug. The SLA template crowd call this evidence; your insurer calls it a discount.
• Report misses with the same calm as hits. The monthly line in the status report reads: "September wave: 14/15 patched, 1 deferral (billing server, vendor regression, expires 15 Oct)." A cadence that sometimes misses and always says so is more credible than one that claims perfection and hides three EOL boxes.
• Tie the misses to severity, not to guilt. A missed Lane 2 wave is a scheduling conversation; a missed Lane 0 is an incident, and the postmortem template applies. The severity matrix decides which conversations happen — the calendar just needs to keep its promises or say why not. The status page template covers what you tell humans when the patching itself breaks something.

Small-team honesty note: a five-person company does not need a patch management platform; it needs a recurring calendar event and a log file. This page's entire system is four lanes, three anchors, a four-line deferral card, and one evidence page. The trap this page exists to prevent is cadence theater — a beautiful policy document with no calendar entry behind it. If the PATCH WAVE event is not in your calendar as you read this, the cadence does not exist yet. Put the event in, run the first wave ugly, and let the system make itself real. The weekly ops review is where the coming week's patch windows get named before they land.

Related: patch management checklist · change freeze window policy · asset inventory checklist · IT asset inventory template · backup restore test · severity matrix · weekly status report · vendor outage runbook · vendor escalation ladder · SLA/SLO definition · postmortem template · status page template · first 30 minutes · new admin's first week · hot-spare loaner laptop

Patches and freezes meet on one row: the change-freeze calendar template writes down, per window, which patch lanes still run and which wait — so nobody relitigates it at 4pm on December 23.