Incident Response Process

Last updated

Preparation: before anything burns

Incident response is decided in advance. The 2025–26 cyber insurance minimum-controls list includes an incident response plan – increasingly an exercised one – so preparation is both survival and a control your clients' carriers will ask about.

  • A written IR plan per client, stored where you can reach it when the client's network is down: severity definitions, containment authority (can you isolate machines without asking?), and the contact tree.
  • The contact tree: client executive sponsor, your incident lead, the client's breach counsel if pre-selected, and – first among equals – the client's cyber insurance carrier hotline number and policy number. Keep an offline copy.
  • First-call rule, agreed in advance: the carrier hotline gets called before any vendor is engaged. Most policies require pre-approved panel vendors; calling your favorite firm first can delay or void claim payment.
  • Your own "the MSP is popped" runbook. The CISA AA22-131A advisory exists because attackers target MSPs to reach every client at once. Per its guidance: an exercised plan, offline copies of documentation, and out-of-band communications for the scenario where your own RMM or tenant is the incident. See securing your MSP.

Roles: one incident lead per event (owner or service manager), a technical lead running containment, and a single communicator. In a small shop one person wears two hats – never all three.

Detection and triage

Incidents surface through EDR/MDR alerts, user reports ("my files have weird extensions"), backup anomalies, mailbox rules nobody created, or a client's bank flagging a payment. Triage answers four questions fast: What is affected and how widely? Is it active right now? Is data leaving? Are privileged accounts or your own tooling involved? Do not start "fixing" until you can answer these – triage determines whether this is a ticket or an event.

Severity classification

Use your standard priority matrix, with security-specific auto-escalation. These conditions make an incident P1 immediately, no judgment call required:

  • Confirmed ransomware encryption anywhere in the environment
  • Active hands-on-keyboard attacker activity
  • Confirmed or suspected data exfiltration
  • Compromise of a privileged/admin account, or of the MSP's own RMM, PSA, or documentation platform
  • BEC with a fraudulent payment in flight

Lower severities (single compromised mailbox with no lateral movement, a contained malware detection) run through normal escalation – but they get the same evidence discipline, because "contained" is a hypothesis until verified. An active security incident is a P1 under any sane SLA matrix; make sure yours says so.

Containment: isolate, don't wipe

  1. Isolate. EDR network-isolate affected hosts; for site-wide events pull WAN, disable VPN and remote access; kill file-sync clients so encrypted files stop propagating to clean copies.
  2. Cut off identities. Disable compromised accounts, revoke active sessions and tokens, reset credentials – token theft survives a password change, so revoke sessions explicitly.
  3. Preserve evidence. Do not wipe, rebuild, reimage, or delete anything. The instinct to "clean it up" destroys the forensic record that the DFIR firm, the insurer, and possibly regulators will need – and botched evidence handling creates liability for you.
  4. Activate. Trigger the client's IR plan and make the carrier hotline call now, in parallel with containment – not after.

Who leads a major incident: the carrier's panel, not you

The MSP is the first responder, not the DFIR firm. For any confirmed encryption or exfiltration, legal or regulatory exposure, or ransom negotiation, the client's policy will route the response through pre-approved panel vendors: breach counsel, a DFIR firm (Arctic Wolf IR, Kroll, ProvenData are typical), and negotiators if needed. Breach counsel typically quarterbacks the whole response so the work is legally privileged.

This structure protects everyone, including you. A small MSP should not negotiate with threat actors or run forensics alone. Your job in a major incident: preserve logs and images, provide access and tribal knowledge of the environment, execute containment and rebuilds under DFIR direction, and run the restores. If you or your clients hold IR retainers, verify the retained firm sits on the carrier's panel before signing – a retainer with an off-panel firm can be worthless when the claim matters.

Communication discipline

  • One voice. The designated communicator talks to the designated client executive on a stated cadence. Technicians don't freelance updates, speculate in writing, or use the word "breach" – a legal term of art counsel decides on.
  • Counsel reviews written statements once engaged. Regulatory notification clocks (typically 30–60 days under FTC, HHS, and state rules) are counsel's call, not the MSP's.
  • Assume email is compromised. BEC and mailbox takeovers mean the attacker may be reading incident emails. Move coordination to the pre-agreed out-of-band channel from the contact tree – phone, Signal, or an alternate tenant – the moment identity compromise is suspected.

Recovery

Recovery runs through the backup and DR process, from immutable copies – but only after DFIR confirms the attacker is evicted and the initial-access vector is identified and closed. Restoring a system with the same vulnerability, or from a backup taken after the compromise, restores the breach. Rebuild in runbook order, rotate every credential in the environment, re-enroll MFA, and monitor the restored environment closely for re-entry attempts in the following weeks.

Post-incident review and hardening

Within about two weeks, run a blameless post-incident review: timeline, initial access, what each control caught or missed, what the response got right and wrong. Two outputs: (1) a complete documentation package for the insurance claim – every action, timestamp, and decision; (2) a hardening roadmap priced as projects and presented at the next QBR as risk reduction. An incident is the one moment a client's appetite for security spending exceeds your ability to schedule the work – use it.

Your own liability

When a client is breached, the MSP gets scrutinized – expect the client, the carrier, and counsel to ask what you deployed, monitored, and missed.

  • Never sign the client's insurance attestation. Misstatements have led carriers to rescind coverage post-breach, and an MSP that wrongly attested "MFA everywhere" lands in the E&O crossfire. Provide written control status with evidence; the client's officer signs.
  • Carry your own E&O and cyber coverage – MSP-specific programs exist (SeedPod and Cork are examples) – and align your MSA's limitation-of-liability and security-incident carve-outs with that policy. Require clients to carry their own cyber insurance in the contract. More in MSP legal and insurance.
  • Document contemporaneously. Dated records are cheap during the incident and nearly impossible to reconstruct when a claim lands a year later.

Readiness cadence

  • Quarterly: verify the contact tree and carrier hotline numbers; confirm offline documentation copies are current.
  • Annually: tabletop the IR plan with each top-tier client, and run your own "RMM compromised" exercise internally.
  • At every onboarding: capture carrier, policy number, and hotline into documentation; agree containment authority in writing.
  • Continuously: evidence discipline on every security ticket, however small.

The MSPs that survive a client's worst day are the ones that made the carrier call first, contained without destroying evidence, and worked calmly under the panel's direction – all of which is decided by the preparation you do this quarter.