MSP Patch Management SOP Template

1.Purpose

To patch every managed client’s operating systems and third-party applications on a predictable schedule, inside agreed maintenance windows, with enough testing that a bad patch never reaches every client at once.

2.Scope

Applies to operating system, firmware and third-party application patches on servers and endpoints the MSP manages through its RMM tool. Network device firmware follows the same cadence but is scheduled as a change.

Definitions

Patch policy

The RMM settings that decide which patches are approved, when they install and how devices reboot for a client or device group.

Pilot ring

A small group of devices at each client that receives patches first, before the rest of the client’s devices.

Maintenance window

The agreed time when the MSP may install patches and reboot a client’s systems.

Out-of-band patch

A security patch released or deployed outside the normal monthly cycle because the risk cannot wait.

Patch exception

A device or patch deliberately excluded from patching, with a documented reason and the client’s acceptance of the risk.

3.Responsibilities

Patch Administrator

Maintains patch policies in the RMM, reviews vendor releases, runs the rings and produces compliance reports.

Service Manager

Approves the broad rollout each cycle, authorizes out-of-band patching and owns patch compliance across clients.

Service Desk Technician

Works tickets for devices that failed or missed patching and for user issues caused by a patch.

Technical Account Manager

Agrees maintenance windows and exceptions with each client and reports patch status at business reviews.

Client Point of Contact

Approves maintenance windows, names systems that need special handling and accepts the risk of exceptions.

RACI matrix

R = Responsible, A = Accountable, C = Consulted, I = Informed

4.Materials and PPE

Materials, tools and systems

• →RMM tool with patch management
• →Third-party application patching catalog
• →Vendor release notes and security advisories
• →Client maintenance window register
• →Patch exception register
• →PSA ticketing system
• →Patch compliance report per client

5.Procedure

1. 5.1

   Agree patch windows with each client

   Technical Account Manager

   The Technical Account Manager agrees each client’s maintenance windows, reboot rules and systems that need special handling, and records them in the client documentation.

2. 5.2

   Configure client patch policies in the RMM

   Patch Administrator

   The Patch Administrator sets up each client’s patch policies in the RMM to match the agreed windows, including third-party applications and a pilot group of devices.

3. 5.3

   Review vendor releases each month

   Patch Administrator

   The Patch Administrator reviews the monthly vendor releases and known issues, and decides which patches to approve, defer or block.

4. 5.4

   Patch the MSP’s own systems first

   Patch Administrator

   The Patch Administrator deploys the approved patches to the MSP’s internal devices first and watches for problems for at least one business day.

5. 5.5

   Deploy to client pilot rings

   Patch Administrator

   The Patch Administrator releases the patches to the pilot group at every client in their next maintenance window and reviews the results and any tickets raised.

6. 5.6

   Approve the broad rollout

   Service Manager

   The Service Manager reviews pilot results across clients and approves the broad rollout, or holds specific patches that caused problems.

   Checkpoint: No patch moves past the pilot rings without the Service Manager’s recorded approval.

7. 5.7

   Deploy inside maintenance windows

   Patch Administrator

   The Patch Administrator lets the RMM deploy the approved patches to all remaining devices inside each client’s maintenance window, following the agreed reboot rules.

8. 5.8

   Handle out-of-band critical patches

   Service Manager

   For an actively exploited vulnerability, the Service Manager authorizes out-of-band patching, and the Technical Account Manager tells affected clients before deployment.

   Warning: Even urgent patches go to a pilot group first, unless the Service Manager decides the risk of waiting is greater.

9. 5.9

   Review patch compliance per client

   Patch Administrator

   After each cycle the Patch Administrator reviews the compliance report for every client and opens tickets for devices that failed, were offline or are pending a reboot.

10. 5.10

    Fix devices that failed patching

    Service Desk Technician

    The Service Desk Technician works each failed-device ticket: brings offline devices online, clears install errors, schedules reboots with users and confirms the patch installed.

11. 5.11

    Document patch exceptions

    Technical Account Manager

    The Technical Account Manager records every device or patch that cannot be applied, with the reason, compensating controls and the client’s written acceptance of the risk.

12. 5.12

    Report patch status to the client

    Technical Account Manager

    The Technical Account Manager reports compliance, exceptions and unsupported systems to the client each month and at every business review.

6.Quality checks

• →Every client has documented maintenance windows matched by its RMM patch policy.
• →Patches reached client pilot rings before any broad rollout.
• →Every device that failed or missed patching has a ticket.
• →Every patch exception has a reason and the client’s written risk acceptance.
• →Each client received a patch compliance report this month.

7.Records

• →Client maintenance window register
• →Monthly patch approval decisions
• →Patch compliance report per client
• →Patch exception register with client acceptance

8.KPIs

• →Patch compliance rate per client
• →Days to deploy critical security patches
• →Number of patch-related incidents per cycle
• →Number of open patch exceptions

9.Common mistakes

• →Approving every patch for every client at once with no pilot ring.
• →Patching outside the client’s agreed maintenance window.
• →Ignoring third-party applications and only patching the operating system.
• →Leaving unpatchable systems undocumented instead of recording an exception.

10.Revision history