Skip to main content

Patch Management

Canonical runbook. Audience-neutral. Referenced by the Operational pages for MSPs and Internal IT Teams.

Unpatched systems are the most common way attackers get in. Patching isn't a heroic event; it's a cadence — a repeatable rhythm with clear timeframes, testing to avoid self-inflicted outages, and evidence you can show a client, an auditor, or an insurer.

Prioritise by risk, not by date alone​

Not all patches are equal. Prioritise by exploitability and exposure:

  • Critical / actively exploited vulnerabilities on internet-facing systems are the top priority — these are what get organisations breached.
  • Internet-facing services and applications generally take precedence over internal- only systems.
  • Severity ratings (CVSS) inform but don't dictate priority; a "high" being actively exploited in the wild outranks a "critical" that isn't.

Target timeframes​

Current ASD guidance (the Essential Eight, now transitioning to the ASD Essentials series) sets defensible benchmarks. As a baseline aligned to its higher maturity levels:

  • Internet-facing services: patch critical vulnerabilities within 48 hours of a patch (or mitigation) being available.
  • Operating systems and applications on workstations/servers: patch within two weeks, or 48 hours where the vulnerability is being actively exploited.
  • Replace unsupported (end-of-life) software that no longer receives security updates — an unpatchable system is a permanent open door.

Set your own committed timeframes against these and hold to them; the point is a defensible, documented cadence, not perfection.

Testing rings​

Patching that breaks production is its own kind of incident. Stage deployments through rings so problems surface on a small population first:

  1. Pilot ring — IT and a small set of tolerant users. Catch breakage here.
  2. Broad ring — the general population, once the pilot is clean.
  3. Critical/sensitive systems — last, with a tested rollback path.

For an MSP this maps onto tenant tiers; for an internal team, onto device groups. Either way, never deploy a patch everywhere at once.

Evidence and reporting​

A patch cycle isn't done until it's evidenced. Capture and retain:

  • Compliance percentage — proportion of devices/servers up to date against your target timeframe.
  • Exceptions — what's unpatched, why, and the compensating control or remediation plan.
  • Trend over time — so you can show posture is maintained, not just occasionally achieved.

This evidence is what turns "we patch regularly" into something a board, an auditor, or an insurer can actually rely on.

Mapping​

This runbook implements Essential Eight: Patch applications and Patch operating systems — two of the eight mitigation strategies. See the Essential Eight Baseline for how it fits the wider model, and for the Essential Eight's retirement and replacement by ASD's Essentials series. Patching cadence is expected to carry across largely unchanged.