What Does Patch Management Do
Patch management identifies, prioritises, tests, and deploys software updates across an organisation's entire IT estate then verifies compliance and monitors continuously for new threats.
That is the direct answer. But the gap between that definition and a well-functioning enterprise programme is where most organisations lose ground. The term 'patch management' is used to describe everything from an IT administrator manually applying Windows updates on a Tuesday afternoon, to a fully automated, intelligence-driven remediation workflow protecting 10,000 endpoints in real time. The functions are the same. The capability gap between them is enormous.
This guide explains the seven distinct functions that patch management performs in a complete programme, what each function delivers, what patch management does not do, and how to assess whether your current programme is actually performing all seven.
The Seven Core Functions of Patch Management
Function 1: Asset Discovery and Inventory
Patch management begins by identifying every device, operating system, application, and firmware version present in your environment. This covers on-premises servers and endpoints, cloud workloads, network devices, remote and hybrid worker endpoints, IoT devices, third-party applications, and legacy systems.
Organisations consistently underestimate the scope of their own estate. One organisation discovered 847 applications where they expected approximately 300. Another found 47 end-of-life applications across recently acquired tenants three with active exploits at the time of discovery. You cannot patch what you cannot see, and incomplete asset visibility means incomplete protection by definition.
Advanced discovery tools complete comprehensive patch management inventory within one day. Manual methods take months and leave gaps. Asset discovery is not a one-time exercise it is a continuous function that updates as the estate changes.
Function 2: Vulnerability Scanning and Missing Patch Detection
Once the estate is mapped, patch management continuously monitors for patches and updates released by vendors, cross-referencing installed versions against current release data to identify what is missing.
A complete patch management process goes further: it integrates vulnerability intelligence to cross-reference missing patches against known CVEs, CVSS severity scores, and active exploitation databases. This transforms the question from 'what patches are missing?' to 'which missing patches represent genuine, active risk right now?' The distinction determines whether limited IT resource is directed at real threats or vendor-generated noise.
Function 3: Risk-Based Patch Prioritisation
Patch management determines which patches to deploy first and how urgently. Effective prioritisation combines:
• CVSS severity scores — technical baseline assessment
• Active exploitation intelligence — is this vulnerability being attacked in the wild right now?
• Business criticality — how important is the affected system to operations, revenue, or patient safety?
• Compensating controls — what protections already reduce the effective risk?
Without this function, teams face an impossible choice: attempt to address 200 'critical' patches simultaneously (and achieve little), or default to arbitrary prioritisation that leaves the most dangerous vulnerabilities unaddressed. Risk-based prioritisation resolves this by separating the genuinely urgent from the merely labelled urgent.
Function 4: Pre-Deployment Testing
Patch management validates every patch against your specific environment before it reaches production. Automated test environments that replicate production configuration catch compatibility conflicts, application dependency breaks, and performance regressions before they affect end users.
This function is what separates confident, consistent patching from the 'patch roulette' that causes operational disruptions. The most common reason organisations delay or avoid patching is fear of disruption a rational response to past experiences of patches breaking critical applications. Pre-deployment testing, combined with system snapshots enabling one-click rollback, eliminates this fear by providing a known safety net for every deployment.
Function 5: Controlled Deployment Across the Estate
Patch management orchestrates the deployment of validated patches to managed devices. This includes:
• Scheduling deployments to minimise business disruption
• Phased rollouts: pilot groups (5-10% of estate) → canary deployments → full estate
• Exception management: handling systems that require deferrals or alternative compensating controls
• Rollback execution: rapid restoration if issues emerge post-deployment
Deployment scope is a critical distinction. Effective patch management covers the complete attack surface: operating systems, applications, firmware, browsers, third-party software, cloud workloads, and remote endpoints. Programmes that patch only OS updates leave browsers, PDF readers, media players, and productivity applications all actively targeted by attackers consistently unaddressed.
Function 6: Compliance Verification and Reporting
After deployment, patch management confirms that patches were successfully applied and maintains an auditable record of compliance status. Real-time dashboards show patch status by device, criticality level, compliance framework (GDPR, ISO 27001, NIST 800-53, SOC 2, PCI DSS, HIPAA, Cyber Essentials), and business unit.
This function transforms patch management compliance from a periodic, resource-intensive exercise into continuous automated governance. Manual compliance evidence gathering exporting reports, correlating data across tools, preparing audit packs produces evidence that is out of date before it is reviewed and consumes significant IT resource. Automated compliance dashboards make audit-ready evidence continuously available, on demand.
One CISO discovered 47 end-of-life applications during a systematic compliance review, three with active exploits and avoided £4.2 million in potential GDPR fines through proactive remediation.
Function 7: Continuous Monitoring and Zero-Day Response
Patch management is not a periodic task it is a continuous cycle. New vulnerabilities are disclosed daily. Threat actors scan for unpatched systems within hours of public disclosure. The average time between CVE disclosure and active exploitation is now 15 days making weekly or monthly patch cycles structurally insufficient for critical vulnerabilities.
Modern automated patch management maintains continuous monitoring with emergency response protocols for zero-day events: pre-defined deployment authority, pre-approved testing waivers for emergency scenarios, and phased deployment capabilities that enable organisations to protect critical systems within hours of a disclosure. Organisations with these protocols reduce zero-day response time from 8-12 days to under 4 hours before the exploitation window opens.
What Patch Management Does NOT Do
Understanding scope boundaries is as important as understanding capabilities.
Patch management does not replace vulnerability management. Vulnerability management includes vulnerability scanning, risk assessment, and tracking remediation across multiple control types not just patching. Some vulnerabilities require configuration changes, access controls, or network segmentation rather than patches. (→ See Blog 2: The Difference Between Patch Management and Vulnerability Management for the full framework.)
Patch management does not address non-patch vulnerabilities. Misconfigurations, weak or default credentials, excessive user permissions, and insecure network configurations are outside patch management's scope. These require separate controls.
Patch management cannot protect against zero-days with no available patch. When a vulnerability is disclosed before a vendor patch is available, compensating controls network segmentation, access restrictions, enhanced monitoring are required whilst awaiting the patch.
OT and IoT patching requires additional consideration. Some operational technology and industrial control systems cannot be taken offline for patching without significant operational impact. OT patching requires vendor coordination, extended maintenance windows, and compensating controls that fall outside standard IT patch management workflows.

Comments
Post a Comment