Patch Management
Prioritization, testing, deployment windows, and verification for patches that must reduce exposure without destabilizing operations.
Patch management is a cadence of decisions, not a monthly act of installation. Each release cycle forces teams to sort vendor advisories, asset scope, exploit signals, application dependencies, maintenance windows, and the confidence they have in a fix. Endpoint, infrastructure, security, and application owners may look at the same patch through different lenses: exposure, availability, supportability, or customer commitments. Patch Tuesday provides a predictable intake rhythm, yet the real work begins after release notes arrive. Teams need to know which assets are affected, whether a workaround is viable, what testing represents production, and whether the change can be rolled back if the package creates a second incident.
The posts gathered here examine the machinery that converts that intake into a controlled deployment sequence. They cover CVSS, EPSS, and Tenable VPR as inputs rather than automatic decisions; CISA KEV as a stronger escalation signal; and incomplete patches as a case where closure must not be assumed. They also address audit defensibility, because a risk-based deferral needs an owner, a rationale, compensating safeguards, and a next review point. Readers can use this material to improve patch windows and CAB submissions by joining vulnerability intelligence to service knowledge. The goal is neither maximum speed nor perfect certainty. It is a documented choice that reduces the most relevant risk while keeping operational consequences visible.
Start here
-
Patch Tuesday: What It Is and How to Plan Around It
Establishes a useful operating rhythm for turning a recurring vendor release into planned change work.
More on Patch Management
-
This Week in Change Risk — Week of Nov 9, 2026
11 KEV adds incl. OpenSSH and Barracuda, a GitHub migration that hit Actions, Cloudflare's Workers change outage, Jira's 422 limits and NIST SP 800-221r1.
-
This Week in Change Risk — Week of Nov 2, 2026
Ivanti, WordPress and a 2024 Apple flaw join KEV, GitHub's retry-storm RCA, Datadog's Q3 usage warning, NIST CSWP 50 and Alpine's sshd restart lesson.
-
WordPress CVE-2026-119977: When the Upgrade Is the Risk
CISA's WordPress KEV entry is due Nov 6 and the exposure sits in the upgrade itself. How to scope, triage and run the core update as an emergency change.
-
This Week in Change Risk — Week of Oct 26, 2026
php2shell, Cisco ASA and GitLab KEV adds, three entries with months-old fixes, Cloudflare's provider outage, ServiceNow Q3 margins, PCI's Oct 31 sunsets.
-
php2shell KEV Deadline: Evidence First, Then the Emergency Patch
CISA's php2shell KEV entries are due Oct 29 and flagged for forensic triage. How to run the emergency change: collect evidence, patch, restart, verify.
-
BOD 26-04: Pre-Wire Your Emergency Change Before the Clock
CISA's BOD 26-04 sets a 16-row deadline table. Here is how a CAB pre-authorizes the ECAB so a 3-day KEV clock never catches you improvising.
-
The Patch You Could Calendar: SharePoint's RCE Chain
Microsoft split a SharePoint RCE chain across two Patch Tuesdays. Here is how a CAB stages a planned emergency change for a fix you know is coming.
-
The 3-Day KEV Clock: A CAB Runbook for CVE-2026-8037
CISA gave Progress LoadMaster CVE-2026-8037 a three-day deadline. How a change advisory board runs an emergency change against that clock.
-
How to Read a CISA KEV Entry and What to Do Next
A field-by-field guide to CISA KEV catalog entries, BOD 22-01 obligations, and a 24-hour runbook for when a new KEV drops.