14-day RMM trial · No card

Start free
← All guides

Incident response · 14 minute read · free CSV

RMM incident response checklist for MSPs

A suspected RMM compromise can cross customer, identity, endpoint, automation, and remote-access boundaries at once. This workflow keeps containment fast while preserving scope, evidence, authority, and recovery accountability.

Last reviewed November 1, 2026Vendor-neutral · not legal or forensic advice

Eight stages from readiness to corrective action

Adapt the sequence to the incident, customer agreements, legal obligations, insurer requirements, and qualified response guidance. The checklist does not replace an approved incident response plan, EDR, identity controls, backup, forensic support, or the customer's decision authority.

1. Prepare before the RMM becomes an incident channel

Document tenants, endpoint groups, privileged roles, integrations, deployment paths, logging sources, emergency contacts, and the authority to isolate or disable access before an alert forces the decision.

  • Name the incident lead, technical lead, customer contact, legal or insurer contact, communications owner, and recovery approver.
  • Keep an independent contact and coordination path that does not depend on the suspected RMM tenant, agent, identity provider, or technician workstation.
  • Record how to revoke sessions, credentials, API tokens, deployment packages, automations, scripts, remote-access paths, and agent enrollment authority.

2. Declare the incident and preserve a decision log

Create one incident identifier and timestamped record. Separate observed facts from hypotheses, decisions, actions, owners, and requested approvals so urgency does not erase the evidence chain.

  • Record the first signal, source, time, reporter, affected tenant or site, suspected action, and current confidence.
  • Freeze routine changes that could overwrite evidence or make the affected population harder to reconstruct.
  • Define severity, escalation triggers, notification obligations, and who can change the incident scope.

3. Reconstruct the intended and observed scope

Start from the authorized population, then compare it with enrolled agents, active sessions, job targets, automation history, remote connections, technician activity, and endpoints that are offline or otherwise unknown.

  • List affected and potentially affected customers, sites, endpoints, identities, jobs, scripts, policies, packages, and integrations.
  • Preserve unknown, offline, excluded, stale, duplicate, and newly enrolled endpoints as explicit states rather than silently dropping them.
  • Record the time range and evidence source for every scope statement.

4. Contain through a trusted control path

Choose containment actions that reduce attacker reach without destroying the records needed to understand the event. If the console or its identity path may be compromised, do not rely on it as the only containment mechanism.

  • Revoke or restrict suspected technician sessions, credentials, tokens, automations, remote-access tools, and enrollment packages through a verified path.
  • Use approved EDR, identity, network, cloud, or local controls when the RMM cannot be trusted to contain itself.
  • Document every isolated endpoint, disabled function, customer impact, exception, approval, and rollback condition.

5. Preserve and correlate evidence

Collect the records needed to establish identity, intent, execution, target, result, and follow-on activity. Preserve original timestamps, time-zone context, source, collection method, access restrictions, and integrity evidence.

  • Capture technician activity, authentication and session records, API activity, job definitions, script revisions, targets, output, agent events, remote sessions, and relevant endpoint telemetry.
  • Export or retain evidence before normal retention, rotation, account disablement, or endpoint cleanup removes it.
  • Use qualified legal, insurer, regulatory, forensic, and law-enforcement guidance where the incident requires it.

6. Remove the cause and verify the recovery boundary

Recovery is not the same as turning the agent or account back on. Establish which identities, packages, scripts, policies, endpoints, and integrations are trusted, then restore them in bounded groups with explicit validation.

  • Rotate or reissue affected credentials, keys, tokens, certificates, packages, and enrollment secrets.
  • Validate endpoint state with independent security and operational evidence before restoring broad privileged access.
  • Use lab, canary, pilot, and broader recovery waves with pause, rollback, and stop conditions.

7. Reconcile every endpoint and customer outcome

Close the technical response only when every originally intended or potentially affected endpoint has an explained state and every customer-facing obligation has a named owner and completion record.

  • Separate recovered, unaffected, isolated, offline, removed, rebuilt, transferred, excepted, and still-unknown endpoints.
  • Confirm monitoring, alerting, patching, automation, remote access, reporting, backup, and retained integrations at the scope actually restored.
  • Record customer acceptance, residual risk, temporary controls, follow-up dates, and the authority that approved closure.

8. Correct the control system, not only the symptoms

Convert the timeline and evidence into durable changes to identity, roles, enrollment, targeting, approvals, script integrity, logging, retention, monitoring, recovery, training, vendor oversight, and customer agreements.

  • Assign each corrective action an owner, due date, verification method, and evidence location.
  • Exercise the revised plan and independent communication path before treating the action as complete.
  • Retain only the evidence and lessons justified by contracts, law, insurance, policy, and the documented recovery need.

Evaluate the evidence before wider authority

Use one authorized endpoint to test the complete response loop.

Qualified MSP and IT operators can evaluate Nizlo without a credit card on authorized lab or noncritical Windows or macOS systems. Nizlo remains Windows-first, so verify required workflow depth on each platform. Founding Tester discounts are assigned by successful paid upgrade order: the first five receive 75% off for life, the next five 50%, and the next ten 25%. Applying or starting a trial does not reserve a position.

Start the 14-day trial

Primary guidance