Small Business Incident Response Plan: Template and Drills

A small business incident response plan should name the people who take charge, the decisions they can authorize, the support they can reach, and the evidence they must record. This guide gives a company of 10–100 people a copyable plan template, decision-authority worksheet, scenario playbooks, incident-log example and exercise agenda.

The test is practical: if company email is unavailable and the owner cannot answer, can someone find the plan, reach the right technical help, and make an authorized decision? If the answer depends on remembering a password or finding one particular employee, that dependency belongs on your preparation list.

Use our incident-response overview for definitions and the broader preparation background. Here, the job is implementation: turn responsibilities into decisions your team can carry out. Official sources were checked on October 27, 2026; the worksheets and fictional examples need adaptation and have not been tested in your organization.

Set the scope before filling in the plan template

Write the business boundary on the first page: which locations, services, people and providers does this plan cover? Identify who owns exceptions, such as a separately managed subsidiary or a customer system your company cannot authorize changes to. Connect the technical work to business decisions about service interruption, specialist help, communication and recovery.

NIST SP 800-61 Revision 3, published in April 2025, supersedes Revision 2 and integrates incident response with Cybersecurity Framework 2.0 risk management. Preparation and improvement continue outside the incident itself. Writing a document once does not establish a working response capability.

Start by naming the services your company needs to operate: for example, order processing, email, payroll, customer support or production control. For each, identify its business owner, technical provider, important dependencies and acceptable temporary workarounds. Decide which disruptions require immediate management involvement.

Keep the boundaries between plans clear. Incident response manages the security event; continuity planning keeps essential work moving; disaster recovery restores technology. Our business continuity, disaster recovery and incident response comparison explains how those responsibilities fit together. Reference the other plans rather than copying them into a larger, harder-to-maintain document.

Name the people, their backups and their authority

A small company does not need a separate department for each responsibility. It does need clarity about who is doing which job. The following is a practical starting model, not a staffing requirement from NIST:

• Incident lead: coordinates the response, maintains the situation summary, assigns actions and sets the next update. An operations manager may fill this role while a technical specialist investigates.
• Technical lead: assesses what happened, recommends containment, preserves relevant evidence and directs technical recovery. This may be internal IT or a named contact at your managed service provider.
• Business approver: authorizes significant disruption, emergency spending and business risk decisions. Name a deputy who can act if the usual approver is unavailable.
• Communications owner: coordinates staff, customer and partner messages using verified information and the required review process. Identify who can speak publicly.

Attach contacts for legal counsel, qualified forensic assistance and your insurer, where applicable. Assign someone to coordinate those relationships. Different incidents may need different specialists; a suspected data exposure raises questions that an ordinary service outage may not.

Write authority as a decision, not a job title. “IT handles incidents” leaves too much unresolved. Specify who may isolate an endpoint, approve a broader shutdown, engage emergency support, and authorize restoration. Define limits and escalation routes with the people and providers involved. A responsibility without the access or authority to carry it out is a gap.

Complete a decision-authority worksheet

For each important action, record five fields: action and boundary; primary decision maker; deputy; authority limit; and evidence of the decision. Add the operational prerequisites, such as the provider contact or emergency-access process needed to carry it out.

For example, a fictional 30-person distributor might authorize its technical provider to isolate a suspected infected workstation under an agreed procedure, while interruption of the order-processing service requires the operations director or deputy. Record how the deputy is reached and what happens if neither responds. The company and provider must agree these rules; the example grants no authority in a real environment.

Review the worksheet with everyone named in it. Ask each person to explain their limit and handoff in their own words. Resolve conflicts before management approves the plan.

Make the provider handoff explicit

Ask your IT provider what it actually monitors, when someone responds, which systems it administers, and which actions require your permission. Record an after-hours escalation route and the information needed to open an urgent case. Verify the applicable contract rather than assuming “managed IT” includes forensic investigation or continuous incident handling.

Check boundaries between providers too. Your website host, email provider and endpoint support company may each see only part of the incident. Name the person responsible for coordinating them. Include a fallback when the primary provider is unavailable; do not promise a response time that has not been agreed.

Define when to activate and escalate the plan

