Operational guides, written for people who run the fleet

A patch policy that survives an audit

Most patch programs fail the same way: approvals happen, installs partially fail, nobody reconciles the difference, and the monthly report shows approval status rather than installed state. When an auditor, an insurer or a client's security officer asks for evidence, the gap becomes visible immediately.

Write the policy in measurable terms

Start by defining, per device class, the maximum time between a vendor release and installation in your environment. A workable baseline for most US small and mid-market environments is: critical and security updates on workstations within 7 days, on servers within 14 days after pilot validation, and third-party application updates within 14 days. Firmware and driver updates should be explicitly excluded from automatic deployment unless they address a known exploited vulnerability, because they carry a different risk profile.

Use rings, not a single wave

Create three approval rings. The pilot ring contains IT staff machines and one non-critical server per platform. The early ring contains roughly 10–20% of endpoints spread across departments. The broad ring is everything else. Set a 48-hour gap between pilot and early, and another 72 hours before broad. Rings turn a bad patch into an incident affecting a handful of machines rather than the whole company.

Handle reboots honestly

A patch that is installed but never activated by a reboot is not protection. Configure user-facing notifications with a limited number of deferrals, and a hard deadline with an announced maintenance window. Report separately on "installed, pending reboot" so that number cannot hide inside your compliance percentage.

Reconcile monthly

Once a month, compare three numbers per client: endpoints expected, endpoints reporting, and endpoints compliant. The difference between the first two is usually stale asset records or agents that stopped checking in — both are findings in their own right. Document exceptions with a business justification and an owner, and review them quarterly rather than letting them become permanent.

Keep the evidence

Retain patch compliance reports monthly, along with the exception register and the reboot compliance figures. Twelve months of history answers nearly every question an auditor or insurer will ask, and it takes minutes to produce if the reports are scheduled rather than assembled by hand.

Cutting alert noise without going blind

Alert fatigue is the most common reason monitoring stops working. The failure is rarely technical; it is that thresholds were set once, by default, and never tuned against how the environment actually behaves. Within weeks the team learns to ignore the channel, and then a real outage arrives in the same stream as three hundred false positives.

Measure before you threshold

Run monitoring in observation mode for one to two weeks before enabling notifications. Look at the distribution of CPU, memory and disk metrics per device class. A file server that idles at 70% memory utilization is normal; alerting at 80% will generate noise forever. Set thresholds relative to observed behavior, not to a number that felt reasonable in a template.

Add duration to every threshold

Almost no metric matters instantaneously. Require that a condition persists — five minutes for CPU, fifteen for memory, thirty for a queue depth — before an alert fires. This one change typically removes the majority of transient alerts without reducing coverage of real problems.

Suppress dependent alerts

When a host is unreachable, its service checks, disk checks and application checks will all fail. Configure dependency suppression so the parent condition alerts once and the children are muted. The goal is one alert per root cause.

Automate the top five

Rank alert types by monthly volume. For the top five, ask a specific question: what does the technician do when this fires? If the answer is a repeatable sequence — restart the service, clear the cache, re-register the agent — that alert should trigger a script first and only reach a human if the script fails. This converts recurring noise into a metric you can report as automated resolutions.

Review what nobody acts on

Every quarter, list alert types with zero remediation actions taken over 90 days. Each one is either misconfigured or unnecessary. Delete or retune them. A monitoring system that only alerts on things people act on is one people keep reading.

Route by severity and time

Not everything deserves the same channel. Informational events belong in a digest. Warnings belong in a team channel during business hours. Critical events belong on the phone of whoever is on call, with escalation if unacknowledged after a defined interval. Maintenance windows should mute expected noise on patch nights automatically.

Planning an RMM migration

Replacing an RMM platform touches every managed device and every operational workflow, so the risk is real. It is also entirely manageable with a plan that assumes coexistence rather than a cutover weekend.

Inventory what you actually use

Before evaluating anything, export three lists from your current platform: active monitor sets and their thresholds, patch policies and approval rules, and scripts with their trigger conditions. Most teams discover that a large proportion of configured monitors have not produced an actionable alert in a year. Do not migrate what you would not build today.

Define coverage parity

Write down what "no worse than today" means in specific terms: which checks must exist, which reports must be reproducible, which integrations must function. This list becomes your acceptance criteria and it protects you from discovering a gap after the old contract lapses.

Run both agents deliberately

