Incident Response Plan Template (SMB)

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.

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.

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.

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.

• 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.

Another pitfall is treating the IR plan as a compliance checkbox rather than an operational tool. A plan that sits in a shared drive and is never tested, updated, or referenced during real incidents provides a false sense of security. The plan should be a living document that your team can actually use under stress, which means it needs to be short, current, and familiar. A one-page reference card with roles and first actions is more useful during an incident than a thirty-page binder that nobody has read.

Cross-functional ownership is also important. If the IR plan is owned solely by IT, other functions like legal, HR, and executive leadership may not understand their roles until an incident forces them to figure it out in real time. Ensure that the plan has named owners in each function, that those owners have reviewed and understood their responsibilities, and that the contact list is validated at least quarterly.

Finally, do not confuse having a plan with having capability. A plan that has never been tested is a plan you cannot rely on. Schedule at least one tabletop exercise per year, use the findings to update the plan and prerequisites, and track improvement actions to completion. The cycle of plan, test, improve is what turns a document into an operational capability that actually reduces incident impact.

Your IR plan defines how you coordinate. Playbooks define what you actually do for specific scenarios. Start with the incidents most likely to hit your organization, not an exhaustive list.

Ransomware is the scenario most organizations should tackle first. The playbook should cover isolation decisions, communication timing, backup validation steps, and when to involve legal counsel and law enforcement. The key question the playbook answers is: who makes the call to shut things down, and what does IT do in the first thirty minutes before that call is made?

Business email compromise is the most common incident type for SMBs. The playbook should cover session revocation, mailbox audit, scope assessment (what did the attacker access or forward), and stakeholder notification. BEC incidents often require quick internal communication because the compromised account may have been used to request payments or share sensitive information.

Lost or stolen devices are frequent but often handled inconsistently. The playbook should specify how to remote-wipe or disable a device, how to assess what data was on it, and when the incident warrants broader notification. A clear playbook prevents the common outcome where a lost laptop is reported to IT but nobody checks whether the device had access to sensitive systems or data.

Related: ransomware preparedness, BEC guide, and remote work security.

An IR plan that has never been tested is a plan you cannot trust. Tabletop exercises are the most practical way to validate your plan without disrupting operations. The format is straightforward: present a realistic scenario, walk through the response step by step, and document what works, what breaks, and what is missing.

Choose a scenario that matches a real risk for your organization. If BEC is your biggest concern, run a scenario where a vendor email is compromised and a fraudulent payment change is discovered after hours. If ransomware is the concern, run a scenario where an employee reports encrypted files on a Monday morning. The goal is not to script a perfect response but to find the gaps in roles, communications, and access that only become visible when people have to walk through the decisions.

After the exercise, produce a short after-action report that lists specific improvements, assigns owners, and sets deadlines. Common findings include missing contact information, unclear escalation paths, insufficient logging access, and role assignments that assumed people who were unavailable during the exercise. Feed these findings back into the plan and the prerequisite checklist. Re-test at least annually, or after any major change to your identity platform, backup infrastructure, or organizational structure.

Related: incident response tabletop exercises.

How you handle evidence during and after an incident affects legal exposure, insurance claims, and regulatory obligations. The principle is simple: preserve what you can, document what you do, and avoid actions that destroy forensic value.

During containment, resist the urge to immediately reimage or wipe compromised systems. Work with your security lead or external incident response provider to capture relevant logs, screenshots, and system state before cleanup. If you have SIEM or centralized logging, confirm that the relevant time window is preserved and exported before any retention limits apply.

Document the timeline as it develops: when the incident was detected, who was notified, what containment actions were taken and when, and what decisions were made and by whom. This timeline serves double duty as both an operational record and evidence for insurance claims, customer notifications, and regulatory inquiries. Cyber insurance policies often require timely notification and may have specific evidence preservation requirements. Your plan should identify who contacts the insurer and what information they need.

Related: cyber insurance readiness and SOC operations.