Patch Management Process

Why this process exists

Patching is unglamorous, but it is one of the controls that now decides whether your clients can buy cyber insurance at all. The standard 2025–26 underwriting minimum includes a documented patch and vulnerability management cadence alongside MFA, EDR, and tested backups – weak answers typically mean 40–100% premium hikes, exclusions, or declination. A written, ring-based process also protects you: when a client asks "why did my machine reboot" or "why weren't we patched before the breach," the answer is a policy they signed, not an improvisation.

Roles: one named patch owner runs the monthly cycle end to end; the service desk works patch-failure tickets like any other ticket; the account manager handles client-facing scheduling and exception sign-off. In a two-person shop these are hats, not headcount – but the cycle still needs a single owner.

The patch policy: deployment rings

Write one patch policy, attach it to every agreement, and record client deviations as exceptions. The core of the policy is a ring structure that turns "test before broad deployment" into a schedule:

1. Ring 0 – test group. Your own MSP machines plus a handful of lab VMs mirroring common client builds. Patches apply within a day or two of release. You are the canary – if an update breaks printing, you find out on your own laptop.
2. Ring 1 – pilot. Roughly 5–10% of each client fleet: IT-tolerant volunteers, one machine per department, non-critical servers. Let patches soak here a few days while you watch for failure patterns.
3. Ring 2 – broad workstations. The rest of the fleet, deployed automatically once the pilot ring is clean.
4. Ring 3 – servers and critical systems. Last, inside contracted maintenance windows, with a snapshot or verified backup taken first.

The rings are policy objects in your RMM, not a spreadsheet. A typical full cycle runs about two weeks from vendor release to servers patched.

OS vs third-party patching

OS patching is the easy half – every serious RMM automates Windows and macOS updates. Third-party applications (browsers, PDF readers, runtimes, collaboration clients) are where coverage quietly fails, because RMM third-party catalogs vary widely in breadth and freshness. Audit which of your clients' actual installed applications your tooling covers, close the gap with a supplemental patching tool if needed, and treat uncovered line-of-business apps as documented exceptions with a manual update owner. An endpoint with a current OS and a year-old browser plugin is not patched.

Maintenance windows and client communication

• Workstations: patch outside business hours with wake-on-LAN or next-boot retry. Allow user deferral of reboots, but cap it (a typical policy: three deferrals or 72 hours, whichever comes first, then forced reboot with warning).
• Servers: a contracted monthly window per client – for example, third Saturday 22:00–02:00 – written into the SLA attachment, not negotiated ticket by ticket. Set expectations during client onboarding.
• Communication rhythm: publish the annual window schedule once, send a reminder before each server window, and otherwise stay silent on success. Notify only on exceptions – a completed-with-issues note beats a monthly "everything was fine" email nobody reads.

Automating approvals and schedules in the RMM

Configure approval policies once, per ring, and stop touching individual patches:

• Auto-approve security updates and definition updates after their ring soak; hold feature upgrades, firmware, and driver updates for manual review.
• Map schedules to rings globally; per-client overrides exist only as documented exceptions.
• Route failures automatically: an endpoint that misses two consecutive cycles opens a PSA ticket – silent drift is the failure mode that shows up in breach postmortems.
• Patch your own house fastest of all. Your RMM is a supply-chain weapon pointed at every client – the July 2021 Kaseya VSA attack pushed ransomware through the RMM's own agent channel to roughly 60 MSPs and 800–1,500 downstream businesses. Patch RMM servers and agents within days of release, and see securing your MSP for the rest of your own hardening.

Exceptions and deferrals

Every "don't patch that" needs a paper trail: what is excluded, why (usually a legacy LOB app pinned to an old runtime), the compensating control (network segmentation, extra monitoring), a review date, and the client's written risk acceptance. Store exceptions in your documentation platform per your documentation standards and review them at every QBR – an exception without a review date is permanent unpatched exposure you now own.

Emergency out-of-band patching

When a CVE is being actively exploited (CISA KEV listing, vendor emergency advisory) in software your clients run, the monthly cycle is suspended for that patch:

1. Assess exposure fast. Query the RMM for affected versions; internet-facing systems first.
2. Compress the rings. Test on a handful of machines in hours, not days; if exploitation is confirmed and the vendor patch is stable, skip the pilot soak. Where no patch exists, apply the vendor mitigation (disable the feature, firewall rule) and track it as a deferral.
3. Patch outside windows. Your patch policy should pre-authorize emergency work without per-event approval – negotiating window exceptions during active exploitation wastes the hours that matter.
4. Notify clients on a set cadence. Initial notice at the start: what the vulnerability is, whether they're exposed, what you're doing, whether any action or downtime is needed. Interim updates at a stated interval (every 4–8 hours is typical for multi-day events). A completion notice with verification results. Keep a reusable template with those four fields – writing prose at 11pm during an incident is how errors happen.

Verification, rollback, and reporting

Success is verified, not assumed. After each cycle, reconcile: every endpoint checked in, installed, rebooted, and rescanned clean. Chase stragglers (offline laptops are the usual culprits) and track patch-compliance percentage per client.

Rollback is planned before deployment. Servers get a snapshot or verified backup before the window; know the uninstall path for each major update. If the broad ring surfaces a bad patch: pause the policy, remove the update from affected machines, document the CVE-vs-stability decision.

Reporting is your evidence. A monthly patch-compliance report per client, with exceptions listed, does triple duty: QBR material, compliance artifact, and cyber-insurance evidence. Insurers send annual attestation questionnaires the client can't answer – you supply the patch reports, but the client's officer signs the attestation, never you.

Monthly cadence checklist

• Release day +1–2: Ring 0 patched; review vendor notes for known issues.
• Day 3–5: Ring 1 pilot deploys; monitor failure alerts.
• Day 6–10: Ring 2 broad workstation deployment; failures become tickets.
• Day 10–14: Ring 3 server windows; snapshot first, verify after.
• Day 15: Reconciliation – compliance report per client, chase stragglers, file evidence.
• Quarterly: review exceptions and deferrals; audit third-party coverage.
• Continuous: monitor KEV/vendor advisories for out-of-band triggers; patch your own RMM within days.

Run this cycle unchanged for three months and patching stops being work – it becomes a report you hand to clients and insurers while the RMM does the labor.