Give staff a simple reporting route for suspected incidents. They should know what to report, whom to contact and how to use the fallback channel. A report can be uncertain: the technical lead can validate it without making every employee an investigator.

Use a severity scheme that reflects your business. These three levels illustrate the decisions to document; they are not official classifications or universal response deadlines:

• Report and assess: a suspicious message or isolated alert with no confirmed compromise. Route it to the designated reviewer and record the result.
• Activate the response team: credible account compromise, unexplained access to sensitive information, or an event affecting an important service. Assign an incident lead and assess scope and impact.
• Escalate to business leadership and specialist support: suspected spreading ransomware, compromise of privileged access, significant data exposure, or serious disruption. Apply the agreed emergency authority and assess external obligations.

Evaluate the facts rather than the order in which tickets arrived. NIST’s incident-management guidance considers factors such as asset criticality, functional impact, data impact and recoverability. A single affected administrator account may deserve more urgent attention than several unrelated low-impact alerts.

Keep the plan available when normal systems fail

Maintain a controlled offline or printed response packet, with an owner and a review date. Include the plan, essential contacts, service priorities and provider escalation instructions. Limit access to the people who need it, and replace outdated copies when information changes.

The UK NCSC’s small-business preparation guide recommends documenting responsibilities, decision trigger points and contacts that remain accessible when normal communications are disrupted. Its operational planning advice is useful here; UK reporting rules are not being applied to a US company.

Choose an alternative way to coordinate if company email or chat is unavailable or suspected to be compromised. Document who starts the call, how participants verify each other’s identities, and where restricted incident information can be shared. Avoid making the fallback depend entirely on the same account or device that may be affected.

Keep passwords, recovery codes and other secrets in the appropriate secure access process, not in a widely distributed contact sheet. The packet can identify who holds emergency access and how authorized responders obtain it. Rehearse that process safely before an incident.

Use a short response sequence and keep a decision log

When the plan is activated, the incident lead should establish a shared record. Separate observed facts, working assumptions and unanswered questions. Record times with a time zone, affected services, the source of each report, assigned actions, decisions and the next review point.

A useful sequence is:

1. Validate and scope. Have the technical lead assess the report, identify known affected systems or accounts, and state what remains unknown. Escalate when the evidence or business impact warrants it.
2. Coordinate containment. Use the agreed authority and specialist advice to limit further harm. Record the action, expected operational effect and person approving it. Consider dependencies before interrupting a critical service.
3. Preserve relevant evidence. Assign qualified people to protect logs and other incident records before retention limits or cleanup actions remove them. Track collection and transfer through the organization’s evidence-handling process.
4. Communicate and reassess. Give the appropriate stakeholders a verified situation update. Revisit scope, priorities and resource needs as facts change.
5. Authorize recovery. Apply the recovery criteria and record the evidence supporting restoration and return to service.

These activities can overlap. A checklist should support judgment, not force a team to finish an investigation before containing active harm.

Handle the evidence-versus-containment trade-off carefully

Do not make rebooting, wiping or powering down every affected device a routine employee response. Such actions can remove useful evidence. Equally, “never power anything off” is too absolute: the joint October 2023 #StopRansomware Guide allows power-down when affected devices cannot otherwise be disconnected to stop ransomware spreading, while warning that volatile evidence will be lost.

Have the qualified technical lead direct this trade-off for the actual environment. Staff should report promptly, avoid improvised cleanup, and follow the approved response instructions. The company plan should identify the decision maker and escalation path rather than attempt to replace a forensic procedure.

For the log, capture a decision’s reason as well as its time. “Service isolated at 14:10 UTC by the authorized technical lead because ongoing unauthorized activity was observed” is more useful than “IT fixed it.” Record where the supporting evidence is held; avoid copying sensitive data into general chat.

Adapt scenario playbooks to your services

A playbook adds incident-specific questions to the main plan. Keep its trigger, decisions, evidence needs and recovery conditions short enough to use under pressure. The following planning cards apply the official guidance above; they are not tested technical runbooks or instructions to change systems without authority.

Suspected email or identity-account compromise

