.png)
What is Patch Management?
Patch management fixes known security vulnerabilities before attackers exploit them. Learn the process, prioritization frameworks, and what boards should require from security teams.
What Patch Management Actually Involves
Patch management covers software of every type: operating systems (Windows, Linux, macOS), applications (browsers, productivity suites, custom enterprise software), firmware (routers, switches, printers, IoT devices), and cloud infrastructure components. The scope is broader than most organizations initially account for, and the devices that most commonly host unpatched vulnerabilities are often the ones farthest from central IT visibility — network devices, printers, industrial control systems, and employee-managed endpoints.
The patch management cycle has four phases. Discovery: maintaining a current inventory of all software assets across the environment — the prerequisite to knowing what needs to be patched. Assessment: evaluating patches for applicability, criticality, and potential business impact before deployment. Testing: validating patches in non-production environments to identify compatibility issues before broad deployment. Deployment: rolling out patches in a controlled sequence with rollback capability if issues emerge.
Each phase is an opportunity for failure, and each failure extends the window of vulnerability. Organizations that do not maintain accurate software inventories cannot assess patch applicability. Organizations that skip testing deploy patches that break production systems — which leads to delayed patching in the future. Organizations that lack rollback capability cannot recover quickly from failed patches.
Why Most Organizations Fail at Patch Management
The operational reality is that patching is disruptive. Patches require testing, require change management approval, require deployment windows that do not impact business operations, and occasionally break things. The organizational incentive structure works against timely patching: the person responsible for patching is accountable for the disruption it causes but not for the breach that occurs months later when an unpatched vulnerability is exploited. The consequence of delay is invisible until it is not.
The IBM Cost of a Data Breach Report consistently finds that known, patchable vulnerabilities account for a significant percentage of breach entry points. Equifax was breached through CVE-2017-5638, an Apache Struts vulnerability for which a patch was available 78 days before the breach. The patch was not applied. 147 million records were exposed. The breach cost Equifax over $700 million in settlement costs. The patch was free.
Mean time to patch — the average time between a vulnerability patch release and its deployment across an environment — is the primary patch management metric. Industry benchmarks suggest critical vulnerabilities should be patched within 15 days of release. Most mid-market organizations operate with mean times to patch measured in months, not days.
Vulnerability Prioritization: Not All Patches Are Equal
The volume of patches released by major software vendors makes universal rapid patching operationally impossible. Microsoft releases patches monthly (Patch Tuesday). Adobe, Google, Apple, Linux distributions, and thousands of enterprise software vendors release patches on their own schedules. An organization managing hundreds of endpoints may face thousands of patch releases per year. Prioritization is not optional — it is the core of a mature patch management program.
CVSSv3 (Common Vulnerability Scoring System) scores are the standard prioritization input, ranging from 0 to 10. Critical vulnerabilities (9.0-10.0) represent the highest priority — these are vulnerabilities that can be remotely exploited without authentication, often with significant impact. High vulnerabilities (7.0-8.9) require near-term attention. Medium and low vulnerabilities can be batched into standard patch cycles.
Exposure-based prioritization goes beyond CVSS. A critical vulnerability in software that is not internet-facing, not present on privileged systems, and not part of the production environment may represent lower actual risk than a high-severity vulnerability in an internet-facing web server. Risk-based patching considers CVSS score, internet exposure, asset criticality, and the presence of public exploit code — because a vulnerability with a public exploit available represents materially higher risk than the same vulnerability without one.
CISA's Known Exploited Vulnerabilities (KEV) catalog is the most directly actionable prioritization input available. The KEV catalog lists vulnerabilities that CISA has confirmed are being actively exploited in the wild. Any vulnerability on the KEV list that exists in your environment is a critical remediation priority regardless of CVSS score — because it is not theoretical. Attackers are using it right now.
Patch Management for PE Due Diligence
For PE due diligence, patch management posture is one of the most reliable indicators of operational security program maturity. The questions that matter are: What is the organization's mean time to patch for critical vulnerabilities? Does the organization have a current software asset inventory? Is vulnerability scanning conducted regularly, and are findings tracked to remediation? Are network device firmware updates covered by the patch management program?
Organizations without a documented patch management process — or with patching cycles measured in months for critical vulnerabilities — have a structurally exploitable attack surface. The due diligence finding is not 'they should patch faster' — it is 'this organization has known, exploitable vulnerabilities that are likely present in their environment and may have been present for months or years.'
Automated Patch Management and Its Limits
Modern patch management platforms — Microsoft WSUS, SCCM, Intune, Automox, Tanium, and similar tools — automate significant portions of the patch lifecycle: patch discovery, testing in ring deployments, scheduled deployment, and compliance reporting. Automation addresses the volume problem. It does not address the inventory problem — automated patching only covers devices enrolled in the management system — or the prioritization problem, which still requires human judgment about risk and business impact.
The most dangerous unpatched systems in most environments are not managed endpoints. They are network infrastructure (routers, switches, firewalls), industrial control systems, legacy on-premises servers that cannot be easily rebooted during business hours, and the shadow IT devices that IT does not know exist. Comprehensive patch management requires visibility into all asset categories, not just managed workstations and servers.
Related Reading
Equifax: The $700 Million Unpatched Vulnerability
In March 2017, the Apache Software Foundation disclosed CVE-2017-5638, a critical vulnerability in Apache Struts — a web application framework used by many large organizations including Equifax. A patch was available on the day of disclosure. Equifax's security team received notification of the vulnerability and the available patch. The patch was not applied to all affected systems. On May 13, 2017 — 78 days after the patch was available — attackers began exploiting the unpatched vulnerability in an Equifax web application portal. They maintained access for 78 days, exfiltrating the personal data of 147 million Americans. The settlement costs exceeded $700 million. The congressional testimony was humiliating. The patch was free. The lesson is not that Equifax had a vulnerability — every organization has vulnerabilities. The lesson is that the patch existed, was not applied, and an attacker found the unpatched system before Equifax found the time to apply the fix.
of breaches involved a known vulnerability that had not been patched, according to Ponemon Institute research. The patch was available. The attacker used it anyway. Patch management is the control that most directly closes the exploitable gap between known vulnerability and active exploitation.