Guide

A monthly patching routine for a small MSP

By OKSANA DRONOVA · Updated September 29, 2026

Patching is the one service every client assumes you do and almost none of them notice until it fails. For a small MSP the risk is not a single missed update; it is a process that lives in one technician’s head and quietly degrades when that person is on holiday. What follows is the monthly cycle we would hand to a new tech on day one: a calendar, a ring structure, rules for exceptions, and a report the client actually reads.

The examples assume Windows endpoints with Microsoft’s monthly security release on the second Tuesday of the month (Patch Tuesday), plus third-party applications. The same rhythm works for macOS and Linux, with different sources.

The calendar

Anchor everything to Patch Tuesday and count forward. Here is a typical month:

For a vulnerability that is being actively used in attacks, compress the schedule: pilot the same day, broad within 48 hours, servers at the next available window. Write that emergency path down now so nobody has to invent it at 11pm.

Building the rings

Rings let a bad update hurt a few friendly users instead of a whole client.

1. Pilot (5–10% of workstations). Pick people who report problems and forgive them: your own machines, a tech-savvy office manager, one device per common hardware model. Include at least one machine running each critical line-of-business app.
2. Broad (the rest of the workstations). Everyone else. Split very large clients into two waves a day apart if you want an extra safety margin.
3. Servers. Domain controllers, file servers, application servers and hypervisors. Patch one member of any redundant pair first, then the other. Always confirm the most recent backup succeeded before starting.

Keep ring membership in the RMM as groups or tags rather than in a spreadsheet, so new devices land in the broad ring by default.

Deferral and approval settings

Whichever tool you use, you are setting the same few knobs. An illustrative policy, written out as settings rather than any vendor’s actual syntax:

# Illustrative workstation patch policy (not vendor syntax)
ring: broad
os_security_updates:
  approve: automatic
  deferral_days: 7        # pilot gets 0-1
feature_updates:
  approve: manual         # upgrade on a planned project, not monthly
drivers_and_firmware:
  approve: manual
third_party_apps:
  approve: automatic
  deferral_days: 3        # browsers and PDF readers move fast
reboot:
  window: "Wed-Thu 19:00-23:00 local"
  user_postpone_limit: 3
  force_after_hours: 72

Two rules worth applying everywhere: feature updates are projects, not maintenance, and drivers or firmware never ride along unapproved with the monthly cycle.

Reboot windows people will accept

Most failed patch cycles are really failed reboots. Agree windows with each client during onboarding and put them in the contract notes.

• Workstations: an evening window with a visible prompt, a limited number of postponements, and a forced reboot after a fixed deadline. Tell users the deadline in the prompt.
• Laptops that are never on at night: allow a lunchtime window or a reboot on next login, and accept that these devices will lag the fleet by a few days.
• Servers: a scheduled window with the client’s sign-off. Check pending-reboot status before and after.

A quick PowerShell check your RMM can run as a script to find machines waiting on a restart:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
)
$pending = $paths | Where-Object { Test-Path $_ }
if ($pending) { Write-Output "Reboot pending"; exit 1 } else { Write-Output "OK"; exit 0 }

Wire the non-zero exit code to an alert or a dashboard column and you have a daily stragglers list.

Handling exceptions

Some machines cannot take this month’s update: a CNC controller certified on an old build, a lab PC tied to an instrument, a server whose vendor has not approved the patch yet. Exceptions are fine; undocumented exceptions are not.

For each exception record:

1. The device and the specific update or category excluded.
2. The reason, and who at the client approved it (name and date).
3. Compensating controls: network segmentation, no internet access, application allow-listing.
4. A review date, normally the next month’s cycle.

Exceptions appear in the client report every month. That keeps them visible and makes it the client’s decision, not yours, to leave a risk in place.

The client-facing compliance report

Clients do not want a list of KB numbers. They want to know whether they are covered and what is left. A one-page monthly report we like has four parts:

Measure compliance against devices that checked in during the month, and list the devices that did not separately, so a laptop in a drawer does not hide in the percentage. Keep the baseline report from onboarding alongside, so the trend line starts at a real number (see the client onboarding checklist).

Common mistakes

• Auto-approving everything with zero deferral. Fast, until a bad update reaches every machine on the same evening.
• No owner for the cycle. Put the calendar in the PSA as recurring tickets with a named assignee.
• Ignoring third-party apps. Browsers, PDF readers, Java runtimes and remote-support tools carry a large share of real-world risk.
• Counting “installed” as done. An update awaiting reboot is not protecting anyone yet.
• Patching servers without a verified backup. Check the last job status before every server window.

Tools that fit this routine

Patch-focused platforms like Action1 handle OS and third-party patching with rings and reporting, and full RMMs such as NinjaOne, Atera and Syncro bundle patching with monitoring and ticketing. The patch and endpoint category compares them, and Action1 vs NinjaOne covers the most common choice between a patch-first tool and a full RMM. Our scoring approach is on the methodology page.