Building a Patch Tuesday Process That Scales

Today is the last Patch Tuesday of 2022. Microsoft publishes its monthly security updates on the second Tuesday of every month, and a Patch Tuesday process that scales rests on the same few pieces each time: review the release on day one, triage by real-world risk, deploy through test, pilot and broad rings, enforce reboots inside agreed windows, and report on what actually got installed. Everything else in this post is detail on those steps.

The goal is a process that runs the same way at 50 devices as at 5,000, and doesn't depend on one person remembering what to do.

When is Patch Tuesday?

Microsoft releases its scheduled security updates on the second Tuesday of each month, at around 10 a.m. Pacific time. The release covers supported versions of Windows, Windows Server, Office and a long list of other Microsoft products. Details for each vulnerability are published in the Microsoft Security Update Guide.

Microsoft isn't the only vendor on this schedule. SAP holds its Security Patch Day on the second Tuesday of every month, and Adobe typically releases its security bulletins the same day. Other vendors keep their own calendars. Oracle, for example, ships quarterly Critical Patch Updates, and browsers update on a rolling cycle of a few weeks.

Today also marks end of servicing for Windows 10, version 21H1. Devices still on that version stop receiving security updates after this release, so they need to move to a supported version such as 22H2.

Why does a repeatable monthly cadence matter?

Ad hoc patching works when one administrator knows every machine by name. It stops working once you have multiple sites, remote staff and servers with business owners.

A fixed monthly cadence gives everyone something to plan around. Users know when restarts are coming, application owners know when to expect a test request, and because the calendar is predictable, the exceptions stand out.

Here is a simple cycle that fits most small and mid-sized organizations:

Treat these day counts as a starting point. The right numbers depend on your risk appetite and how much testing your environment needs. Write your targets down, get them approved and measure against them.

How do you triage a Patch Tuesday release?

Most organizations install the whole cumulative update anyway, so triage isn't about picking patches. It's about deciding how fast each system needs them and whether anything should skip the normal rings.

Start with these signals, roughly in order:

1. Exploited in the wild. Microsoft marks vulnerabilities it knows are being exploited. These go to the front of the line.
2. Listed in CISA's Known Exploited Vulnerabilities catalog. The catalog is a free, public list of vulnerabilities with confirmed exploitation. Under Binding Operational Directive 22-01, US federal agencies must fix each entry by a due date CISA sets, usually a matter of weeks for recent vulnerabilities. That's a useful yardstick even if the directive doesn't apply to you.
3. Publicly disclosed. Details are already out, so a working exploit may be close behind.
4. Exposure. Internet-facing servers, remote access gateways and systems holding sensitive data carry more risk than an isolated kiosk.
5. Severity and exploitability. Microsoft's severity rating, the CVSS score and its exploitability assessment all help. FIRST's Exploit Prediction Scoring System (EPSS) is another input if you want a probability estimate.

Don't let a CVSS score make the decision on its own. A "critical" flaw in a component you don't run is less urgent than an "important" one on your internet-facing mail server that attackers are already using.

Before anything leaves the test ring, check Microsoft's Windows release health page for known issues. Microsoft often documents problems and workarounds there within days of a release.

Sort updates into three tracks

• Emergency: exploited and exposed. Compress the rings to hours, not days.
• Priority: exploited or disclosed but not directly exposed, or high severity on critical systems. Run the normal rings at the fast end of your targets.
• Routine: everything else. Standard cadence.

What is ring-based deployment?

Ring-based deployment means releasing updates to progressively larger groups, so a bad patch hurts a few devices instead of all of them. The usual structure has three rings.

Test ring

A small set of devices that represent what you run: IT staff machines, a few virtual machines built from your standard image, and one of each major hardware model. It gets updates on Patch Tuesday or the day after. Smoke test sign-in, key business apps, printing, file shares and remote access.

Pilot ring

Roughly 5–10% of users, chosen from every department and location rather than just IT. Include people who use the awkward applications, such as finance on month-end tools or the team with the specialist hardware driver. Pilot users should know they're pilots and have an easy way to report problems.

Broad ring

Everyone else, often split into two or three waves so you can pause if something surfaces late. Set clear exit criteria for moving from one ring to the next: no new update-related help desk tickets, smoke tests passed, and no new known issues published that affect you.

Servers need their own rings

Servers follow the same logic on a separate track: non-production first, then lower-risk production, then critical systems. For clustered or load-balanced services, patch one node at a time and confirm it's healthy before moving on. Domain controllers, database servers and anything with a hard uptime requirement should have named owners and pre-agreed windows.

