Patch Management Checklist for Small Teams (Monthly Cadence That Ships)

Most small teams don't skip patching out of laziness — they skip it out of fear. Every patch is a change, changes break things, and "we'll patch it next window" quietly becomes never. Then a VPN or a PDF reader makes the news and the patch that sat for 200 days suddenly becomes an all-hands emergency. The fix isn't a tool. It's a short monthly cadence and a triage rule that tells you which of the 200 open CVEs actually matters. Here's the checklist.

The monthly patch cycle — copy this

1. Keep one inventory list. Every server, workstation, router, NAS, and container host on a single list with its OS and last-patched date. If you can't say how many machines you have, that unknown machine is your finding #0 — it's the one nobody patches.
2. Triage advisories into 4 tiers. Tier 1: actively exploited or auth bypass — patch within 48 hours. Tier 2: network-facing or remote code execution — 7 days. Tier 3: privilege escalation or local — 30 days. Tier 4: everything else — next monthly window. Without tiers, every advisory is urgent and nothing gets patched.
3. Take the snapshot before the patch, not after. Snapshot or backup every host you're about to touch, and write the rollback command (downgrade, uninstall, config restore) next to it. A patch you can't undo is a change — and it belongs in the same discipline as every other change.
4. Watch the blast radius, don't feel it. If you have staging, patch there first. If you don't, patch ONE production host, run the service for 24 hours, then roll the fleet. "apt said ok" is not verification — check the version command and the service health check.
5. Patch in the window, with a watcher. Pick a monthly window (e.g. first Wednesday 14:00–16:00), put it on the calendar, and have one person watching for the first 30 minutes after. Unwatched patches are discovered the same way unwatched changes are: by customers.
6. Schedule the reboots. The reboot is the real deadline. A patched-but-not-rebooted kernel is a server running yesterday's vulnerability with a green dashboard. Batch reboots into the same window and accept the 4 minutes of downtime — it's cheaper than the CVE.
7. Patch the things that aren't the OS. The VPN appliance, the printer firmware, the npm and pip dependencies, the TLS certs, the firewall. Attackers don't care that your Ubuntu is current when your router is 14 versions behind.
8. Close the log within 24 hours. One line per host: date, CVEs applied, outcome, rollback used (yes/no). Ten closed log lines a quarter beats a scanning tool nobody reads.

The one-line patch log

The rules that make the cadence stick

• Reachable beats loud. A CVSS 9.8 on an internal box that only one admin can reach is usually less urgent than a CVSS 7.5 on your internet-facing gateway. Patch what's reachable first — exposure order, not headline order.
• Emergency patches get a retro-record, not a skip. When a Tier 1 lands mid-week, you patch immediately — and write the one-line log within 24h. The rule isn't "no patches outside the window", it's "no patches without a record".
• Watch advisories 20 minutes a week. One person, one list (vendor advisories + a feed), 20 minutes, mark which tier each one falls into. That's the entire "patch intelligence" function for a team under 30 people.
• End-of-life software is a project, not a patch. Anything past vendor support goes on the replacement list with a date. You cannot patch your way out of EOL — and "we know it's risky" isn't a control, it's an apology you haven't written yet.
• Failed patches are findings too. When a patch breaks a service, the rollback isn't the end of the story — test the same patch on one more host before the next window, and write down what broke. Recurring patch failures mean a test environment is overdue.

---

The Ops Starter Kit Vol. 2 ($27) includes the full maintenance pack — patch log, maintenance-window calendar, and the change record this checklist plugs into — launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.