Patch Tuesday Survival Guide: Building a Monthly Vulnerability Workflow

The second Tuesday problem

Every second Tuesday of the month, Microsoft publishes somewhere between 60 and 150 CVEs. Adobe usually ships the same day. Oracle piles on quarterly with 300+. SAP, Cisco, and VMware follow their own cadences. If your response to this monthly flood is "forward the advisory to the infra team and hope," you do not have a vulnerability management program. You have a mailing list.

The teams that handle Patch Tuesday without drama all share one trait: they run the same process every month, boring and repeatable, with decisions made by rules rather than by whoever is loudest in the war room. This guide is that process.

The monthly calendar

Anchor everything to Patch Tuesday itself (call it day T). Here is a schedule that survives contact with reality:

Adjust the numbers to your environment, but keep the shape: fast lane for actively exploited bugs, pilot ring before broad rollout, hard close at month end.

Day T: ingest without drowning

The goal on Tuesday is not analysis. It is getting every advisory into one normalized list with the fields you need for triage:

• CVE ID, affected product, and affected versions
• Vendor severity and CVSS score
• Exploitation status: publicly exploited, proof of concept available, or nothing yet
• Which of your asset classes it touches

Microsoft's Security Update Guide gives you exploitation status directly ("Exploitation Detected" and "Exploitation More Likely" are the fields that matter). Pull Adobe and any other same-day vendors into the same list. Resist the urge to start patching anything on Tuesday. Triage first.

T+1: triage with KEV and EPSS, not vibes

CVSS alone will bury you. A typical Patch Tuesday includes 8 to 12 CVEs rated critical, and treating them all as emergencies means treating none of them as emergencies. Layer three signals instead:

1. CISA KEV: is the CVE on the Known Exploited Vulnerabilities catalog, or does the vendor flag active exploitation? If yes, it goes in the emergency lane. No debate, no meeting.
2. EPSS: for everything else, the Exploit Prediction Scoring System estimates the probability of exploitation in the next 30 days. A pragmatic threshold: EPSS above 0.1 (roughly the top few percent of all CVEs) earns expedited handling.
3. Exposure: does the vulnerable component face the internet, or sit on a domain controller, or hold crown-jewel data? An exploited-in-the-wild bug on an isolated lab VM can wait. A "moderate" auth bypass on your VPN concentrator cannot. Citrix Bleed (CVE-2023-4966) is the canonical warning here: a session-token leak on internet-facing NetScaler devices that ransomware crews were exploiting at scale within weeks, against organizations still working through their standard 30-day cycle.

You can check KEV status and EPSS for the whole batch in one pass on vuln.mlab.sh, which shows CVSS, EPSS, and KEV side by side for any CVE, so Wednesday morning triage is a lookup exercise rather than a research project.

The output of triage is exactly three buckets:

Write the bucket criteria down once, get leadership to sign them, and stop renegotiating them monthly.

Patch windows by asset class

A single org-wide deadline fails because a laptop and a hypervisor do not carry the same rollback risk. Define windows per asset class ahead of time:

• Internet-facing systems: first in line, always. This is where exploitation actually starts. Edge devices, VPNs, mail gateways, and file transfer appliances deserve the emergency treatment almost by default; ask anyone who ran MOVEit Transfer in May 2023 (CVE-2023-34362 went from unknown to mass exploitation before a patch existed).
• Workstations: high volume, low individual risk. Automate aggressively, patch in rings, accept the occasional broken printer driver.
• Standard servers: pilot ring first, then maintenance windows. One week of soak time in pilot catches most bad patches.
• Critical servers and infrastructure: scheduled windows with tested rollback plans. These get the longest runway, which is precisely why anything exploited must jump the queue.
• OT and appliances: vendor-dependent. Track them separately and compensate with network controls when patching lags.

Communicate deadlines like you mean them

Patching fails at the handoff more than at the technical step. Three habits fix most of it:

• One monthly summary, sent T+1, to system owners: what dropped, what is in each bucket, what their deadline is. One page. Nobody reads the 40-page advisory digest.
• Deadlines phrased as dates, not durations. "Patch by April 25" beats "within 14 days of release."
• Escalation path defined in advance. If a deadline passes, the item goes to the owner's manager automatically. This should feel like process, not like drama.

Verify, or you patched nothing

Deployment reports lie. Reboots get postponed, WSUS clients drift, gold images resurrect old builds. Verification means an independent check: an authenticated scan or agent query at T+28 confirming the vulnerable version is actually gone.

Track two numbers every month:

• Compliance by deadline: percent of in-scope assets patched within their bucket's SLA.
• Residual exposure: count of KEV-listed CVEs still present anywhere in the estate, by age.

The second number is the one worth showing leadership. "Zero known-exploited vulnerabilities older than 30 days" is a sentence executives understand and attackers respect.

Handle exceptions with discipline

Some things will not get patched on time: the vendor appliance that voids support, the legacy app that dies on the new runtime, the plant system with a six-month maintenance window. An exception process keeps these from becoming invisible permanent risk:

1. Written request from the system owner with a business reason.
2. Compensating controls documented: network segmentation, WAF rule, disabled feature, extra monitoring.
3. Expiry date. Exceptions renew explicitly or lapse; none are forever.
4. A named risk acceptor above the requester's pay grade.

Review the exception register monthly, in the same meeting where you close the cycle. An exception nobody re-reads is just a vulnerability with paperwork.

The one-page checklist

Pin this next to the coffee machine:

• [ ] T: ingest all vendor advisories into one normalized list
• [ ] T+1: triage every CVE into emergency / expedited / standard using KEV, EPSS, exposure
• [ ] T+1: send the one-page summary with dated deadlines
• [ ] T+2 to T+4: emergency patches deployed and verified on exposed assets
• [ ] T+7: pilot ring patched, soak started
• [ ] T+14: broad workstation and standard server rollout
• [ ] T+21: critical server maintenance windows executed
• [ ] T+28: verification scan, compliance and residual-exposure metrics
• [ ] T+30: exceptions reviewed, month closed

Patch Tuesday never gets smaller. But a team running the same calm loop every month will beat a team of heroes improvising every time, and it will not even be close.