How to Create a Small Business Incident Response Plan

An incident response plan gives the organization a coordinated way to report, contain, investigate, communicate, and recover from a cybersecurity incident.

Why a Written Plan Matters

During an incident, people may be working with incomplete information while business systems are unavailable or untrusted. A written plan reduces hesitation and helps the organization avoid destructive actions such as deleting evidence, wiping devices too early, contacting the attacker, or making unapproved public statements.

The plan should be short enough to use under pressure but detailed enough to identify responsibilities, contact information, priorities, and decision points.

Define What Counts as an Incident

Employees need examples of events that should be reported. The organization can classify events by severity after the initial report.

• Compromised email or cloud account
• Unexpected multifactor authentication prompts
• Malware or ransomware alert
• Lost or stolen business device
• Accidental external sharing of sensitive information
• Unauthorized payment or banking change
• Website compromise
• Unavailable critical service
• Vendor notification of a security event
• Suspicious administrator activity

Create a Simple Reporting Process

Employees should have one clear way to report a suspected incident, plus an alternative if email is unavailable or compromised. Provide a phone number, service desk method, or emergency contact.

Encourage immediate reporting. Employees should not investigate deeply, delete messages, shut down systems, or confront a suspected person unless the response lead instructs them to do so.

Assign the Incident Response Team

A small business may not have a full internal security team. The plan can assign roles to business leadership, internal technology staff, an outside provider, legal counsel, insurance contacts, communications staff, and system owners.

• Incident lead: Coordinates actions and maintains the timeline.
• Technical lead: Investigates, contains, and restores systems.
• Business decision maker: Approves business disruption and major actions.
• Legal and compliance contact: Advises on obligations and evidence.
• Communications lead: Coordinates employee, customer, and public communication.
• Vendor coordinator: Contacts cloud providers, software vendors, carriers, and outside responders.

Maintain an Incident Contact List

Record names, roles, office numbers, mobile numbers, alternative email addresses, vendor support numbers, account identifiers, insurance policy contacts, and escalation procedures. Review the list quarterly.

Keep an offline or independently accessible copy. If the primary email system is compromised, the team may need another communication channel.

Establish Severity Levels

A simple severity model helps the organization decide who must be notified and how quickly. For example:

• Low: Suspicious event with no confirmed compromise or business impact.
• Moderate: Confirmed issue affecting one user or device with limited impact.
• High: Confirmed compromise of an important account, system, or sensitive information.
• Critical: Widespread disruption, ransomware, significant data exposure, safety impact, or loss of critical operations.

The team should be able to increase or decrease severity as facts change.

Prepare Initial Response Steps

1. Record who reported the event and when.
2. Record the affected account, device, system, data, and location.
3. Preserve the original message, alert, or evidence.
4. Contact the incident lead.
5. Decide whether immediate isolation is required.
6. Protect important logs and audit records.
7. Start an incident timeline.
8. Identify additional people or vendors who must be involved.

Contain the Incident Carefully

Containment can include disabling an account, revoking sessions, isolating a device, blocking a malicious sender, disabling a compromised integration, removing a public sharing link, or restricting network access.

Containment should balance security with operational needs. Disconnecting a critical server without preparation may destroy useful evidence or cause additional business harm.

Preserve Evidence

Record dates, times, actions, people involved, screenshots, alerts, logs, affected accounts, file names, and communication. Store evidence in a restricted location and avoid changing original files when possible.

The required level of evidence preservation depends on the incident, contracts, insurance, legal guidance, and potential law-enforcement involvement.

Investigate the Scope

• How did the incident begin?
• Which accounts, devices, applications, and data were affected?
• When did unauthorized activity begin?
• What access did the compromised identity have?
• Were forwarding rules, new administrators, tokens, or integrations created?
• Was information viewed, changed, downloaded, encrypted, or deleted?
• Did the attacker move to other systems?
• Are backups and recovery credentials safe?

Plan Communication

Document who communicates with employees, customers, vendors, insurers, regulators, law enforcement, and the public. Communication should be accurate, approved, and updated as facts change.

Do not speculate. Record what is known, what is being investigated, what actions recipients should take, and when another update will be provided.

Review Legal, Contractual, and Insurance Requirements

Data-breach notification, contractual notice, insurance cooperation, and preservation requirements can vary. The plan should identify who obtains qualified legal guidance rather than attempting to include every possible requirement in one generic procedure.

Contact the cyber-insurance carrier according to policy instructions before committing to major outside expenses when required.

Eradicate the Cause

Remove malicious software, accounts, forwarding rules, access tokens, integrations, exposed credentials, vulnerable applications, and unauthorized changes. Patch the entry point and review similar systems for the same weakness.

Do not restore normal access until the team has addressed the known cause or established compensating controls.

Recover in a Controlled Order

Prioritize systems according to business importance and dependency. Restore from known-good sources, apply updates, reset credentials, verify access, monitor for recurrence, and obtain business-owner approval.

Recovery may require temporary manual workarounds. Document which services remain limited and how employees should operate safely.

Conduct a Lessons-Learned Review

After stabilization, review what happened, what worked, what delayed the response, which controls failed, and which procedures need improvement. Assign corrective actions with owners and deadlines.

The review should improve systems and processes rather than focus only on individual blame.

Exercise the Plan

Run a tabletop exercise at least annually and after major organizational changes. Present a realistic scenario and ask participants how they would report, contain, communicate, and recover.

Test contact information, authority, vendor escalation, backup restoration, alternative communication, and business workarounds.

Incident Response Plan Checklist

Frequently Asked Questions

Does a small business need a full incident response team?

It needs assigned roles and contacts, even when several roles are performed by the same employee or outside provider.

Should the plan include passwords?

No. Store credentials in an approved password-management or emergency-access system and reference the process rather than placing passwords in the plan.

When should outside help be contacted?

Define triggers in advance, such as ransomware, administrator compromise, significant data exposure, critical business disruption, or any event beyond internal capability.

When Professional Support Helps

Professional support can develop the plan, define roles, create contact and timeline templates, coordinate technology providers, and facilitate a realistic tabletop exercise.