Patch Management: From Discovery to Deployment

In May 2023, the Cl0p ransomware group exploited CVE-2023-34362 in MOVEit Transfer as a zero-day -- mass exploitation began days before the patch existed, and the window to deploy the May 31 fix before the campaign widened was measured in hours. Over 2,500 organizations were compromised. Not because they lacked a patch management program -- most had one. Because their program could not execute at the speed the threat demanded.

Patch management is not "install updates." It is the operational discipline that translates vulnerability detection into vulnerability elimination -- and the speed at which your program executes is now the difference between a finding on your POA&M and an incident on your breach disclosure.

Why This Matters Now

The patching window -- time between patch availability and mass exploitation -- is collapsing. Historical norms gave defenders weeks or months. Current reality gives days, sometimes hours:

CVE-2021-44228 (Log4Shell): patch available December 10, 2021. Mass exploitation within 24 hours.
CVE-2023-4966 (Citrix Bleed): patch available October 10, 2023. Active exploitation confirmed by October 30.
CVE-2024-21762 (FortiOS): advisory published February 8, 2024. CISA confirmed exploitation February 9.
CVE-2023-34362 (MOVEit): exploited as a zero-day from May 27, 2023. Patch available May 31 -- after mass exploitation was already underway.

CISA BOD 26-04 acknowledges this reality by shifting from calendar-based remediation (30/90/180 days) to risk-based timelines driven by exploitation evidence. If a vulnerability is actively exploited, the remediation timeline is not 30 days -- it is now.

This means your patch management program must support two operational modes: the structured lifecycle for the 95% of patches that can flow through change management, and the emergency bypass for the 5% that cannot wait.

The Patch Management Lifecycle

Phase 1: Discovery

You cannot patch what you do not know is vulnerable. Discovery feeds come from:

Vulnerability scan results -- your primary detection source, identifying missing patches across infrastructure
Vendor security advisories -- Microsoft Patch Tuesday, Fortinet PSIRT, Cisco Security Advisories, Red Hat Errata
CISA KEV additions -- confirmed exploitation, requiring immediate attention regardless of scan cadence
CVE monitoring -- new disclosures affecting software in your asset inventory
Operating system update channels -- Windows Update, yum/apt security repos, macOS software updates

The failure mode here is fragmentation. If scan results live in one console, vendor advisories arrive by email, and CISA KEV notifications come through an RSS feed, the correlation burden falls on a human analyst. That analyst will miss things.

Phase 2: Prioritization

Not every patch deploys with the same urgency. The prioritization decision considers:

Exploitation status -- Is this vulnerability being actively exploited? CISA KEV status is binary: yes means immediate priority. EPSS score provides probability: above 0.7 means high likelihood of exploitation within 30 days.

Severity -- CVSS score provides the baseline. But CVSS alone is misleading. A CVSS 9.8 vulnerability in a test lab matters less than a CVSS 7.5 in your internet-facing production database.

Asset criticality -- What is the business impact if this system is compromised? Systems handling CUI, payment data, or authentication infrastructure receive higher priority.

Network exposure -- Internet-facing assets face the broadest threat actor population. Internal-only assets require authenticated access, reducing (but not eliminating) exploitation probability.

Compensating controls -- Does a WAF rule, network segmentation policy, or EDR capability reduce exploitability while you test and deploy the patch?

Here is the contrarian position: organizations that prioritize purely by CVSS are patching the wrong things first. A CVSS 9.0 remote code execution vulnerability with an EPSS of 0.02 (2% exploitation probability) and no known exploit is less operationally urgent than a CVSS 7.5 with an EPSS of 0.85 that CISA just added to KEV. Severity is not urgency. Exploitation evidence is urgency.

Phase 3: Testing

Deploying patches directly to production without testing is a gamble. Patches occasionally break functionality -- vendor QA cannot test every application combination that exists in your environment:

Test environment requirements:

Mirror production configurations (same OS versions, same middleware, same application stack)
Include application-level regression testing (not just "does the system boot")
Test patch interactions (multiple patches applied simultaneously may conflict)
Validate rollback procedures before you need them in production

Testing cadence tradeoffs:

