Patch management is the structured process of identifying, testing, deploying, and verifying software updates (patches) across an organisation's IT estate — operating systems, applications, network devices, firmware, containers, cloud workloads. The goal is to close known security vulnerabilities and fix bugs before attackers can exploit them. Patch management is one of the highest-impact security controls — most ransomware campaigns exploit vulnerabilities that have been publicly known and patched for months or years. Mature programmes patch critical CVEs within 24-72 hours; immature ones take weeks or never patch at all.

Six phases: (1) **Discovery and inventory** — know what assets you have (servers, workstations, network devices, cloud workloads); incomplete CMDB is the biggest patching blocker, (2) **Vulnerability assessment** — scan for missing patches and prioritise (most environments have thousands of missing patches), (3) **Risk-based prioritisation** — combine CVSS, EPSS (exploitation probability), CISA KEV (known exploited), and asset criticality, (4) **Test** — validate critical patches in a staging environment first, (5) **Deploy** — push patches via automation tools (Intune, SCCM, Ansible, BigFix, AWS Systems Manager) following maintenance windows, (6) **Verify** — confirm patches applied successfully, document compliance. Iterate continuously.

Choose based on environment: (1) **Microsoft estates** — Microsoft Intune (cloud, modern), SCCM/Configuration Manager (on-prem), Windows Server Update Services (WSUS) for legacy, (2) **Linux estates** — Ansible, Puppet, Chef, Red Hat Satellite, native package managers (yum, apt, dnf), (3) **Heterogeneous enterprise** — IBM BigFix, Tanium, ManageEngine Patch Manager Plus, (4) **Cloud-native** — AWS Systems Manager Patch Manager, Azure Update Manager, GCP OS Config, (5) **Endpoint-focused** — Automox, NinjaOne, Action1, ConnectWise Automate, (6) **Container/Kubernetes** — Trivy, Aqua, Sysdig, Snyk for image scanning + GitOps for redeployment. Cyber insurance carriers in 2026 increasingly require demonstrable patch automation.

Modern prioritisation uses three risk factors beyond raw CVSS: (1) **CVSS** — base technical severity (0-10), useful but coarse; many CVSS 9-10 are never exploited, (2) **EPSS (Exploit Prediction Scoring System)** — probability of exploitation in next 30 days from FIRST.org; CVSS 7.5 with EPSS 90% is more urgent than CVSS 9.8 with EPSS 0.01%, (3) **CISA KEV (Known Exploited Vulnerabilities)** — confirmed exploitation in the wild; treat all KEV entries as P0. Add business context: asset criticality (production database vs dev workstation), internet exposure, data sensitivity, compensating controls (WAF, EDR). Tools: Tenable, Qualys, Rapid7 InsightVM, Wiz, ServiceNow Vulnerability Response provide combined scoring.

Common risk-based SLAs (2026 best practice): (1) **Critical CVE on KEV or with active exploitation** — patch within 24-72 hours (some organisations patch in 8 hours), (2) **High severity with high EPSS** — within 7 days, (3) **High/Medium severity** — within 30 days, (4) **Low severity** — quarterly cycle. NIS2 and DORA do not specify exact patch SLAs but require timely vulnerability remediation as part of risk management. Cyber insurance carriers often require 30-day SLA for high-severity. Document SLAs in policy, measure compliance via SIEM/vulnerability dashboards, and report to the board quarterly. Exception process for systems that genuinely can't be patched (legacy OT, vendor lock-in) — must include compensating controls.

Six common blockers: (1) **Incomplete inventory** — you can't patch what you don't know about; CMDB drift is universal, (2) **Coordination friction** — application owners refuse maintenance windows, change advisory boards slow approvals, (3) **Compatibility risk** — patches sometimes break applications, especially legacy ones; this drives over-cautious testing, (4) **Patch fatigue** — Patch Tuesday brings dozens of updates; teams burn out, (5) **End-of-life software** — vendors stop releasing patches; legacy Windows Server 2012, Java 8, etc. (6) **Air-gapped or OT environments** — limited or no internet connectivity, vendor approval cycles measured in months. Solutions: automation, treating patching as continuous operations rather than periodic projects, separating risk-based emergency patching from routine cycles.

Patch management is a *subset* of vulnerability management. **Vulnerability management** is the broader risk-driven lifecycle: discovery, prioritisation, *all* remediation paths (patching, configuration changes, compensating controls, accepting risk), and verification. **Patch management** is the operational discipline of deploying vendor patches across the estate. Many organisations have mature patch management but immature vulnerability management — they apply what vendors release but lack risk-based prioritisation, coverage of zero-days, configuration weaknesses, or architectural gaps. Modern programmes combine both: vulnerability scanners feed patch SLAs, exception process handles non-patchable issues, dashboards report on residual risk.