A critical CVE lands on a Tuesday morning. By noon, three teams are asking which systems matter. By Friday, the patch is still sitting in a test queue while a proof-of-concept exploit circulates. The gap between "we know about it" and "we fixed it" is where most breaches live, and it is usually a prioritization problem, not a technical one.
Thirty days is enough time to close the genuinely dangerous gaps without freezing the business in change-control meetings. What follows is a practical framework: inventory, scoring, staged deployment, verification. It assumes you have limited people, imperfect tooling, and systems that cannot all go down at once.
Why a 30-Day Clock Beats "Patch Everything Now"
Blanket patching sounds responsible and fails in practice. If everything is urgent, nothing is, and the change board becomes a bottleneck. A 30-day cycle gives you a defensible target: anything remotely exploitable, internet-facing, or already being exploited gets closed inside the window. Everything else gets scheduled into normal maintenance.
The output you are aiming for is not a perfect patch rate. It is a documented position: here is what we fixed, here is what we mitigated, here is what we accepted, and here is who owns each item. Auditors and incident responders both care more about that clarity than about a percentage.
Days 1–3: Fix the Inventory Before Touching a Patch
You cannot patch what you cannot see, and most organizations have more unknowns than they expect. Pull together whatever sources exist: your vulnerability scanner, EDR telemetry, the CMDB, DHCP logs, switch MAC tables, cloud console listings, and the spreadsheet someone keeps for the finance team's remote laptops.
Scan with credentials wherever possible. Unauthenticated scans will show open ports and banner versions, but they routinely miss the actual patch level of an operating system or application.
- End-of-life operating systems still running because one legacy application depends on them
- Virtual appliances that only the network team knows exist
- Out-of-band management interfaces (iDRAC, iLO, BMC) exposed on internal VLANs
- Printers, NAS devices, and IP cameras with their own web servers
- Cloud instances spun up for a project and never tagged
- Remote worker machines that only appear on the network via VPN
Tag each asset with a business owner and a criticality level while you are in there. That tagging does most of the work for the next phase.
Days 4–7: Score by Exposure, Not by CVSS Alone
A base CVSS score tells you how bad a vulnerability could be in the abstract. It says nothing about whether the affected system is reachable, whether it holds data anyone wants, or whether the vendor already reports exploitation in the wild. If a vendor advisory or a national CERT says a flaw is being actively exploited, treat that as the strongest signal you have and stop arguing about the score.
A simple triage table keeps decisions consistent across teams:
- Internet-facing plus known exploitation: patch or mitigate within 72 hours.
- Internet-facing, no known exploitation: patch within 7 days.
- Internal, privileged access or lateral movement risk: within 14 days.
- Internal, isolated, low-value: fold into the normal monthly cycle.
Record the reasoning for anything you downgrade. That single habit will save you an uncomfortable conversation later.
Days 8–14: Internet-Facing Systems First
This is the wave that matters most. VPN concentrators, edge firewalls, load balancers, mail gateways, web servers, and anything with a login page reachable from the public internet. These are the systems attackers scan continuously and automatically.
Patch the way you would deploy any risky change: snapshot or back up first, pilot on one node if you have redundancy, then roll through the rest inside a defined window. Have a rollback path written down before you start, not after something breaks.
Where patching is impossible in the window, mitigate. Disable the vulnerable feature, restrict access by IP range, apply a virtual patch at the WAF, or require multi-factor authentication on the exposed service. A mitigation is not a fix, so give it an owner and an expiry date. Undated mitigations quietly become permanent architecture.
Days 15–22: Endpoints and Internal Servers
Use deployment rings rather than a single big-bang push. A workable shape: IT and a volunteer pilot group, then five to ten percent of the estate, then everyone. Watch for the failure modes that show up in the pilot — a line-of-business application that breaks, a driver conflict, a reboot that never completes.
Third-party software deserves as much attention as the operating system: browsers, PDF readers, Java runtimes, remote support agents, and backup clients are common entry points and often update on their own schedule. Consolidate them into your patch tool rather than relying on users clicking prompts.
For servers, patch by role. Drain cluster nodes before rebooting, check dependent services and scheduled jobs, and confirm that database failover actually works before you take the primary down. Communicate reboot deadlines to users in advance and stick to them — silent reboots at the wrong moment cost you goodwill you will need next month.
Days 23–27: Network Devices, Firmware, and Appliances
This is where 30-day plans usually slip, because firmware upgrades mean downtime. Back up configurations before every upgrade and verify the vendor's upgrade path — some releases require intermediate versions, and skipping them causes failures that are painful to reverse.
Keep an out-of-band console session open while upgrading anything that provides remote management. If the upgrade breaks the very connection you are using, you will be driving to the office. On switches and routers, work one redundant pair at a time. On wireless controllers, schedule around business hours. On anything without redundancy, accept a short outage and put it in the maintenance calendar.
Days 28–30: Verify, Document, Start Again
Re-scan the estate and compare against your starting baseline. Confirm that mitigations you applied in week two are still in place and that nobody quietly re-enabled a disabled feature. Close out exceptions with a named owner, a business justification, and an expiry date.
Write a short internal note on what would have caught these issues earlier: a faster inventory feed, a better software deployment tool, a test lab for the awkward appliance. Then reset the clock for the next cycle.
Making the Rhythm Sustainable
Thirty-day cycles fail when they become quarterly heroic efforts. Spread the work: run inventory continuously, re-score new critical advisories weekly, and keep the deployment rings warm so patching is routine rather than an event. If your change process cannot survive a weekly cadence, fix the process, not the calendar.
Keep the documentation light enough that people actually maintain it — a single ticketing board or spreadsheet with asset, vulnerability, owner, status, and due date is enough. For regulatory or contractual obligations around patching and breach notification, confirm your specific requirements with qualified counsel rather than relying on a generic framework. The goal is simple: when the next critical CVE arrives, you already know what you own, what is exposed, and what happens next.
Photo: Matheus Bertelli / Pexels