Buy a complete patching workflow
Separate patch selection, preparation, deployment, verification and later monitoring. NIST SP 800-40 Rev. 4 (external website), published in April 2022, describes patch management as preventive maintenance. Its deployment sections distinguish installing an update from checking that it is installed and has taken effect. A closed deployment task alone cannot answer whether a device still needs a restart or its application works.
Your proposed scope should identify operating systems, application categories and device classes separately. Windows workstations, Windows servers, macOS, Linux, network firmware and third-party applications can have different owners and maintenance rules. Ask which are included, excluded or separately charged. A tool's supported-product list does not prove that the supplier will operate every supported feature.
Published service examples
These three existing purchases illustrate different scope boundaries. They do not establish a preferred supplier or a common patch deadline.
IT By Design / NOC Care
Care adds scheduled preventive maintenance, patch execution, backup verification/restore validation, health checks and maintenance reporting to Watch. NOC service and FAQ / 2026-11-06 (external website)
Ask in the proposal: Which device groups, update categories, canary checks, restart windows and failed-change work does NOC Care include?
Read this service profile / RFP for this service / Download service brief
ConnectWise / NOC with ConnectWise RMM
24/7/365 monitoring, support and patching are advertised. Source / 2026-10-15 (external website)
Ask in the proposal: Which RMM package, patch categories, approval policy and post-restart checks apply to the proposed NOC service?
Read this service profile / RFP for this service / Download service brief
Uptime / Inbay / White-label help desk
Standard patch management covers Windows unless a Mac support contract is taken. Patching scope / 2026-10-17 / PDF p. 7 (external website)
Ask in the proposal: Which Windows device classes and applications are included, and what does the separate Mac support contract add?
Read this service profile / RFP for this service / Download service brief
IT By Design's Watch tier already includes reactive remediation; the explicit structured maintenance and patch execution wording appears in Care. Keep those obligations separate when requesting a lower-tier quote. ConnectWise also describes its NOC testing, restricting and deploying patches (external website). That is the supplier's description, not an independent test of a particular patch or your intended environment.
For Automate fleets, the ConnectWise Automate NOC guide keeps the selected supplier scope beside script approval, device targeting, the maintenance window and PSA handback.
Agree who can take each action
Example responsibilities to agree with your provider.
| Decision | Put in the service scope | Completion or escalation record |
|---|---|---|
| Select an update | Who checks applicability, dependencies and vendor notices; who can hold or approve it | Approved update and device group, or a dated hold with an owner |
| Choose the first devices | Who selects representative, authorized canary devices and accepts their checks | The selected devices and the decision to expand or stop |
| Deploy to the next group | Which policies, tenant boundaries and changes the supplier may use | Device-level deployment results and remaining work |
| Restart a device | Who can approve the interruption and notify users or application owners | Restart completed, denied or deferred, with the next owner |
| Handle a failed change | Who may retry, pause later deployments or approve recovery | The fault, allowed action, application owner and next update |
| Close the work | Who checks update state, required restart and business function | A verified result or a clearly owned open item |
An offline endpoint is still work to account for. Ask when the supplier retries, how it notices a device returning and who contacts an absent user. A maintenance window must also say what happens when a deployment is still running at its end.
Make the restart a separate decision
Microsoft's device restart documentation (external website) distinguishes scheduled installation, restart policies and active hours. It also marks some restart settings as legacy and inapplicable to Windows 11. Confirm the actual Windows version and effective policy before accepting a proposed restart process. This Windows client example does not prescribe settings for servers, macOS or Linux, or describe any listed supplier's configuration.
Write the permitted window with its timezone, the latest start time, user notification, approval owner and action if approval is unavailable. For a service-hosting device, name the application owner who can confirm that service has returned. Approval to install an update need not include approval to interrupt the workload.
Define the failed-change path before rollout. Name who can halt expansion, diagnose the fault, contact the software vendor and authorize an available recovery method. Removing an update, restoring a backup and rebuilding a device are different actions with different effects; their availability and permission require an agreed plan. Use the backup recovery guide when that plan relies on a restore.
Count the complete inventory
Invented example, not observed supplier performance: ten devices are in the agreed patching group. Their mutually exclusive end states at the reporting cutoff are:
| State at the cutoff | Devices | Work still to own |
|---|---|---|
| Update verified and required restart completed | 6 | Keep the result and application-check reference |
| Installation reported, restart still pending | 1 | Obtain the authorized restart and verify afterward |
| Installation failed | 1 | Diagnose, escalate or execute an approved recovery |
| Device offline throughout the attempt | 2 | Retain in the inventory and arrange the next attempt |
| Total assigned inventory | 10 | Four devices still lack the stated completion result |
Six of ten assigned devices gives 60% confirmed completion. Excluding the two offline devices gives six of eight reachable devices, or 75%. Both ratios can be calculated, but they answer different questions. Label the denominator and reporting cutoff; keep offline and deferred devices visible. A successful installation count must not quietly absorb pending restarts or missing application checks.
Ask for the actual device count, installed update identifiers, remaining states, restart evidence, exceptions and next owners. The worked percentages are not a target, a vulnerability-free claim or a provider score.
Keep emergency work explicit
NIST's planning scenarios and maintenance groups (external website) distinguish routine patching, emergency patching, temporary mitigation and assets that cannot be patched. Its routine deployment example starts with a limited group before wider rollout. These are planning distinctions, not a universal timetable or a contractual requirement for every MSP.
In the proposal, separate routine scheduled work from an out-of-cycle request. Name who can raise urgency, approve an exceptional window and accept business interruption. If an asset cannot receive an update, retain it in a named plan with an owner and a review date. A general 24/7 monitoring statement does not price or authorize every emergency change.
Try bounded acceptance cases
Example pilot cases. Reuse the NOC pilot case log to retain the first attempt, result reference, correction and retest.
- An approved canary update: the supplier identifies the correct device group, documents the permitted change and obtains the agreed check before expansion.
- A denied restart: the update remains in a pending state with a receiving owner; the task does not close as fully verified.
- An offline device: the endpoint remains in the denominator with a retry or contact plan.
- A failed installation: the receiving engineer documents the fault and escalation, and wider deployment follows the agreed stop decision.
- An application fault after an update: the application owner is contacted and recovery follows the separately approved path.
- An out-of-cycle request: urgency, business approval, coverage and any additional charge are resolved under the proposed order.
The MSP and supplier choose safe cases and authorized devices. Agree what each result must show before accepting the operating scope; this page supplies no tenant access, execution instruction or prefilled outcome.
Put the whole workload in the order
Include the device and software inventory, maintenance groups, approval and restart permissions, covered window, completion checks, failed-change handling and reports. Ask how repeat attempts, emergency requests, vendor coordination and retained MSP work affect the charge. The three examples above do not supply a comparable public patch-management tariff.
Use the quote worksheet for complete charges at the same workload. Keep SLA clocks separate from a planned maintenance deadline, and use the after-hours handoff for anything the next shift must accept.
For a proposed NinjaOne NOC workflow, use the NinjaOne patch-closeout guide to settle task targets, pending reboots, maintenance suppression and the accepting ticket owner.