Incident Response Plan Template (for SMBs)

What an incident response plan should do (and why most SMB plans fail)

An incident response plan is a written, pre-approved playbook for how your organization detects, responds to, and recovers from incidents. The key word is pre-approved. During an event, your team is under pressure, information is incomplete, and every action can affect downtime, data loss, and liability. A good plan removes uncertainty by defining who decides, who executes, and how communications happen across IT, leadership, vendors, and insurers.

SMB plans often fail for simple reasons. They are too generic, they are hidden in a folder nobody opens, or they treat incident response as an IT-only activity. Real incidents hit multiple functions: operations needs systems restored, finance needs to understand exposure, HR may handle employee impact, compliance needs documented decisions, and executives must approve time-sensitive choices. When the plan is vague, teams either freeze or improvise, and both outcomes increase cost.

The goal is not a perfect binder. The goal is a usable system: a one-page summary for fast execution, plus deeper runbooks for the incidents you are most likely to face (phishing, business email compromise, ransomware, lost devices, and SaaS account takeover). If you build it that way, you can run tabletop exercises, improve weak links, and shorten recovery time.

The incident response lifecycle you can actually operationalize

Most practical incident response programs follow a simple lifecycle: preparation, detection and analysis, containment, eradication, recovery, and post-incident improvement. You do not need a massive enterprise program to use this structure. You need a consistent rhythm so incidents do not become one-off fire drills.

Preparation is where SMBs win. If you pre-stage access, logging, backups, escalation paths, and decision authority, you cut the time spent searching for information when it matters most. Detection and analysis is where you confirm what is happening, prioritize the incident, and decide the first containment actions. Containment, eradication, and recovery are where you stop the bleeding, remove the cause, and bring services back safely. Post-incident activity is how you convert pain into improved controls, better runbooks, and fewer repeats.

Quick start: the 1-page incident response plan (copy this first)

Before you write long runbooks, build a one-page IRP summary. This is the page you print, store in a shared location, and keep offline. It tells anyone what to do in the first moments of a suspected incident, even if key people are unavailable.

[ONE-PAGE INCIDENT RESPONSE PLAN SUMMARY]

Organization:
Plan owner:
Version:
Last updated:
Approved by:

1) Declare an incident (trigger)
- Examples: suspected account takeover, ransomware note, data exfiltration alert, vendor breach notice, unusual outbound traffic, repeated MFA prompts, missing devices.
- Who can declare: ______________________
- How to declare: Teams channel / phone tree / incident ticket / SMS group

2) Incident commander (IC)
- Primary: ______________________  Backup: ______________________
- IC responsibilities: assign roles, set severity, approve containment actions, run status cadence, document decisions.

3) Severity level (pick one)
- SEV-1: safety/legal risk, widespread outage, ransomware, confirmed data exfiltration
- SEV-2: limited outage or compromise, high-risk identity event
- SEV-3: suspicious activity, contained malware, single device compromise
- SEV-4: low-risk alert, false positive, routine security task

4) First containment actions (do not wait)
- Disable affected accounts and revoke sessions (identity team)
- Isolate impacted endpoint(s) from network (endpoint team)
- Preserve evidence: keep logs, snapshots, copies of emails (forensics lead)
- Notify leadership and communications lead (comms lead)

5) Critical contacts (24/7)
- MSP / IT partner: ______________________
- Cyber insurance hotline: ______________________
- Legal / breach coach: ______________________
- PR / communications support: ______________________
- Cloud vendor support (Microsoft, etc): ______________________
- Law enforcement (if applicable): ______________________

6) Status cadence
- SEV-1: every 30 minutes
- SEV-2: every 60 minutes
- SEV-3: twice daily
- SEV-4: weekly review

7) Recovery principle
- Restore clean first, then reconnect.
- Do not re-enable accounts or systems until containment and root cause are verified.

8) Post-incident review
- Hold within 5 business days.
- Assign remediation owners and due dates.

Define roles, responsibilities, and decision rights (RACI for SMBs)

