Small Business Incident Response Plan Template: What to Do After a Breach

Overview

An incident response plan is a written set of decisions and actions for handling a security problem. It does not need to be complicated. A useful plan tells your team who makes decisions, who preserves evidence, who contacts affected parties, and how the business will restore normal operations.

Use the framework below as a starting point. Replace the bracketed fields with your own information, then store a copy somewhere that remains accessible if your usual email, file storage, or collaboration platform is unavailable.

Incident response plan template

• Business name: [Company name]
• Plan owner: [Name, role, and phone number]
• Technical lead: [Name or security provider]
• Executive decision-maker: [Name and backup contact]
• Legal or privacy contact: [Name or adviser]
• Insurance contact: [Broker, insurer, and policy reference]
• Primary incident channel: [Phone bridge or alternate messaging channel]
• Critical systems: [Email, accounting, customer database, website, payment systems, and other essential services]
• Backup location: [Offline or separately protected backup details]
• Last review date: [Date]

Assign a primary person and a backup for every important role. A plan that depends on one person being available is not a dependable plan.

For prevention work that supports response, use a 30-day small business cybersecurity plan and review your access controls with the access control checklist for small businesses.

Checklist by scenario

The first response should be proportionate to the situation, but the sequence is usually similar: verify what happened, limit further damage, preserve useful information, communicate carefully, and recover in a controlled way.

1. Suspected phishing or compromised account

• Record the message, sender, time, link, attachment, and affected account without forwarding suspicious content unnecessarily.
• Ask the user what they clicked, opened, entered, or approved.
• From a trusted device, reset the password and revoke active sessions where the service supports it.
• Review recent sign-ins, forwarding rules, new mailbox delegates, connected applications, and changes to payment or recovery details.
• Enable or re-enroll multifactor authentication if it may have been disabled or bypassed.
• Warn relevant staff, customers, or suppliers only after confirming what information they need to avoid confusion.

2. Lost or stolen device

• Record the device type, assigned user, approximate time, and location of the loss.
• Use your device-management or account tools to lock, locate, or erase the device when appropriate.
• Disable sessions, tokens, or credentials stored on the device.
• Identify the data the device could access, including local files, cloud services, customer records, and saved passwords.
• Document whether the device was encrypted and whether a screen lock was active.
• Consider whether the incident involves personal or confidential information that requires additional review.

3. Malware or ransomware warning

• Disconnect the affected computer or server from networks, shared drives, and remote-access tools. Do not destroy or wipe it immediately.
• Prevent employees from reconnecting affected devices or using potentially compromised credentials.
• Identify the earliest known alert, affected systems, and visible symptoms.
• Contact your technical lead, security provider, insurer, and other approved responders using known contact details.
• Preserve ransom notes, alerts, logs, filenames, timestamps, and relevant messages.
• Confirm that backups are separate, available, and not also affected before beginning restoration.
• Do not assume that paying or refusing a demand resolves the underlying compromise. Escalate the decision to the appropriate business, legal, and insurance contacts.

4. Suspicious payment request or business email compromise

• Pause the payment, bank-detail change, invoice approval, or gift-card request.
• Verify the request through a known phone number or an established process, not by replying to the suspicious message.
• Notify the bank or payment provider quickly if funds may have moved.
• Secure the suspected account and inspect mailbox rules, sign-ins, delegated access, and recent correspondence.
• Preserve messages and transaction information for the investigation.
• Tell employees which impersonated person, supplier, or process they should treat as suspicious.

5. Suspected exposure of customer or employee data

• Define what data may be involved, whose data it is, where it was stored, and the period of possible access.
• Limit access to the affected system while avoiding changes that could erase evidence.
• List the facts known, the facts still being investigated, and the assumptions that must not be presented as confirmed.
• Ask qualified legal or privacy advisers to assess notification, contractual, and regulatory responsibilities for the locations and data involved.
• Coordinate customer and employee communications so they are accurate, consistent, and appropriately protective of personal information.

What to double-check

Roles and contact paths

Confirm that every contact number works outside your normal systems. Include an executive decision-maker, technical responder, communications owner, records keeper, and legal or privacy contact. If you use an insurer or external security provider, check whether the policy requires specific notification steps or approved vendors before engaging them. These are potential cyber insurance requirements to verify against your own policy, not assumptions to apply universally.

Evidence handling

Keep an incident log with the date and time, person making each entry, observed facts, actions taken, decisions, and open questions. Save relevant emails, screenshots, alerts, access logs, payment records, and file names in a restricted location. Avoid editing original files where possible. Record who collected an item and where it was stored. A simple, consistent record is more useful than an elaborate process nobody follows.

Communication

Prepare a short internal message that says what is known, what employees should stop doing, where updates will appear, and who can approve external statements. Do not speculate about the cause, scope, or affected people. Do not publish technical details that could help an attacker. Customer, supplier, employee, and regulator communications may have different requirements, so obtain appropriate advice before sending them.

Recovery and validation

Restoring a system is not the same as proving it is safe. Before reconnecting services, identify the suspected entry point, remove unauthorized accounts or software, reset relevant credentials, patch exposed systems, and confirm that monitoring is working. Restore the most business-critical services first, then validate transactions, data integrity, integrations, and user access. Keep a record of what was restored and by whom.

For SaaS-heavy teams, review the related cloud security checklist for Microsoft 365 and Google Workspace and the guide to securing SaaS accounts.

Common mistakes

• Waiting for certainty: Treat credible warning signs as a reason to investigate and contain, even when the full scope is unknown.
• Using the compromised channel: If email may be affected, use a verified phone number or alternate channel for response coordination.
• Wiping devices too soon: Immediate cleanup can remove information needed to understand the incident or support a claim.
• Resetting only one password: Review reused credentials, active sessions, recovery methods, application access, and privileged accounts.
• Assuming backups are usable: Test restoration and confirm that backup accounts and systems are protected separately.
• Overpromising in updates: State what is confirmed, what is being investigated, and when the next update is expected.
• Leaving the plan in a shared folder: Keep an offline or independently accessible copy with current contacts.
• Skipping the review: A plan that has never been practiced will not reveal unclear authority, missing contacts, or impractical steps.

When to revisit

Review this incident response plan at least annually and after any real incident, near miss, major system change, or change in responsibility. Also revisit it before seasonal planning cycles, busy sales periods, office moves, acquisitions, or extended staff leave.

Update the plan whenever you change email, cloud storage, accounting, payment, endpoint protection, backup, remote-access, or e-signature tools. Recheck contact details, administrator lists, critical systems, backup procedures, and insurance instructions. Your quarterly security review can provide a regular checkpoint.

Once a year, run a tabletop exercise lasting about an hour. Choose one scenario, such as a compromised administrator account or ransomware on a shared drive. Ask each role to explain the next action, decision authority, communication route, and evidence to preserve. Do not grade the exercise by how quickly participants guess the answer; use it to find gaps. Finish by assigning an owner and deadline for every improvement.

Start today: fill in the contact list, identify your three most critical systems, confirm that a copy of the plan is available offline, and schedule the first tabletop exercise. A short plan that is current and practiced is a stronger foundation for small business cybersecurity than a detailed document nobody can use under pressure.