MSP Incident Response Plan Template: Who Calls, Who Acts, and What the Client Owns
An incident response plan is not a PDF you admire until somebody calls at 2:13 a.m.
It is the answer to a few rude questions before the incident starts: Who can take a system offline? Who tells the client? Who calls the carrier? Who decides whether the event is a breach? What work is included, and what becomes a separate incident project?
If those answers live in three contracts, an account manager's head, and a half-finished Teams thread, the MSP gets pulled into decision-making without authority. That is how a technical emergency turns into free executive consulting.
The template below is for the vCIO or strategic account lead who needs a client-ready answer before the first breach call. It complements the technical runbook. The engineer still needs tooling, logs, and containment steps. The client still needs counsel for legal and notification decisions. Your job is to make the handoffs explicit.
CISA's incident response plan basics and NIST's incident-response guidance both put preparation, defined roles, communications, and continual improvement at the center of response. For an MSP, that starts with an ownership map the client can actually read.
What this template is for
Use this template when a client has an incident-response clause, cyber-insurance questionnaire, compliance requirement, or an upcoming business review, but the actual call tree is still fuzzy.
It is not a substitute for legal advice, an insurance policy, a digital-forensics retainer, or your signed agreement. It is the operating map that keeps everyone from assuming the other party made the decision.
A useful plan should let your team answer five questions in the first call:
- What happened, and what evidence do we have?
- Who is leading the technical response?
- Which decisions need a client executive, counsel, carrier, or vendor?
- What do we tell staff, customers, regulators, or the board, and who approves it?
- What response work is included now versus scoped separately?
The ownership map: who calls, who acts, who decides
Do not write "MSP handles incident response" into a plan and call it a day. That sentence is a liability generator with good typography.
Start with this ownership map. Replace the role names with the actual people, service scope, escalation channels, and response hours in the client agreement.
| Role | Owns in the first response | Can decide | Must not decide alone |
|---|---|---|---|
| MSP technical incident lead | Preserves evidence, coordinates technical triage, recommends containment, keeps the response timeline | Immediate technical actions already authorized in the agreement | Whether an event is legally reportable, what the client discloses, or business shutdown priorities outside agreed authority |
| MSP service or account lead | Keeps one response record, confirms service scope, coordinates client updates and vendors | When to raise the incident to the client sponsor and when to request separate incident scope | Technical root cause, legal notification language, or client risk acceptance |
| Client executive sponsor | Sets business priorities, approves material downtime and business tradeoffs, names the client decision owner | Whether to accept operational impact, fund emergency work, or authorize business communications | Technical facts they have not reviewed or legal advice without counsel |
| Client legal counsel and carrier contact | Advises on notification, privilege, insurer conditions, and external statements | Legal and insurance response path | Technical containment or forensic conclusions without the response team |
| External incident-response partner | Provides agreed forensic, containment, or recovery support | Work inside its statement of work | Client communications or contract decisions unless specifically engaged |
| Critical vendor | Provides product-specific logs, outage facts, token resets, and support actions | Vendor-side containment in its service | The client's breach determination or communications |
The important line is between acting and deciding. The MSP can often act quickly on a known technical condition. The client still owns business priorities, risk acceptance, public statements, and decisions reserved by contract or law.
For the broader responsibility split, use a shared responsibility matrix. The incident plan is where that matrix gets a clock and a phone number.
Copyable MSP incident response plan template
Keep this in the client record, not in a folder that only one engineer can find. Fill it out during onboarding, refresh it in the QBR, and use the actual agreement language when responsibilities change.
| Plan field | What to record | Example prompt for the client review |
|---|---|---|
| Scope and trigger | Which systems, services, locations, users, and events trigger this plan | "Does a suspected Microsoft 365 account takeover trigger this plan, or only a confirmed incident?" |
| Technical incident lead | Primary and backup MSP response lead, after-hours contact, and authority already granted | "Who can authorize an emergency account disable if we cannot reach you for 20 minutes?" |
| Client decision owner | Executive sponsor plus backup who can approve downtime, emergency spend, and business priorities | "Who can decide whether the finance system stays offline until tomorrow?" |
| Counsel and carrier path | Legal contact, carrier hotline, policy number location, and who may call | "Does the policy require notice before outside forensic work begins?" |
| Communications owner | Who drafts the status, who approves it, and the update cadence | "Who receives the first update, and when do they hear from us again if facts have not changed?" |
| Evidence record | Incident ID, timestamps, affected systems, logs preserved, vendor notices, and decisions | "Where do we keep the timeline so the client, MSP, and counsel are not working from different stories?" |
| Containment authority | Pre-approved technical actions and actions needing client approval | "Can we revoke sessions, disable accounts, or isolate a device before the executive sponsor responds?" |
| Service boundary | Included triage versus billable incident analysis, after-hours work, forensics, recovery, or communications support | "What turns this from a support event into a scoped incident project?" |
| Recovery decision | Who accepts restoration order, residual risk, and return-to-service criteria | "Who says the line-of-business app is ready to return, and what evidence do they need?" |
| Review date | Next tabletop date and the owner who updates the plan after an incident | "What changed since the last exercise: people, vendors, scope, insurance, or business priorities?" |
The plan is deliberately more specific than "call the MSP." A client needs to know whether the MSP is calling them to inform them, request a decision, or ask them to activate counsel and insurance. Those are different calls.
The first-hour sequence
The first hour is not the moment to debate every responsibility. It is the moment to use the map.
- Open one response record. Capture the report time, reporter, affected client, known systems, and the person running technical triage. Stop parallel facts from becoming competing narratives.
- Preserve the facts you have. Save alerts, timestamps, relevant logs, screenshots, vendor notices, and the original report. Label what is observed versus what is assumed.
- Contain only within authority. Take pre-approved emergency actions. If an action would materially affect the business, raise it as a named client decision with the consequence of waiting.
- Call the client decision owner with a useful ask. "We need approval to isolate these three devices for the next two hours" is a decision. "We have an incident" is not.
- Start the counsel and carrier path when the trigger says to. Do not improvise policy or notification requirements from memory.
- Set the next update time. A calm update can be short: what we know, what we are checking, what we need decided, and when the next update arrives.
The specific technical sequence will change by client. The decision rhythm should not.
How to keep emergency response from becoming free work
Basic triage may belong inside the service agreement. A client-specific investigation across email, identity, endpoints, cloud logs, vendors, legal coordination, executive updates, and recovery planning is not "just one ticket." It is incident work.
Write the boundary before you need it:
| Usually included by agreement | Usually a separate incident project |
|---|---|
| Receive the alert, confirm the client and system, preserve initial evidence, take pre-authorized containment actions, send the first factual update | Multi-system investigation, forensic evidence package, after-hours command, legal or insurer coordination, client-specific exposure analysis, executive briefings, recovery design, user outreach, and remediation projects |
Do not use this table to nickel-and-dime a client in trouble. Use it to keep the initial response fast and the expanded work honest. If the incident reveals unknown ownership, stale evidence, or a gap in the agreement, put that work in front of the client as a decision instead of silently absorbing it.
A tabletop exercise the owner will actually attend
A tabletop does not need a conference room full of dramatic breach theater. Run one around a client condition the owner recognizes.
Scenario: A finance employee reports repeated Microsoft 365 sign-in prompts. The MSP sees a new inbox rule and unusual session activity. The client has payroll due tomorrow morning.
Ask these questions in order:
- Who opens the incident record and leads technical triage?
- Can the MSP revoke sessions and disable the account immediately? If not, who approves it and how fast?
- Who decides whether payroll can wait while the team contains the account?
- Who calls the carrier and counsel if the facts cross the agreed trigger?
- Who approves the first employee or customer communication?
- What evidence must be preserved before anyone changes the environment?
- Which response tasks are inside the service agreement, and which need a separate incident scope?
- What must change in the client roadmap after the incident closes?
The value is not proving that every person remembers a phone number. The value is exposing where a real decision has no owner.
Turn the post-incident review into a client decision
After containment and recovery, do not close the ticket with "monitor for 30 days" and hope the lesson survives.
Create a short client review with four headings:
- What happened: confirmed facts, affected systems, and what remains unknown.
- What worked: people, controls, evidence, or approvals that made the response faster.
- What failed or delayed the response: missing authority, missing logs, unclear client ownership, stale contacts, or scope gaps.
- What the client needs to decide next: remediation now, roadmap timing, accepted risk, or paid discovery.
That is where Scopable's GRC workflow fits: it keeps frameworks, evidence signals, open gaps, client summaries, and the next remediation decision tied to the client record. The MSP still owns the judgment. The client still owns the business decision.
If you want the incident review to turn into a roadmap item, scoped remediation, or documented accepted-risk decision without rebuilding the client story from scratch, start Scopable for free.
