How to Write an Incident Response Plan Small Business Owners Use

Prerequisites and Expected Outcomes

By completing this tutorial, you will have a functional, documented incident response plan small business staff can follow during a security event. You do not need a dedicated internal security operations center to manage an emergency. You will produce a concise, operational runbook containing roles, severity levels, containment procedures, communication templates, and external contact lists.

Before you begin drafting, gather a complete inventory of your company hardware, software applications, and cloud accounts. Identify your primary data storage locations, including email systems, financial databases, and file repositories. Ensure you have the contact details for your web hosting provider, insurance broker, legal counsel, and IT managed service provider. If you have not cataloged your primary operational hazards, review how to conduct a cybersecurity risk assessment to understand your threat profile before drafting containment steps.

Define the Incident Response Team and Contact Directory

Small businesses rarely have full-time forensic analysts. Your plan must assign critical operational roles to existing personnel so that confusion does not delay containment. The NCSC small business guidance highlights that responsibility for security should never rest with a single individual, noting that one in two small businesses experience a cyber incident annually.

Assign an Incident Coordinator to lead the overall response and authorize emergency shutdowns. Assign a Technical Lead, who may be an external managed service provider, to handle host isolation and log extraction. Assign a Communications Lead, often an office manager or business owner, to manage client notices, regulatory filings, and employee announcements. Document alternative personnel for each role to prevent bottlenecks during vacations or sick leave.

Your contact sheet must record primary telephone numbers, alternative phone lines, personal email addresses, and account numbers for external partners. Include technical assistance hotlines for cloud providers, your cyber insurance claims department, outside legal counsel, and relevant public agencies. For United States businesses dealing with extortion, CISA StopRansomware guidance recommends reporting directly to federal law enforcement via the Internet Crime Complaint Center (IC3) or a United States Secret Service field office.

Establish Incident Severity Levels and Triage Criteria

Not every suspicious email or blocked connection requires shutting down core business applications. Classifying events prevents operational paralysis and ensures appropriate escalation. The NIST SP 800-61 Rev. 3 publication provides incident response recommendations aligned with the Cybersecurity Framework to help organizations improve detection, response, and recovery. In line with NIST guidance on organizing incident response activities, establishing categorized severity levels helps teams triage anomalies based on operational impact.

You can adopt a straightforward three-tier severity matrix. A Low-severity incident involves minor, isolated events with no data exfiltration or operational disruption, such as a single staff member receiving a credential harvesting email that automated email filters intercepted. An office manager can log these events without calling an emergency meeting.

A Medium-severity incident involves limited system compromise or operational degradation, such as a compromised workstation or an account takeover where multifactor authentication was bypassed. This triggers containment protocols, account resets, and internal review. A High-severity incident represents an existential threat, such as widespread file encryption from ransomware, active database exfiltration, or loss of control over your domain registrar. High-severity incidents require executive escalation, legal notification, and potential vendor shutdown.

Step-by-Step Incident Handling Procedures

A successful response relies on predictable execution under stress. Your plan should clearly structure actions into sequential phases: initial detection, evidence-preserving containment, eradication, system restoration, and post-incident analysis.

When containment begins, staff must avoid actions that destroy volatile digital evidence. For example, turning off an endpoint wipes active RAM, which can erase critical forensic clues regarding how the threat actor gained initial access. Instead, disconnect the Ethernet cable and disable Wi-Fi. If you manage personal data under privacy regulations, align your operational steps with our guide on 7 steps for GDPR data breach response to ensure regulatory reporting deadlines are tracked alongside technical isolation.

Documenting these actions inside your overall governance structure provides consistency. You can align these procedures with broader administrative rules using 8 essential small business security policies to protect operations and record ongoing operational exposures in an active cyber risk register.

Incident Response Plan Working Aid: Quick Decision Matrix

Use this operational decision matrix as a reference page in your physical binder. It tells any employee exactly what initial defensive action to take when an anomaly is observed.

Scenario: Employee clicks a suspicious link and inputs corporate credentials. Initial action: Immediately revoke the user session from the cloud administrative portal, change the account password, review active app permissions, and verify multifactor device bindings.

Scenario: Workstation displays a ransom note demanding payment for file decryption. Initial action: Disconnect the network cable immediately. Do not power off the computer. Notify the Incident Coordinator. Check the backup repository status to verify that backup volumes remain isolated.

Scenario: Financial department receives an urgent wire transfer request claiming to be from the CEO. Initial action: Halt payment processing immediately. Verify the request through a secondary, out-of-band communication channel using a known phone number, not the phone number supplied in the email body.

How to Validate Your Incident Response Plan

A written plan is untested theory until your staff walks through an active scenario. Schedule regular tabletop exercises with your team. Bring together your leadership, technical staff, and administrative personnel to review a realistic event from initial alert through recovery.

To test whether your response plan worked, evaluate three objective metrics: time to alert the coordinator, access to critical contacts, and backup integrity. During your tabletop exercise, verify that every contact phone number in your directory reaches the correct human or service desk. Verify that staff can retrieve physical copies of your plan without accessing cloud storage. Check that your external IT provider can access offline backup images and restore a sample server within your planned recovery time objective.

If the exercise exposes gaps, do not ignore them. Common points of failure include unmonitored shared administrative mailboxes, expired software vendor contracts, and stale phone numbers for former employees. Update your documents immediately following the exercise, record lessons learned, and distribute the revised plan to all role holders.