Critical/KEV patches: abbreviated testing (hours, not days). The risk of exploitation outweighs the risk of a patch-induced regression.
High patches: standard testing cycle (1-3 days for most organizations)
Medium/Low patches: bundled into regular maintenance windows with full regression

When testing is not feasible: some environments lack adequate test infrastructure. In those cases, deploy to a subset of production systems first (canary deployment), monitor for issues, then expand. Document the risk acceptance for audit.

Phase 4: Deployment

Deployment is where change management discipline meets security urgency:

Change management integration:

Standard patches flow through your CAB (Change Advisory Board) or equivalent approval process
Emergency patches use a pre-approved emergency change process -- one that exists before the emergency, not one improvised during it
Document the change ticket, approval authority, deployment window, and rollback plan

Deployment patterns:

Phased rollout -- deploy to 10% of systems, monitor 4 hours, expand to 50%, monitor, then 100%
Maintenance window -- scheduled downtime for patches requiring reboots (decreasing relevance with container and serverless workloads)
Rolling deployment -- patch servers one at a time behind a load balancer, zero-downtime for the service
Image rebuild -- for containerized workloads, rebuild the image with updated packages and redeploy

Automation at scale:

Configuration management tools (Ansible, SCCM, Puppet) deploy OS patches across thousands of endpoints
Container orchestration handles image-based patching natively (new image, rolling restart)
Cloud infrastructure patching may require managed service upgrades (RDS engine versions, managed Kubernetes node updates)

Phase 5: Verification

A patch deployed is not a vulnerability remediated until verification confirms it:

Re-scan -- run a targeted vulnerability scan against patched systems. The finding should disappear. If it persists, the patch failed to apply, was overwritten, or the scanner plugin requires additional conditions.

Version confirmation -- independently verify the patched version is running (package manager query, file version check, API response header).

Functional validation -- confirm the system and its applications operate correctly post-patch. Regression introduced by patches is a real operational risk.

Compliance evidence -- the scan-before and scan-after pair, combined with the change ticket and deployment record, constitutes auditable evidence that the vulnerability was identified, prioritized, remediated, and verified within the required timeline.

POA&M closure -- if the vulnerability was tracked in a Plan of Action and Milestones, verification triggers closure with the evidence attached.

Compliance Framework Remediation Timelines

Every major framework defines remediation SLAs by severity. These are maximums, not targets:

Framework	Critical	High	Medium	Low
FedRAMP	30 days	30 days	90 days	180 days
PCI DSS v4.0	Immediate/30 days	30 days	90 days	Quarterly
CISA BOD 22-01 (KEV)	By specified due date	--	--	--
CISA BOD 26-04	Risk-based (exploitation-driven)	Risk-based	Risk-based	Risk-based
NIST 800-171	Organization-defined	Org-defined	Org-defined	Org-defined
CMMC Level 2	Per 800-171 policy	Per policy	Per policy	Per policy
Best practice	48-72 hours	7-14 days	30 days	90 days

Note that CISA BOD 26-04 eliminates fixed timelines in favor of risk-based urgency. A KEV-listed vulnerability with active exploitation effectively has a "now" deadline regardless of CVSS band.

Common Failure Modes

The Scan-to-Patch Gap

Organizations that scan monthly but patch quarterly have a structural gap where known vulnerabilities sit unaddressed. The scan detected it. Everyone knows it exists. But the patch deployment does not happen for 60+ more days because "the next maintenance window is in March." During that gap, exploitation probability increases daily.

Fix: decouple scan cadence from patch cadence. Scan frequently, prioritize continuously, deploy patches as risk dictates -- not as the calendar permits.

Legacy Systems

End-of-life software that cannot receive patches is a permanent POA&M entry:

Preferred: upgrade to a supported version (the only real fix)
Compensating: network isolation, enhanced monitoring, virtual patching via WAF/IPS rules
Documented: formal risk acceptance with executive signature, timeline for migration

Third-Party Application Sprawl

The operating system and infrastructure are the easy part. The hard part is 400 third-party applications across 3,000 endpoints where each vendor has its own update mechanism, cadence, and installer format.

Fix: centralized application inventory (you cannot patch what you do not know you have), automated deployment tooling, and contractual requirements for vendors to publish CVEs and patches through standard channels.

The Emergency Bypass That Never Returns to Standard