Most patch management tools can express rings as deployment groups with deferrals and deadlines, which turns the monthly cycle into approvals and monitoring.

How should you handle out-of-band updates?

Microsoft sometimes releases updates outside the monthly cycle. These out-of-band releases usually fall into one of two groups:

• Urgent security fixes for vulnerabilities being actively exploited, where waiting for the next Patch Tuesday would be too risky.
• Fixes for problems a monthly update caused, such as authentication failures or broken printing.

Your process needs a documented fast path for the first group. Decide in advance who can approve an emergency deployment, how far each ring can be compressed and who gets told. For an exposed system, that might mean test in the morning and broad by evening.

The second group needs a different question: are we affected? Many fix-only releases matter only if you hit the specific problem. Some are published only through the Microsoft Update Catalog, so check whether your tooling will pick them up automatically or needs a manual import.

When there's no patch yet, apply the vendor's published mitigation or workaround, track it as a temporary exception and remove it once the fix is installed.

How do you manage reboots and maintenance windows?

An update that's installed but waiting for a restart hasn't protected anything. Pending reboots are a common reason patch reports look better than reality.

Servers

Agree maintenance windows with server owners before you need them. A standing monthly window beats negotiating every time. Record it against each server in your inventory so the tooling can enforce it.

Workstations and laptops

For end-user devices, use deadlines with grace periods: notify users when the update is ready, let them pick a restart time for a few days, then enforce the restart. Keep the grace period short enough that your compliance targets still hold.

Laptops that rarely connect to the office network need a way to get updates straight from the internet. Otherwise some will fall behind for weeks.

Change freezes

Many organizations freeze changes around year-end or peak trading periods. Decide ahead of time whether security updates are exempt, and under what conditions, so you're not having that argument mid-emergency.

Don't forget third-party applications

Windows patching gets the attention, but a lot of exposure sits in third-party software: browsers, PDF readers, Java runtimes, collaboration clients, compression tools, remote support utilities and hardware drivers.

Fold them into the same cycle:

• Inventory first. You can't patch software you don't know is installed.
• Enable auto-update where it's safe. Browsers are the obvious candidate. Control the settings centrally so users can't turn updates off.
• Use the same rings. Third-party updates can break things too. Route them through test and pilot like everything else.
• Remove what you don't need. Every unused application you uninstall is one fewer thing to patch each month.
• Track vendor calendars. Adobe and SAP line up with Patch Tuesday, but many vendors don't. Subscribe to security notifications for anything business-critical.

For line-of-business applications, ask each vendor how they announce security fixes and put it in the contract at renewal if you can.

Firmware, BIOS and network devices usually need a separate track with their own windows, but they should still show up in the same monthly report.

What should a Patch Tuesday report include?

Track a small set of measures every month:

• Compliance by ring and severity at fixed points, such as day 7, day 14 and day 30.
• Time to patch for emergency and priority updates.
• Pending reboots as their own number, not folded into "installed".
• Failed installs and their root causes.
• Stale devices that haven't checked in with your management tool for more than a set period.
• Open exceptions, each with an owner, a reason, compensating controls and an expiry date.

Check the deployment tool's numbers against an independent source, such as an authenticated vulnerability scan. Deployment tools report what they tried to install. Scanners report what's actually missing. The gap between the two is often where the real risk sits.

Operations teams need device-level detail. Leadership needs one page: are we within target, what's the trend, and which exceptions need a decision.

Frequently asked questions

Should we wait a few days before installing Patch Tuesday updates?

Not blindly. Waiting protects you from bad patches but leaves you exposed to the vulnerabilities being fixed. Ring-based deployment gives you both: the test ring starts right away, and the broad ring waits until the early rings have proven the update is safe.

Do servers and workstations need the same schedule?

No. They share the same triage but usually run on separate ring tracks with separate windows. Servers often take longer because of owner approvals and uptime requirements, which is fine as long as the targets are written down and met.

What if a patch breaks a critical application?

Roll it back on affected devices, record an exception with compensating controls and an expiry date, and raise it with the application vendor. Recheck at the next Patch Tuesday, because cumulative updates mean you can't skip a month's security fixes indefinitely.

Key takeaways

• Run the same monthly cycle every time: triage on day zero, then test, pilot and broad rings with clear exit criteria.
• Triage by exploitation and exposure first, severity second.
• Keep a documented fast path for out-of-band security fixes.
• Count pending reboots and stale devices as unpatched until proven otherwise.
• Put third-party applications and firmware in the same process and the same report.
• Before year-end, upgrade any devices still on Windows 10 21H1 and agree how change freezes treat security updates.