How to Build an Incident Response Plan for Your Small Business (Template Included)

You do not want to be writing your incident response plan during a ransomware attack. That sounds obvious, yet the majority of small businesses that experience a breach have no documented plan to fall back on. The result is chaos: key decisions made under panic, critical evidence destroyed, notifications delayed, and avoidable costs compounding by the hour. Businesses with a tested incident response plan consistently achieve shorter containment times, lower total incident costs, and faster recovery than those improvising in the moment.

A small business does not need a 200-page NIST-compliant incident response policy. It needs a clear, practical document that tells your team exactly what to do in the first hours of a breach — who calls whom, what gets shut down, how you communicate, and how you recover. This guide walks you through building that plan step by step, with a template structure you can adapt immediately for your business.

The Six Phases of an Effective Incident Response Plan

The NIST Computer Security Incident Handling Guide defines a standard incident response lifecycle that works well for businesses of any size. Adapted for small businesses, the six phases are:

1. Preparation: Building the plan, training the team, and putting tools in place before an incident occurs.
2. Identification: Detecting that an incident has occurred and determining its nature and scope.
3. Containment: Limiting the spread and impact of the incident — stopping the bleeding.
4. Eradication: Removing the threat from your environment — eliminating malware, closing the attack vector, removing unauthorized access.
5. Recovery: Restoring affected systems and verifying they are clean before returning to production.
6. Post-Incident Review: Analyzing what happened, why it happened, and what you will do differently to prevent or better handle a recurrence.

Your incident response plan should have a documented playbook for each phase, tailored to the most likely incident types for your business. Most small businesses should have playbooks for at minimum: ransomware, phishing compromise, data breach, and business email compromise.

Building Your Incident Response Team

Incident response requires clearly defined roles. In a small business, one person may fill multiple roles — that is fine, but the roles must be explicitly assigned so there is no confusion under pressure.

Incident Response Lead (IR Lead)

Owns the overall response. Coordinates between technical, legal, and communications functions. Makes decisions about containment, eradication, and recovery sequencing. Typically the IT manager, IT consultant, or a senior operations leader in the absence of dedicated IT staff.

Technical Responder

Investigates the incident technically — identifies affected systems, performs forensic triage, executes containment and eradication steps. In a small business, this may be your IT consultant or a retained managed detection and response (MDR) service.

Business Lead / Executive Sponsor

Ensures business continuity decisions are made with appropriate authority. Authorizes significant resource expenditure (engaging external incident response firms, paying for emergency IT services). Communicates with the board or ownership.

Legal and Compliance Contact

Advises on breach notification obligations, regulatory requirements, and insurance claim management. This may be your business attorney and/or cyber insurance broker.

Communications Lead

Manages internal communications to employees and external communications to customers, partners, and media (if applicable). Ensures messaging is accurate, timely, and appropriate.

Before an incident occurs, document each role with name, primary contact number, backup contact, and escalation path. Store this document somewhere accessible offline (not only on systems that might be compromised).

The First 30 Minutes: Identification and Initial Response

The first 30 minutes of an incident are the highest-value time in the entire response. Your actions during this window significantly determine the total impact. Here is a practical first-30-minutes checklist:

• Declare an incident: If something looks like a security incident, treat it as one until proven otherwise. False alarms are infinitely less costly than delayed responses. Alert your IR Lead immediately.
• Do not touch, click, or delete anything on affected systems: Instinctive reactions — opening unknown files, clicking on things to 'see what happened,' or running antivirus scans that overwrite forensic evidence — can destroy valuable evidence. Notify IT before touching anything.
• Isolate affected systems: Disconnect affected systems from the network by unplugging Ethernet cables or disabling Wi-Fi. Do not power them down if possible — memory forensics may be needed. Isolation is the most critical containment step.
• Take photographs of affected screens: Before doing anything else, photograph any ransom notes, error messages, or anomalous screens with your phone. These may be needed for law enforcement or insurance.
• Call your technical responder: Your IT consultant, managed service provider, or MDR service should be notified immediately. They will guide the technical investigation and contain the incident.
• Alert your IR Lead and executive sponsor: The business needs to know this is happening. Early involvement of leadership enables rapid resource authorization.

Containment, Eradication, and Recovery

Once the immediate crisis is stabilized and the incident is scoped, the response moves through containment, eradication, and recovery in sequence.

Containment Strategy

Short-term containment (first hours): isolate affected systems and block identified malicious IPs and domains at the firewall and DNS layer. Long-term containment: maintain isolation while forensic investigation proceeds. Change all potentially compromised credentials. Review and tighten access controls to limit further lateral movement.

Eradication

Remove the root cause of the incident. This typically means: removing identified malware and attacker tools from affected systems, closing the vulnerability or misconfiguration that was exploited, removing unauthorized user accounts or backdoors the attacker created, and patching the affected systems. Eradication must be complete before recovery begins — rushing to restore systems before eradication risks immediate reinfection.

Recovery

Restore affected systems from known-clean backups. Verify backup integrity before starting. Restore in order of business criticality. Before reconnecting a restored system to the network, run a clean endpoint scan and confirm no indicators of compromise remain. Monitor closely for 72 hours post-recovery — attackers sometimes leave dormant access points.

Define your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) in advance. How long can your business operate without specific systems? How much data loss is acceptable? These parameters guide your backup strategy and recovery sequencing. See our guide on backup and disaster recovery planning for detail on setting RTO and RPO targets.