Organizations create emergency patch processes for critical vulnerabilities, then never close the loop with retrospective testing and formal documentation. Six months later, an auditor finds patches deployed without change tickets, without test evidence, and without approval records.

Fix: emergency process includes a mandatory 7-day follow-up where abbreviated testing is completed and documentation backfilled. The emergency waives the timing requirement, not the documentation requirement.

Metrics That Drive Improvement

Metric	Target	Why It Matters
Mean Time to Patch (Critical/KEV)	< 72 hours	Measures emergency response capability
Mean Time to Patch (High)	< 14 days	Measures standard-cycle efficiency
Patch compliance rate	> 95% within SLA	Measures program coverage
Overdue patch percentage	< 5% of total findings	Measures backlog health
Patch failure/rollback rate	< 3%	Measures testing adequacy
Scan-to-patch gap (median)	< 7 days for Critical	Measures prioritization-to-action speed

Track these monthly. Trend over quarters. Report to leadership alongside vulnerability scan metrics to give a complete picture of detection and remediation.

Key Takeaways

The patching window (patch available to mass exploitation) is collapsing -- days or hours for critical vulnerabilities, not months
Patch management requires two operational modes: structured lifecycle for routine patches and emergency bypass for KEV/active exploitation
Prioritize by exploitation evidence (EPSS, KEV) and asset context, not CVSS alone
Verification (re-scan + version confirmation) is what closes a vulnerability, not deployment alone
Emergency patches must still generate compliance evidence -- the timing is waived, not the documentation
Scan-to-patch gap is the metric that reveals whether your program can actually execute at threat speed

How Advisedly Helps

Advisedly tracks the complete patch management lifecycle from vulnerability discovery through deployment verification. The platform integrates with vulnerability scanners supporting 350,000+ plugins to identify missing patches, applies risk-based prioritization using EPSS, CISA KEV, and asset context to determine remediation order, and tracks deployment status against compliance-defined timelines across 500+ frameworks. Re-scan verification confirms patches landed, and the compliance module automatically generates auditor-ready evidence for each remediation lifecycle. Contact begin@advisedly.ai to close your scan-to-patch gap.

Frequently Asked Questions

How do we handle patches that break production applications?

Rollback immediately, document the failure, and pursue an alternative remediation path. Options: vendor hotfix addressing the compatibility issue, compensating controls (WAF rule, network isolation) while waiting for a compatible patch, or version upgrade of the affected application to one compatible with the security patch. Document the situation in your POA&M with the alternative remediation timeline. Auditors accept documented compensating controls when accompanied by a vendor timeline.

What is the right patch management cadence?

There is no universal cadence -- it depends on your risk tolerance and compliance requirements. Emergency/KEV patches deploy within hours. Critical patches within 72 hours. High patches within 14 days. Routine patches bundle into weekly or monthly maintenance windows. The key insight: cadence is not about scheduling convenience; it is about how long you are willing to leave a known vulnerability unpatched while exploitation probability rises daily.

Should we automate patch deployment?

Yes, with controls. Automation is the only way to achieve sub-72-hour deployment timelines at scale. But fully autonomous deployment without testing gates is reckless for production systems. The pattern: automate discovery, automate prioritization, automate testing in pre-production, automate deployment with human approval gates for production. Remove the human from the loop for non-critical endpoints (workstations, development servers) to focus human attention on high-risk deployments.

How do we satisfy auditors when we use emergency patch processes?

Emergency patch processes are expected and acceptable -- every mature program has them. Auditors want evidence of: (1) a defined emergency process that existed before the emergency, (2) appropriate authorization (even if expedited), (3) the patch was verified post-deployment, and (4) any abbreviated testing was completed retrospectively. The worst audit outcome is patches deployed with no process at all -- ad hoc heroics without documentation.

What about systems that cannot be patched during business hours?

Use rolling deployments behind load balancers (zero-downtime for services), schedule maintenance windows for systems requiring reboots, or leverage infrastructure patterns that enable patching without disruption (immutable infrastructure, blue-green deployments, container image rotation). If true downtime is required, the business must accept scheduled windows -- a 2-hour maintenance window monthly is cheaper than a ransomware incident because the patch waited for a "convenient time" that never came.

First developed from vulnerability remediation lifecycle documentation for the Advisedly compliance platform.