Trigger: credible unexplained account activity, an administrator alert, or a report that messages were sent without the user’s knowledge. An alert still needs assessment; its existence alone does not establish the incident’s scope.

First decisions: the incident lead chooses a trusted coordination channel, while the qualified administrator assesses which identities, access and services may need containment. Use the authority worksheet to resolve service interruption and customer-support dependencies. Do not coordinate sensitive response details through an account suspected to be compromised.

Record and handoff: preserve relevant alerts, original message information and identity records under the evidence process. Track affected accounts, known activity and unresolved scope. Agree what access checks, remediation and monitoring must support a return to normal use; changing a credential should not be treated as a complete investigation.

Suspected ransomware or data extortion

Trigger: suspected unauthorized encryption, a ransom demand, or credible evidence of an extortion attempt. Escalate promptly to qualified technical support and leadership using the established plan.

First decisions: coordinate containment and business interruption, preserve evidence, and protect the recovery process. Apply the isolation-versus-power-down trade-off described above to the real incident. Staff should not improvise cleanup, negotiate with an attacker, or make recovery promises on the company’s behalf.

Record and handoff: document known affected services, key dependencies, observed indicators, actions and remaining uncertainty. Assign legal and insurer coordination where applicable. Require evidence supporting recovery-source integrity and restored-service acceptance. Keep a suspected information exposure open for assessment even if operations resume.

Sensitive information sent to the wrong recipient

Trigger: a report that a message, shared document or export reached an unintended audience. Record what is known about the information and access without spreading another copy through general support channels.

First decisions: have authorized technical staff assess available containment, while the incident lead involves the appropriate business owner and qualified legal support. Determine what actually happened before treating the report as a confirmed legal conclusion. Avoid promising that a recall, revoked link or recipient assurance proves that no copy remains.

Record and handoff: preserve the relevant access and communication records, identify the affected information and audience, and track follow-up. Counsel should assess applicable duties. Close the incident only against recorded criteria, including unresolved questions and any continuing obligations.

Keep an incident record people can verify

Use one incident reference across technical tickets, decision records and communication updates. The record should identify the source of a fact, who added it, and whether it is confirmed or provisional. Protect access and preserve changes under your organization’s process. NIST’s RS.AN-06 and RS.AN-07 address the integrity and provenance of response records and evidence.

A compact log entry needs: time and zone; observation or action; source; owner; decision and authority; evidence location; and next checkpoint. Keep sensitive evidence in its controlled location and reference it from the log rather than duplicating it everywhere.

For example, an entirely fictional exercise might record: “09:05 UTC—provider reports unusual activity for Account A; source ticket EX-01; scope unconfirmed; technical lead assigned to validate.” A later entry might say: “09:12 UTC—incident lead activates the plan under the agreed account-compromise trigger; deputy business approver notified; next update at 09:30 UTC.”

Those times illustrate a record format, not required response targets. If a later finding changes the initial interpretation, preserve the correction and its reason. A clear history helps the next responder distinguish what was observed from what the team initially suspected.

Coordinate messages and assess notification duties

Prepare a communication checklist before you need it. Identify the audiences, message owner, reviewer, approved channel and next update time. Staff may need instructions about reporting, alternative work arrangements and which systems to avoid while the team investigates.

Distinguish facts from conclusions. A service outage does not by itself prove a breach, and restored files do not prove that no information was taken. Explain what is known, what is being investigated and what the audience should do, without speculating or exposing additional sensitive information.

The FTC’s Data Breach Response guide recommends consulting legal and forensic specialists, preserving evidence and avoiding misleading communications. Have qualified counsel assess applicable notification duties using the affected data, jurisdictions, contracts and current rules. This article does not supply a universal notification deadline.

Record any insurer or service-provider requirements from the actual policy or contract. The incident lead should know who checks those terms and coordinates required contacts. Do not infer coverage, exclusions or guaranteed assistance from the existence of an insurance policy.

Require evidence before returning a service to operation

Define acceptance criteria for each critical service with its technical and business owners. NIST Revision 3 calls for checking restoration assets for integrity issues, verifying restored systems, and confirming essential functions. A backup job or restore operation marked successful is only part of that evidence.