The most common incident response failure is unclear ownership. Someone sees a suspicious alert, but no one knows who can approve containment actions like disabling accounts, isolating machines, or pausing email forwarding rules. Your plan should define a small incident response team with explicit decision rights. In SMBs, one person often holds multiple roles. That is fine, as long as you name backups.

Start with these core roles: incident commander, technical lead, identity lead (Microsoft 365 and Entra ID), communications lead, and executive sponsor. Add optional roles as needed: privacy or compliance lead, HR lead, vendor liaison, and finance lead (especially if cyber insurance is involved).

Create a severity matrix with response targets you can meet

Severity is how you turn a flood of alerts into a manageable queue. The goal is not to over-classify everything as urgent. The goal is to align severity to business impact and risk, then attach response targets that fit your staffing reality. If you have a 24/7 SOC or MDR service, you can hold faster response targets. If you do not, your plan should specify what happens after hours and who is on-call for true emergencies.

Below is a practical severity matrix you can adapt. Use examples that match your environment: Microsoft 365 account takeover attempts, suspicious mailbox rule creation, unusual outbound data transfer, and ransomware indicators on endpoints or servers.

Build your contact list and escalation tree (include insurers and vendors)

During an incident, people waste time hunting for phone numbers, support portals, and contract details. Your plan should include a single contact list with after-hours information. Keep a copy offline in case your email or file systems are impacted. If you have cyber insurance, confirm your policy requirements in advance. Many policies require that you contact their hotline quickly and use approved vendors, and delays can complicate claims.

Communications: scripts, approvals, and what not to say

Communications is a control, not a nice-to-have. Poor messaging can increase liability, confuse employees, and compromise an investigation. Your plan should specify who communicates internally, who communicates externally, and who approves each message type. It should also include pre-written scripts for common scenarios so you are not writing from scratch at 2 a.m.

For SMBs, you typically need four communication streams: employees, customers or partners, vendors, and leadership. In regulated industries, you may also need to notify a privacy office, regulator, or professional body depending on the nature of the incident. Your legal and privacy counsel should review this part of the plan so you do not accidentally admit fault, confirm details that are not verified, or share information that assists an attacker.

Microsoft 365 focused runbooks (identity and email come first)

For Microsoft 365 centric SMBs, many incidents start with identity or email: phishing, MFA fatigue, OAuth consent abuse, mailbox rule manipulation, or credential reuse. That is why your incident response plan should include a Microsoft 365 runbook that emphasizes rapid containment, evidence preservation, and least-privilege admin access.

The goal is not to memorize every portal. The goal is to define a repeatable set of actions: identify impacted accounts, stop attacker sessions, block persistence mechanisms, and document what you did. If you use Microsoft Defender, Sentinel, or an MDR service, align your plan to how alerts are triaged and how escalations happen after hours. If you do not have 24/7 monitoring, your plan should specify triggers that wake someone up.

Technical playbooks for the incidents SMBs face most often

Your plan should include short playbooks for your top incident types. Each playbook should answer four questions: how do we detect it, how do we contain it, how do we eradicate it, and how do we recover? Keep the playbooks action-oriented, with decision points, not long theory. Below are three high-impact playbooks you can copy and tailor.

Playbook A: ransomware or suspected encryption activity

• Contain: isolate impacted endpoints and servers from the network. Disable compromised accounts and remove admin privileges if needed.
• Preserve: capture a snapshot of impacted systems where possible, export logs, and store copies offline. Do not wipe before collecting evidence.
• Scope: identify patient zero, shared drives affected, backup exposure, and whether data exfiltration indicators exist.
• Decide: engage cyber insurance and legal early. Define decision authority for downtime tradeoffs and restoration sequencing.
• Recover: restore from known-good backups, validate integrity, patch root cause, rotate credentials, and monitor for reinfection.

Playbook B: business email compromise (BEC) and invoice fraud risk