Notifications and Legal Obligations

Data breach notification requirements are one of the most time-sensitive legal obligations in incident response. Most jurisdictions have mandatory notification timelines, and missing them can add regulatory penalties on top of incident costs.

Key Notification Obligations

• GDPR (EU/EEA): Notify your supervisory authority within 72 hours of becoming aware of a personal data breach. Notify affected individuals without undue delay if the breach poses high risk to their rights and freedoms.
• US State Laws: Notification requirements vary by state. California, New York, and Texas have among the most stringent requirements. Most US states require notification within 30 to 90 days. A cyber attorney should advise on applicability.
• Canada (PIPEDA/CPPA): Report breaches with real risk of significant harm to the Privacy Commissioner of Canada and affected individuals as soon as feasible.
• UK GDPR: Same 72-hour supervisory authority notification requirement as EU GDPR post-Brexit.
• Australia (NDB Scheme): Notify OAIC and affected individuals as soon as practicable after determining a breach is eligible.

Cyber Insurance Notification

Notify your cyber insurer as soon as an incident is detected — ideally within hours. Most policies require prompt notification and may require pre-approval before engaging external incident response or legal services. Delayed notification is one of the most common reasons cyber insurance claims are complicated or denied.

Internal Communications

Brief your employees before external notifications go out. Employees who hear about a breach from a customer before management has communicated internally feel blindsided and their trust is damaged. Keep communications factual, calm, and action-oriented.

Incident Response Plan Template: Key Sections

Your incident response plan document should include the following sections at minimum. Use this as your template structure:

• 1. Purpose and Scope: What incidents this plan covers, what assets and data are in scope, and who this plan applies to.
• 2. Incident Response Team: Roles, names, primary and backup contact numbers, and escalation paths. Include your external contacts: IT consultant or MSP, cyber insurer, legal counsel.
• 3. Incident Classification: A simple severity matrix (P1: critical — full business impact; P2: high — significant impact; P3: medium — limited impact; P4: low — minimal impact). Define response time targets for each level.
• 4. Incident Response Playbooks: Specific step-by-step response procedures for each incident type: ransomware, phishing compromise, data breach, BEC fraud, DDoS attack. Each playbook should cover identification indicators, containment steps, eradication steps, recovery steps, and notification triggers.
• 5. Communication Templates: Pre-written internal and external notification templates that can be quickly adapted. Having these ready removes the cognitive load of drafting under stress.
• 6. Contact List: All relevant contacts: IR team members, IT support, legal counsel, cyber insurer, local law enforcement cybercrime unit, relevant regulatory bodies.
• 7. Post-Incident Review Template: A standard format for capturing what happened, what worked, what did not, and what you will change. Schedule the review within two weeks of incident resolution.

Store the plan in at least two offline-accessible locations — a printed copy and an encrypted offline drive. A plan that lives only in your cloud systems may be inaccessible exactly when you need it most. To get help building a plan tailored to your business, contact us for a free consultation.

Frequently Asked Questions

How long should an incident response plan be?

For a small business, an effective incident response plan is typically 10 to 20 pages including playbooks for the key incident types. Conciseness is a virtue — a short plan that gets used is far better than a comprehensive one that nobody reads. Focus on the identification-containment-eradication-recovery sequence for your top three to five incident scenarios, clear role assignments, and essential contacts.

How often should we update and test our incident response plan?

Review and update the plan at least annually, and after any significant incident, major infrastructure change, or key personnel change. Test the plan through tabletop exercises at least once per year — ideally twice. A tabletop exercise walks your response team through a simulated incident scenario in a meeting room, identifying gaps in the plan and building response familiarity without a real incident. Track what each exercise reveals and update the plan accordingly.

Does a small business need to hire an external incident response firm?

For major incidents — ransomware with significant business impact, confirmed data breach with customer personal data, or a sophisticated targeted attack — engaging an external incident response firm is strongly recommended. They have tools, experience, and threat intelligence that internal teams or general IT consultants typically lack. Many cyber insurance policies include access to an approved IR firm as part of coverage. For minor incidents, a competent managed service provider or IT consultant can handle response.

What is the difference between a disaster recovery plan and an incident response plan?

An incident response plan focuses on detecting, containing, and eradicating a cybersecurity threat — it is primarily a security response process. A disaster recovery plan focuses on restoring business operations after any disruptive event (not just cyber incidents, but also natural disasters, hardware failures, or power outages). They overlap but serve different purposes. A complete business resilience strategy includes both, often alongside a Business Continuity Plan (BCP) that addresses how to maintain operations during an extended disruption.

What should we do in the first 24 hours of a ransomware attack?

In the first 24 hours: isolate affected systems from the network immediately; do not power them down; photograph ransom notes and affected screens; notify your IT team or MSP; alert your cyber insurer; verify backup integrity to determine recovery options; brief your executive team; engage external IR support if needed. Do not pay any ransom without consulting your insurer and legal counsel first. Speed of containment is the single biggest factor in limiting total damage.

Is there a legal requirement for small businesses to have an incident response plan?

In many jurisdictions and industries, yes. Organizations subject to GDPR, HIPAA, PCI-DSS, SOC 2, or various financial services regulations have explicit requirements to have documented incident response capabilities. Even without a direct legal mandate, having a plan is typically required for cyber insurance and is increasingly expected by enterprise customers as part of vendor due diligence. Beyond compliance, it is simply sound risk management.