Deploy the new agent alongside the old one on a pilot tenant. Two RMM agents can coexist, but be explicit about which one owns patching and which one owns automatic remediation during the overlap — two systems both trying to restart the same service is a self-inflicted incident. Assign ownership per function, in writing, for the overlap period.

Migrate by tenant, reconcile after each wave

Move one client or business unit at a time. After each wave, reconcile agent counts against your asset records and your billing, then confirm alert delivery is reaching the right queue. A two-week cadence across six waves is comfortable for a mid-sized fleet; six weeks total is a realistic plan for several thousand endpoints.

Mind the contract and the calendar

Check the notice period on your existing agreement before you begin, and avoid migrating during a client's fiscal close or a healthcare organization's open enrollment. If your current term has many months remaining, running a limited pilot and cutting over at renewal is usually cheaper than paying twice.

Decommission properly

When a tenant is fully migrated, export historical reports you may need for compliance, remove the old agent, and revoke its credentials and API keys. Leaving a dormant management agent installed is an unnecessary attack surface.

Pricing managed services around your tool cost

For US managed service providers, tooling is typically the second largest cost after labor, and it behaves differently: it scales with endpoints, not with revenue. Understanding that relationship is the difference between growth that improves margin and growth that erodes it.

Build a per-endpoint cost stack

List every tool that scales per endpoint or per user: RMM, endpoint protection, backup, email security, documentation, PSA. Convert each to a monthly per-endpoint figure. Then add the components that scale per technician, and any modules billed separately. The result is your true cost to deliver one managed endpoint, and it is frequently higher than providers assume because the per-seat and per-module lines are easy to overlook.

Watch for the variables that multiply

A cost model with three growing variables — endpoints, technician seats and add-on modules — compounds as you win larger accounts. A model with one variable is predictable. This is a structural argument for consolidating on tools that price per endpoint with unlimited technician accounts, and it is why our own pricing works that way: $2.00 or $3.90 per endpoint per month on annual billing, with unlimited seats and no separate patching module on Professional.

Set your margin target explicitly

A range frequently discussed in industry peer groups is 55–70% gross margin on managed services; treat that as conversation, not as a benchmark you must accept. Whatever figure you choose, work backward: if your fully loaded cost to deliver an endpoint is known, your price follows from the margin you need, not from what a competitor charges. Publish tiers that reflect real differences in delivery effort — server versus workstation, after-hours coverage, compliance reporting — rather than discounting a single flat rate.

Reprice on a schedule

Review tool costs annually and align client agreements with an annual adjustment clause. Providers who never reprice absorb every vendor increase themselves, which is how a profitable book of business quietly becomes an unprofitable one.

Count automation as capacity

Every alert resolved automatically is technician capacity you did not have to hire. Track automated resolutions per month and convert them to hours at your loaded labor rate. That number belongs in your margin analysis, and in your quarterly business reviews with clients.

Surviving a vendor security review

If you manage endpoints for healthcare, financial services, government suppliers or any enterprise supply chain, you will be assessed. Expect a questionnaire, evidence requests and questions about the tools that hold privileged access — your RMM chief among them.

Assemble the standard evidence pack once

Most reviews ask for the same artifacts: a current asset inventory, patch compliance reporting with history, proof of MFA on administrative tools, access control documentation showing least privilege, audit logs demonstrating accountability, and an incident response process. Build these as scheduled reports and stored documents rather than assembling them under deadline.

Know what your vendors can and cannot attest to

Ask each vendor directly which attestations they hold, where data resides, who their sub-processors are, and how they notify you of incidents. Be sceptical of marketing language: "HIPAA compliant software" is not a meaningful statement, because compliance is an organizational outcome, whereas "supports HIPAA safeguards through these specific controls" is verifiable. A vendor that answers "not yet" clearly is more useful than one that answers ambiguously.

Document the shared responsibility boundary

Write down which controls your provider operates and which you operate. For an RMM this means being explicit about who manages console user lists, who reviews and approves scripts, who owns patch approval decisions, and who monitors the audit log. Reviewers respond well to a clear boundary and poorly to assumptions.

Prepare for the privileged access questions

Expect specific questions about the RMM: is MFA enforced for all console users, are roles scoped to least privilege, is script execution restricted and reviewed, are sessions and script runs logged with actor and timestamp, how long are logs retained, and can logs be exported to a SIEM. If you cannot answer these today, they are your first configuration project.

Treat the review as a control test

Every question you cannot answer quickly is a genuine gap, not merely paperwork. Teams that treat assessments as an operational audit rather than a sales obstacle end up with a materially better security posture — and much shorter reviews the following year.