N2CON TECHNOLOGY

Incident Response Plan Template (SMB)

An incident response (IR) plan is the coordination layer for bad days: who leads, how you escalate, how you communicate, and what actions you are authorized to take. This guide includes a copy/paste starter plan you can adapt to your environment.

Note: This is general information and not legal advice.

Last reviewed: February 2026
On this page

Executive Summary

What it is
A short plan that defines incident roles, communications, escalation, and first-response actions.
Why it matters
  • Most incident failures are operational: unclear authority, missing access, and confused communications.
  • It reduces time-to-containment and prevents mistakes under stress.
  • Customers, insurers, and frameworks often ask whether you have (and test) incident response.
When you need it
  • You have SaaS and email exposure (account takeover, business email compromise, ransomware risk).
  • You are doing cyber insurance renewals or answering customer security questionnaires.
  • You have after-hours risk but no clear escalation process.
What good looks like
  • Named roles (with backups) and a current contact list.
  • Clear containment authority (what IT can do immediately vs what requires leadership approval).
  • Playbooks for your top scenarios, tested via a tabletop exercise with an improvement plan.
How N2CON helps
  • Build a practical plan and playbooks aligned to your tools and risks.
  • Validate identity, logging, and recovery prerequisites so the plan is executable.
  • Facilitate tabletop exercises and turn gaps into a tracked improvement plan.

Start by defining roles and containment authority

In a small and midsize business (SMB), the fastest way to fail is to assume everyone will "figure it out" during an incident. Your plan should assign decision-making roles and confirm who has the technical access to execute.

  • Incident commander: runs the process, drives updates, and records decisions.
  • IT lead: executes containment and recovery actions.
  • Security lead: handles investigation, evidence, and logging.
  • Leadership: approves business-impact decisions (shutdowns, public statements).
  • Legal / counsel: advises on notification and regulatory obligations.
  • Communications: owns internal updates and any external statements.

Related: incident response tabletop exercises.

Define escalation and communications before you need them

Communications should be deliberate. During an incident, assume email may be compromised and chat may be unavailable.

  • Escalation: how do you reach people after-hours, and who is on-call?
  • Channels: define a backup channel (phone tree, alternate chat, emergency email).
  • External contacts: cyber insurance, counsel, key vendors, and critical customers.

Related: DNS and registrar security and identity foundations.

Include prerequisites: identity, logging, and recovery

An IR plan is only as good as your ability to execute it. If you cannot revoke sessions, see logs, or restore systems, the plan becomes a document-only exercise.

  • Identity: Multi-Factor Authentication (MFA) on admins, break-glass accounts, and recovery procedures.
  • Logging: know where authentication and admin activity is captured and retained.
  • Recovery: backups are tested and RPO/RTO expectations are realistic.

Related: MFA, SIEM, and backup testing.

Copy/paste incident response plan template

This is a starter template. Keep it short, keep contacts current, and add playbooks for your most likely scenarios.

# Incident Response Plan (SMB) - Starter Template

## 1) Purpose
This plan defines how we coordinate, communicate, contain, and recover from security incidents.

## 2) Incident roles
- Incident Commander:
- IT Lead:
- Security Lead:
- Leadership Approver:
- Legal / Counsel:
- Communications:

## 3) Contact list (keep current)
- After-hours escalation number:
- Cyber insurance:
- External counsel:
- Key vendors (email, identity, backup, MSP/MSSP):

## 4) Severity levels and escalation
- SEV-1 (Business down / active attacker): notify leadership immediately
- SEV-2 (Material risk / partial impact): notify within 1 hour
- SEV-3 (Limited scope): notify next business day

## 5) Containment authority
IT may take immediate actions to contain risk (disable accounts, revoke sessions, isolate endpoints).
Actions that materially impact business operations require leadership approval unless delay increases risk.

## 6) Communications plan
- Primary channel:
- Backup channel (assume email compromise):
- Customer communication owner:
- Internal update cadence:

## 7) Evidence and logging
- Where logs are stored:
- Who collects evidence:
- Chain-of-custody notes location:

## 8) Playbooks (attach or link)
- Ransomware
- Business Email Compromise
- Lost or stolen device
- Vendor breach

## 9) Testing and review
- Tabletop exercise frequency:
- After Action Report / Improvement Plan owner:
- Last tested date:

Related scenarios: ransomware and business email compromise.

Common pitfalls

  • No after-hours plan: the first hour is chaos because nobody can reach the right people.
  • Unclear authority: everyone waits for approval while the attacker continues.
  • Evidence drift: logs exist, but access to them is unclear or retention is too short.
  • Backups assumed: restore timelines are guessed, not tested.

Related: cyber insurance readiness.

Common Questions

Is an incident response plan the same as a playbook?

Not exactly. Your incident response (IR) plan defines roles, escalation, communications, and how you coordinate. A playbook is scenario-specific (for example: ransomware, business email compromise, or lost device) and plugs into the plan.

How long should an SMB incident response plan be?

Short. The goal is a plan people will actually use under stress. Start with one page of roles, contacts, and first actions, then add playbooks for your highest-risk scenarios.

How often should we test incident response?

At least annually, and after major changes (identity platform, backups, mergers, or major vendor changes). A tabletop exercise is a low-risk way to validate roles, communications, and decision-making.

Should we notify customers or regulators during an incident?

Sometimes. Notification requirements vary by what data is involved, what happened, contracts, insurance requirements, and jurisdiction. Your plan should define who makes notification decisions and how you involve legal counsel.

Want an IR plan that matches your tools and works after-hours?

We can help you define roles, build playbooks, validate access, and run a tabletop exercise that turns into an improvement plan.

Contact N2CON