Patch Deployment Checklist

Pull the Microsoft Patch Tuesday release, plus any third-party advisories in scope (Adobe, Chrome, Firefox, Java, VMware, network OS). Filter by CVSS 7.0+ and any CISA KEV catalog entries — those drive the priority ring. Skipping the KEV cross-check is how a known-exploited vuln slips a cycle.

Check each KB article and the BornCity / AskWoody known-issues feeds. Recent cycles have shipped KBs that broke Hyper-V, RDP, or domain controller authentication. If a KB has an active known-issue advisory, log an exception in the risk register and exclude it from this cycle's deployment.

Push the approved set to the lab VMs that mirror production roles — DC, file server, RDS host, SQL, and a representative Windows 11 / macOS endpoint. Run for 48 hours minimum before promoting. Watch event logs and application smoke tests; this is where .NET and driver regressions show up.

Email business owners and the helpdesk lead with the window, in-scope systems, expected downtime, and the rollback contact. For MSP clients, send through the PSA so it lands in the ticket history. Include a clear opt-out deadline for any owner who needs to delay a specific server.

Per ring, name the rollback method: Veeam image restore, Intune uninstall command, WSUS decline + scripted removal, or snapshot revert. Include the named operator who owns the rollback decision and the timeline for declaring failure (typically 60 minutes after deployment completes).

Kick a forced full (not incremental) in Veeam, Datto, or Rubrik for every host in the ring. Pre-patch fulls give you a clean restore point if a KB corrupts the boot chain. Confirm the job completes before the maintenance window opens.

Attach the job report screenshot or export. Look for warnings, not just the green checkmark — VSS write errors and CBT corruption are silent failures that show as 'success with warnings' and produce unrestorable backups.

Verify the offsite copy (S3 Object Lock, Wasabi immutable, or LTO eject) is current as of last night. The 3-2-1 rule only protects against ransomware if the third copy is genuinely write-locked from the production credential.

Restore one representative server to an isolated VLAN with no production routing. Boot it, log in, confirm app starts. A backup that hasn't been restored in 90 days is an assumption, not a recovery capability.

The restore drill failed — do not proceed with deployment. File a P2 ticket with the backup vendor, identify the failure mode (agent, credentials, repository, network path), and re-run the drill once fixed. The patch cycle pauses here until backups are demonstrably restorable.

Set maintenance mode in PRTG / Auvik / LogicMonitor for in-scope hosts and disable PagerDuty escalation for the window. Note: don't blanket-suppress the whole site — leave non-patched systems live so a coincident outage still pages.

Push via SCCM, Intune, or your RMM (NinjaOne, Datto RMM, Automox) to the 5–10% pilot ring. These are typically IT-team workstations and a single non-critical server per role. Watch the deployment console live.

Run the smoke-test script on each pilot host: login, primary app launch, network share, print, AV check-in. Confirm event logs are clean of new error IDs. A pilot pass is the gate for production rollout — do not promote on partial signal.

Roll to the remaining hosts in collection batches. Stagger DCs so at least one per site stays available throughout. For RDS hosts, drain sessions before reboot. For database servers, confirm the secondary is current before touching the primary.

Record the headline result, paste any error codes encountered, and attach the SCCM / Intune / RMM deployment report. This becomes the change-record artifact for SOC 2 and SOX ITGC change-management evidence.

Follow the rollback method named in the pre-deployment plan — Veeam restore, snapshot revert, or scripted KB uninstall. Notify stakeholders that the window is being extended for rollback. Open a P1 ticket and capture the failing KB for vendor escalation.

Walk the named-application smoke-test list: ERP login, email send/receive, file-share access, line-of-business app, VPN connect, print. Don't rely on monitoring alone — a service can be 'running' while logins fail.

Take hosts out of maintenance mode and watch alert volume for the first hour. A spike in disk or memory alerts after a patch usually means a service is restart-looping or a driver isn't loading. Investigate before declaring the window closed.

Run an authenticated scan in Tenable, Qualys, or Rapid7 InsightVM and diff against the pre-patch baseline. Attach the report. This is the artifact auditors ask for when they want to see that patches actually closed the CVEs you said they did.

Push the updated build numbers to ServiceNow, Hudu, or IT Glue. Stale CMDB patch levels are how the next cycle's exception list ends up wrong — fix it now while the data is fresh.

For every host that couldn't be patched this cycle (legacy app dependency, vendor-blocked, end-of-life OS), record the CVE, the compensating control, and the review date. Auditors want to see exceptions tracked, not silently skipped.

Re-run CIS-CAT Pro or the STIG checker against a sample of patched hosts. Patches sometimes regress hardening settings — a feature update can flip back default firewall rules or audit policy. Capture and re-apply the GPO if so.

Close the RFC in ServiceNow / ConnectWise with the deployment outcome, vuln scan delta, exceptions, and rollback events (if any). This is the SOX ITGC and SOC 2 CC8.1 evidence. A closed change with no PIR is an audit finding.

Book the 30-minute retro with the patch lead and the security analyst. Review what regressed, which hosts were chronically excluded, and any pilot-ring signal that should have caught a production issue. Feed the findings into next month's checklist.