Small Business Cybersecurity Incident Response Plan: Templates, Roles, and First 24 Hours

Overview

Incident response is the process of identifying a security event, limiting harm, restoring normal operations, and learning from what happened. It is not limited to a large data breach. A suspicious login, payment diversion attempt, lost device, exposed cloud file, malware infection, or phishing compromise may all require a documented response.

Your plan should answer five questions before an incident occurs:

• Who decides? Name an incident lead and a backup. This person coordinates actions and maintains the timeline.
• Who investigates? Identify the people responsible for reviewing logs, accounts, devices, backups, and affected applications.
• Who communicates? Assign separate owners for employees, customers, vendors, leadership, and any required notifications.
• What must be protected first? Define critical systems, sensitive data, payment processes, and essential business operations.
• Where is the evidence? Document how to preserve alerts, email headers, login records, screenshots, endpoint data, and relevant correspondence.

Keep the plan accessible when normal systems are unavailable. Store an offline or separately protected copy with current contact details, administrator procedures, backup information, and the location of key logs. Do not rely on a single administrator account or a document stored only inside a potentially compromised environment.

For a severity framework, use the security incident severity matrix for SMBs as a companion reference. A higher severity generally means broader access, sensitive information, operational disruption, financial exposure, or uncertainty about whether the attacker still has access.

Checklist by scenario

First 24 hours: the common sequence

1. Open an incident record. Record the date and time, reporter, systems involved, current symptoms, and the person coordinating the response. Use a restricted location and limit editing rights.
2. Confirm the signal without destroying evidence. Capture relevant screenshots, messages, alert details, email headers, filenames, and timestamps. Avoid repeatedly opening suspicious files or logging into a potentially compromised account from an affected device.
3. Contain carefully. Disconnect an infected device from networks when appropriate, disable confirmed-compromised accounts, revoke active sessions, remove malicious forwarding rules, and isolate affected systems. Document every action and its time.
4. Protect critical accounts. Reset credentials from a known-clean device, prioritize administrator, email, remote access, payment, and cloud accounts, and require multifactor authentication where available. Do not reset every account blindly before preserving useful evidence.
5. Preserve logs and backups. Export relevant identity, email, endpoint, firewall, cloud, and application records according to the retention available in your tools. Protect backups from alteration while checking whether restoration points are usable.
6. Escalate early. Notify the incident lead and relevant decision-makers when there is suspected data exposure, account takeover, ransomware, payment fraud, safety risk, or continuing unauthorized access.
7. Communicate from trusted channels. Use a known phone number or separate account if email may be compromised. Tell employees what is confirmed, what action is required, and where to send questions. Avoid speculation.

Ransomware or suspected malware

• Isolate affected devices and servers from wired and wireless networks where feasible. Do not reconnect them simply to test whether the problem has stopped.
• Identify the first observed device, the apparent start time, encrypted or unavailable systems, and any signs of lateral movement.
• Protect backup systems and administrative credentials. Check whether backups are reachable, intact, and separated from the affected environment.
• Preserve ransom notes, filenames, process information, alerts, and system timestamps. Do not modify or delete files solely to make the environment look clean.
• Restore in a controlled order only after deciding how to address the suspected entry point and persistence. Document which systems are restored and which remain isolated.

Business email compromise or payment diversion

• Stop pending transfers or payment changes through a verified channel. Contact the financial institution using contact information already on file, not a number in the suspicious message.
• Review mailbox rules, forwarding settings, delegated access, recent sign-ins, sent items, deleted items, and recovery methods.
• Reset the affected account and revoke sessions or application access. Check whether other accounts used the same credentials.
• Warn employees who may have received fraudulent instructions. Tell them not to approve payment, gift card, payroll, or vendor-bank changes without an independent verification.
• Preserve the original messages and full headers. The business email compromise tracker provides additional context for payment diversion and invoice fraud patterns.

Suspected data leak or unauthorized access

• Define what information may be involved: customer records, employee information, credentials, payment data, health-related information, intellectual property, or internal correspondence.
• Identify the systems, accounts, files, and time period in scope. Preserve access logs before they expire or are overwritten.
• Separate confirmed facts from working assumptions. Record the evidence supporting each conclusion and keep a breach timeline.
• Review contractual, regulatory, insurance, and internal notification requirements with the appropriate qualified advisers. Do not promise that no notification is required until the facts and applicable obligations have been assessed.
• Prepare clear notices for affected parties if needed. The breach letter guide explains the information readers typically need to understand in a notification.

What to double-check

Contact information: Verify phone numbers, alternate email addresses, system owners, leadership contacts, payment contacts, and key vendors. Test that the contact list is available outside the affected environment.

Access and recovery: Confirm that at least two authorized people can perform essential recovery tasks without sharing credentials. Review administrator accounts, multifactor authentication methods, emergency access procedures, and password-reset dependencies.

Logging: Know which systems record sign-ins, mailbox changes, file access, endpoint activity, and administrative actions. Confirm how long records are retained and how they can be exported.

Backups: Document what is backed up, how often, where it is stored, who can delete it, and how restoration is tested. A backup that has never been restored should be treated as unverified until tested safely.

Vendor dependencies: List providers that host data, process payments, deliver email, manage endpoints, or support critical operations. Keep escalation paths and contract contacts current. Use the vendor security questionnaire guide when reviewing information-sharing arrangements.

Communications: Prepare a short internal holding message: what happened, what employees must do now, what they should not do, and when the next update will arrive. Every message should avoid unverified attribution and unnecessary personal information.

Common mistakes

• Wiping systems too soon. Reimaging or deleting accounts may remove evidence needed to understand the incident. Contain first, preserve what is useful, then rebuild according to the response plan.
• Using compromised communications. An attacker with email access may read or alter the response. Verify sensitive instructions through a separate channel.
• Treating one account as the whole incident. Investigate related accounts, shared credentials, mailbox rules, connected applications, remote access, and privileged users.
• Announcing conclusions before verification. A fast but inaccurate message can confuse employees and customers. State what is known, what remains under review, and what action is required.
• Ignoring business processes. Technical containment will not stop fraud if employees continue accepting changed bank details or urgent payment requests without verification.
• Forgetting the recovery review. Restoring service is not the same as resolving the cause. Record the entry point, control failures, decisions, costs, and improvements needed.

When to revisit

Review this cybersecurity incident response plan before seasonal planning cycles and whenever workflows or tools change. A new cloud application, payroll provider, payment process, office network, remote-access method, backup platform, or vendor can change both the attack surface and the recovery sequence.

At least once during each review, run a short tabletop exercise. Choose one scenario—ransomware, an email compromise warning, a lost administrator device, or a public data leak notice—and ask each owner to explain the first three actions, the evidence they would preserve, and the person they would contact. Record gaps rather than trying to make the exercise look successful.

After a real event or credible near miss, update the plan while the decisions are still fresh. Retire obsolete contacts, revise system names, add missing log locations, test the relevant backup or account-recovery process, and distribute the new version through a controlled channel. Keep a dated change log so responders know which version is current.

Your next action is simple: assign an incident lead and backup, create the first-page contact list, confirm a separate storage location for the plan, and schedule a tabletop review. A short, maintained checklist is more useful during a security incident than a detailed document nobody can find or trust.