• Contain: disable sign-in or reset credentials, revoke sessions, and remove suspicious MFA methods.
• Remove persistence: delete suspicious inbox rules, forwarding settings, and unknown OAuth app grants.
• Search for impact: identify recipients of malicious emails, check for payment instruction changes, and lock down finance workflows.
• Communicate: notify internal teams to validate payment changes out-of-band. If fraud occurred, contact your bank immediately.
• Harden: enforce MFA, conditional access, and disable external forwarding if possible. Train targeted departments (finance, executive assistants).

Playbook C: lost or stolen laptop, phone, or tablet

• Contain: revoke sessions and tokens, disable the account if compromise is suspected, and trigger remote lock or wipe.
• Validate protections: confirm full disk encryption, device compliance status, and whether local data was accessible offline.
• Scope: review sign-in logs for unusual access after the loss event.
• Recover: issue replacement device, re-enroll, and rotate credentials for sensitive accounts.

Evidence handling and documentation (make it easy to prove what happened)

Evidence preservation is not only for large enterprises. For SMBs, good documentation protects you during insurance claims, audits, and customer inquiries, and it helps you avoid repeating the incident. Your plan should define a simple chain-of-custody process: what evidence you collect, who collects it, where it is stored, and who can access it.

Keep it practical: log exports, screenshots, message traces, and a timeline of actions taken. Do not store evidence only in systems that could be compromised during the incident. Maintain an offline or segregated storage location for incident artifacts. Assign one person as documentation lead if possible, or ensure the incident commander maintains a decision log.

[CHAIN OF CUSTODY / EVIDENCE LOG]

Incident ID:
Date opened:
Collected by:
Storage location (secure):

Item # | Evidence type | Source system | Time range | Hash/identifier | Access restrictions | Notes
1      | Sign-in logs  | Entra ID      |            |                 |                     |
2      | Audit logs    | Microsoft 365 |            |                 |                     |
3      | Email trace   | Exchange      |            |                 |                     |
4      | Disk image    | Endpoint      |            |                 |                     |
5      | Screenshots   | User report   |            |                 |                     |

Decision log:
Timestamp | Decision | Approved by | Evidence used | Follow-up action | Owner

Recovery and restoration: how to avoid reinfection and repeat outages

Recovery is where many SMBs unintentionally prolong incidents. The urge to “get back online” can cause teams to reconnect systems before the root cause is removed. That is how reinfection happens, and why some incidents come in waves. Your incident response plan should define a recovery principle: restore clean first, validate, then reconnect.

Tie your incident response plan to your backup and disaster recovery approach. If you are not regularly testing restores, your backup strategy is a hope, not a control. Define which systems get restored first and why: identity services, critical business applications, file stores, and then user endpoints. Align recovery targets (RTO and RPO) to business needs, not guesses. If your current MSP or internal process cannot meet those targets, that is a signal to redesign.

Testing and maintenance: the plan that is not exercised is not a plan

A plan that has never been exercised will fail at the exact moment you need it. Testing does not need to be expensive. Start with a quarterly tabletop exercise: walk through a realistic scenario with leadership, IT, and operations. Focus on decision points, not technical detail. Ask: who declares the incident, who approves containment, how do we contact insurance, and what do we tell employees?

Then schedule an annual technical exercise that validates backups, account lockdown procedures, and evidence collection. Every major change is also a trigger: new Microsoft 365 security policies, a new backup vendor, a new line-of-business application, or a switch of MSP. Treat your IR plan like a living system that is versioned, reviewed, and approved.

FAQ: incident response planning for SMBs

References and further reading

If you want to validate your plan against widely used public guidance, these are strong starting points:

• Canadian Centre for Cyber Security: Developing your incident response plan (ITSAP.40.003)
• CyberSecure Canada: Develop an Incident Response Plan (fillable template and example)
• NIST SP 800-61 Rev. 3: Incident response recommendations
• CISA: Incident Response Plan (IRP) Basics (PDF)
• Get Cyber Safe: Guide for small businesses (Canada)