Your recovery record should answer: what known access or root cause was addressed; which recovery source was checked; which technical and business tests passed; what uncertainty remains; and who accepted the return to service. Assign monitoring and a fallback if the restored service behaves unexpectedly.

For example, a restored ordering application needs more than a working login page. Its business owner should verify the relevant ordering workflow while the technical owner checks the agreed security and dependency requirements. This is a planning example, not a validated test script for every application.

Use the ransomware recovery and backup-testing guide for that more detailed preparation. Longer-term remediation can continue through the data-breach recovery guide. Track unfinished actions rather than treating operational recovery as the end of every investigation or obligation.

Copy this starter plan into your controlled document

Complete the fields below with the people who will use them. The blank plan is an original editorial worksheet, not a certified template. Keep company-specific contacts and restricted information in your controlled version.

• Plan control: organization ___; owner ___; version/date ___; review date ___; approved by ___; controlled online/offline locations ___.
• Scope: critical services ___; business owners ___; technical providers ___; key dependencies ___; approved temporary workarounds ___.
• People: incident lead/backup ___; technical lead/backup ___; business approver/deputy ___; communications owner/backup ___.
• External support: provider escalation ___; legal ___; qualified response/forensic support ___; insurer contact and applicable requirements ___.
• Activation: reporting route ___; fallback ___; incident declaration authority ___; severity triggers ___; management escalation criteria ___.
• Decision authority: endpoint containment ___; wider service interruption ___; emergency spending ___; external statements ___; recovery approval ___.
• Response record: incident reference ___; date/time zone ___; confirmed facts ___; unknowns ___; assigned actions/owners ___; evidence location ___; next update ___.
• Recovery: checks required ___; evidence recorded ___; business acceptance ___; remaining risks ___; monitoring owner ___; fallback ___.
• Improvement: exercise/incident date ___; gaps ___; action owners/due dates ___; retest date ___; revised plan version ___.

Rehearse the handoffs before relying on the plan

Run a discussion-based exercise with the incident lead, a business approver and your technical provider. A one-hour session is a suggested starting point, not a mandated standard. Keep it separate from live production changes.

Use a fictional scenario: company email is suspected to be compromised, an important account shows unexplained activity, and the usual approver cannot be reached. Ask participants to find the offline plan, identify the deputy, contact the technical lead and explain who can authorize containment. Then introduce a provider delay or an uncertain customer-data exposure.

For a first discussion, this illustrative agenda can keep the session focused:

1. Minutes 0–10: establish the scenario, find the controlled plan, and assign the lead and deputy.
2. Minutes 10–25: walk through reporting, validation, containment authority and provider escalation.
3. Minutes 25–40: introduce an unavailable approver or untrusted email channel; produce a log entry and an audience-specific update.
4. Minutes 40–50: ask what evidence and business acceptance would be needed before restoring the affected service.
5. Minutes 50–60: assign gaps, owners and due dates, then schedule verification of the fixes.

Judge the exercise by demonstrated handoffs and usable records. Finding the right phone number is one check; establishing that the support agreement covers the requested help is another. A discussion exercise also does not prove that a backup restores or that an emergency account works. Plan those technical checks separately with the appropriate authorization.

Record the decisions participants can actually make and the information they cannot find. Finish by assigning each gap an owner and a due date. Retest the important failures after repairs. Review the plan when staff, providers, systems or obligations change, and use lessons from real incidents to improve it.

Research method and practical limits

This is a document-based guide checked on October 27, 2026 against NIST, FTC, UK NCSC and the specified joint-agency ransomware guidance. Relevant sections of the longer publications were reviewed. The role model, severity examples, blank worksheet and exercise scenario are editorial adaptations for small-company planning.

No incident response engagement, company exercise, tenant, endpoint, backup restoration or provider contract was tested. Independent technical review remains pending. The guide cannot determine your legal duties, prove readiness or guarantee containment or recovery.

Start with the handoff your team cannot yet make

Begin with one decision you cannot currently answer: who takes charge if the usual person is unavailable? Name that person and their backup, agree on their authority, and rehearse the handoff. A short plan that people can find and use is the foundation for the more detailed procedures your company needs.