Patch Management

Patch management is the organizational practice of identifying, acquiring, testing, and deploying software updates to remediate known vulnerabilities. Effective patch management is consistently cited as one of the highest-impact controls for preventing ransomware and data breaches. It is one of Black Kite's 20 technical assessment categories and one of the most heavily weighted, as unpatched systems are a primary ransomware and breach entry vector.

What Does a Patch Management Process Include?

Patch management is the cycle of finding available software fixes, deciding which ones matter, testing them, deploying them, and confirming they took effect.

A working process covers five stages:

Inventory, knowing which software and versions run where, since nobody can patch what they don't know they have.
Monitoring, tracking vendor advisories and vulnerability disclosures that apply to that inventory.
Prioritization, deciding which fixes go first based on exploitation risk and business impact.
Testing and deployment, rolling fixes out without breaking the systems they're meant to protect.
Verification, confirming the patch applied and the vulnerable version is actually gone.

Black Kite's blog covers how patch management affects cyber risk in more detail.

How Should Patches Be Prioritized When There Are Thousands?

Severity scores can't sort a patch queue on their own, because only a small share of published vulnerabilities are ever exploited. Black Kite's 2026 Supply Chain Vulnerability Report found that of more than 48,000 CVEs published in 2025, approximately 800 were exploited in the wild. Three signals give a fuller picture together:

CVSS, which rates a vulnerability's technical severity.
EPSS, which estimates the probability that a flaw will be exploited within the next 30 days.
KEV status, meaning a listing in the CISA KEV catalog, which records reliable evidence of exploitation in the wild.

Exploitation Evidence Outranks Severity Scores

The same report recommends that third-party risk programs use EPSS predictions and CISA KEV data as the primary triage layer, replacing CVSS as the default sort. Its reasoning starts with discoverability. A vulnerability that can't be found from outside a vendor's network isn't exploited at scale across a supply chain.

Why Can't You Patch Your Vendors' Systems?

Patch management assumes you own the system, and third-party risk is the part of your environment where that assumption breaks. When a vendor runs a vulnerable server that holds your data, only the vendor can apply the fix. Your role shifts from doing the patching to knowing whether it happened, and how long it took.

Black Kite's 2026 Third-Party Breach Report found that 53.77% of the roughly 200,000 organizations it monitors show at least one critical vulnerability. The report describes that monitored population as the global vendor ecosystem.

Smaller Vendors Patch on a Slower Clock

The gap between large and small vendors is measured in months. The 2026 Supply Chain Vulnerability Report found that mid-market vendors, small software publishers, and open-source maintainers average 197 days to detect a vulnerability and 60 days to remediate it. Large enterprises using AI-powered vulnerability scanning average 14 and 21 days. The report also describes threat actors shifting focus toward those smaller suppliers as enterprise perimeters harden.

A zero-day adds one more wrinkle. Until the software maker ships a fix, there's nothing for any vendor to deploy, and the response depends on compensating controls instead of patches.

What Patch Timelines Should You Expect From a Vendor?

Public benchmarks give risk teams a reference point for vendor patch expectations. CISA’s Binding Operational Directive 26-04, issued in June 2026 to replace BOD 22-01, sets federal remediation deadlines by risk rather than a single clock. Deadlines can be as short as three days for publicly exposed systems with actively exploited vulnerabilities. PCI DSS v4.0.1 requires patches for critical vulnerabilities to be installed within one month of release, with other patches installed on a timeframe the organization defines.

BOD 26-04 binds federal civilian agencies, and PCI DSS covers the systems in its scope. For other vendor relationships, the expectation belongs in the contract. A clause that sets remediation windows by severity, requires notice when a window can't be met, and defines what counts as a compensating control gives both sides something concrete to measure against.

How Do You Tell Whether a Vendor Patches on Time?

You tell by watching what a vendor exposes from the outside over time, because a questionnaire answer confirms that a policy exists and external evidence shows how it's working. Black Kite’s approach to vendor compliance rests on the same principle, cross-checking vendor claims against independent, externally observed evidence. These signals are worth tracking:

Exposed software versions, where a public-facing service reports a version with known vulnerabilities.
Time to close known exploited flaws, especially new additions to the KEV catalog.
End-of-life software, since products past end of life no longer receive security updates from their maker.
The trend over time, since a single scan captures only one moment.

This is the difference between a point-in-time vulnerability assessment and continuous monitoring. With continuous monitoring, a change in a vendor's risk profile surfaces when it happens instead of at the next quarterly assessment.

Where Does Patch Management Break Down?

Some software can't be patched at all, and outside-in data has limits of its own. Both affect how far a vendor patch program can reach.

End-of-Life Software Has No Patch to Apply

Once a product reaches end of life, its maker stops issuing security updates. The remaining options are replacing the product or limiting its exposure, and either one belongs in a documented remediation plan with an owner and a date.

Outside-In Data Sees Exposed Systems, Not Internal Ones

Black Kite's monitoring draws on externally observable data, including IP addresses, subdomains, service fingerprints, SSL certificates, and DNS records. Internal systems that aren't exposed to the internet sit outside that view, so an exposure finding starts a conversation with the vendor about what's running inside.

How Does Black Kite Weigh Patching in a Vendor's Rating?

Patch management carries more weight than any other category in Black Kite's cyber rating, at 10 of 100 points across 19 categories. Black Kite's risk management methodology is standards-based and transparent, built so users know exactly how their findings are calculated.

For third-party software, product-level software risk analysis rates individual third-party software products, on-premises or SaaS, on CVEs, exploits, certifications, and end-of-life status. Black Kite's Investigation Agent investigates findings, validates exposures, checks patch status, and triggers rescans. The cyber risk intelligence knowledge center collects Black Kite's related resources.