The vulnerability that gets you is already public
The uncomfortable truth about patch management is that the vulnerability most likely to hurt you is not an exotic zero-day. It is the known flaw, publicly documented, with a fix available, sitting unapplied on an internet-facing system. Attackers rarely need original research because disclosure does the work for them. The moment a vendor ships a patch, the patch itself becomes a map: diffing the patched binary against the old one tells an exploit developer exactly where the flaw sits, and working exploit code routinely appears within days of a fix shipping. Every week a patch sits unapplied, the pool of people capable of exploiting it grows and the skill required shrinks.
The ACSC understands this, which is why two of the eight Essential Eight strategies are patching strategies, and why the maturity model puts hard clocks on them: patches for vulnerabilities in internet-facing services applied within two weeks of release, or within 48 hours where a working exploit exists. Those numbers are not aspirational. They reflect how far the window between disclosure and mass exploitation has collapsed.
Yet most organisations that miss those clocks are not lazy. Somewhere in their history, a patch broke production, the outage hurt, and the organisation quietly concluded that stability today beats security tomorrow. That trade only looks sensible while patching is unmanaged risk. The whole discipline of patch management exists to make it managed risk, and a managed risk you can take quickly. What follows is the system that does it.
Prioritise by exposure and exploitability, not CVSS alone
Ranking patches purely by CVSS base score is the most common triage mistake. The base score measures theoretical severity in a vacuum, not risk to your environment. A 9.8 on a server reachable only from an isolated management network is less urgent than a 7.5 on your VPN concentrator with proof-of-concept code circulating on GitHub. Chasing the biggest number first feels rigorous and often patches the wrong thing.
Three questions do most of the triage work: whether the vulnerable service is reachable from the internet or by low-trust users; whether there is evidence of exploitation, meaning an entry in CISA's Known Exploited Vulnerabilities catalogue, published exploit code, or vendor advisory language noting attacks in the wild; and what the system holds or touches, whether that is customer personal information, identity infrastructure, or a single point of failure. Honest answers to those three sort almost any patch queue correctly, and a simple tiering falls out of them.
None of it works without visibility. You cannot triage a vulnerability on a system you do not know you own, so an accurate asset inventory and a vulnerability scanner running daily against internet-facing services are preconditions, not nice-to-haves. The Essential Eight maturity model expects exactly that scanning discipline.
- Emergency: internet-facing and an exploit exists. Treat it as a 48-hour incident, with compensating controls at the edge if the patch cannot land in time.
- Urgent: internet-facing, or being exploited elsewhere without a confirmed path to your exposure. Patch within the fortnightly window the Essential Eight expects.
- Routine: everything else rides the standing monthly cycle without individual deliberation.
Stage the rollout: rings, canaries and soak time
Never patch the whole fleet at once. Structure deployment as rings: a test ring of representative but non-critical systems, a pilot ring of real users plus one node of each production cluster, then broad deployment, with the most sensitive systems held to the final ring where they inherit the accumulated evidence of everything before them. Each ring exists to buy observation time cheaply. A driver conflict discovered on twelve pilot workstations is an inconvenience; the same conflict discovered on four hundred is an outage.
Soak time should be proportional to blast radius and inversely proportional to reversibility. Workstation patches can move from pilot to broad in a day or two, because a broken workstation is recoverable and users report symptoms fast. Hypervisors, database servers and domain controllers earn a full business cycle of observation, including at least one backup window and one peak-load period, before the next ring proceeds. Clustered services give you canaries for free: drain one node, patch it, return it to load, and watch error rates and latency before touching its siblings.
The 48-hour emergency clock compresses soak time to nearly nothing, and that is precisely when compensating controls carry the weight. If an internet-facing service cannot be patched safely inside the window, shrink its exposure instead: restrict it at the edge to known addresses, disable the vulnerable component, or take it offline until the patch has soaked in a lower ring. Reducing exposure is a legitimate control, not an admission of failure.
Rollback is a tested path, not a hope
A real rollback plan has three parts: a restore mechanism you have actually exercised, a decision trigger, and a named decision maker. Most organisations have only the first, untested. The trigger matters more than people expect. Agree in advance what symptom, observed by whom, within what window, causes the rollback. Without that, a degraded service limps along for hours while the team debates whether things are bad enough, which is the worst of both worlds.
Just as important is knowing where rollback genuinely does not exist. Firmware that refuses to downgrade. Patches that migrate a database schema forward. Cumulative updates that supersede everything before them. Identity infrastructure is the sharpest case: restoring a domain controller from a snapshot invites update-sequence corruption in Active Directory replication, so treat domain controllers as forward-only and compensate with longer soak in earlier rings. For forward-only systems the plan is roll-forward: spare capacity, a known vendor escalation path, and mitigations you can apply while a hotfix is produced.
Application dependencies deserve the same discipline as operating systems and usually get less. Lockfiles pin exact versions so a patch is a deliberate diff rather than a surprise. An artifact repository keeps the previous package available after the public registry moves on. Container images are rebuilt and redeployed rather than patched in place, which turns rollback into redeploying the previous tag. That is one of the quiet arguments for containerised workloads: the patch becomes a CI rebuild, and the escape hatch is one command.
Maintenance windows that actually hold
Standing, pre-agreed maintenance windows beat per-change negotiation every time. A monthly cadence aligned to vendor release rhythms, Microsoft's monthly cycle being the obvious anchor for most Australian estates, gives the business predictability and the team a drumbeat. Size the window for verification, not just installation: install time, then smoke tests against the services that matter, then margin to execute the rollback if the trigger fires. A window that only fits the install is a window that guarantees you will overrun it.
Define the out-of-band path before you need it: who can call an emergency window, on what notice, with what approval. When a 48-hour clock starts on a Friday afternoon, the last thing you want to be doing over the weekend is inventing governance. The emergency path should be documented, rehearsed at least once, and boring.
Cloud changes the shape of the work without removing it. Platform services shift operating system patching to the provider, though your application dependencies remain entirely yours. Azure Update Manager can enforce schedules and report compliance across a VM fleet, and availability zones let you patch a tier without taking it down. The deeper shift is architectural: the more of your estate you can rebuild from images and templates, the less you are patching anything in place at two in the morning.
Make patching boring
The goal state is a patch process so routine it is dull. The low-risk majority of patches flows through the rings automatically with no human deliberation, and human attention is spent on the exceptions: the emergency clock, the forward-only system, the patch that touches identity. Two measurements tell you whether you are there: elapsed time from patch release to full deployment for each tier, and the count of systems sitting outside any patch process at all. The second number is usually the honest one.
When we run Essential Eight assessments, the two patching strategies are consistently where the gap between how an organisation believes it operates and what the scanner evidence shows is widest. The fix is almost never more urgency. It is the system above: triage by exposure and exploitability, rings with proportionate soak, rollback as a tested path with a named owner, and standing windows that make the whole thing routine.
The unpatched known vulnerability is the attacker's cheapest way in and your cheapest problem to fix. Build a patch process you trust, and the 48-hour clock stops being frightening, because moving fast is simply what the system does.