What you need to know
- An incident response plan assigns decisions before pressure, confusion, and incomplete information make them harder.
- Small businesses need named contacts, containment steps, evidence handling, communication rules, and tested recovery—not a long policy nobody can use.
- Do not erase affected systems or negotiate with an attacker before getting qualified advice and preserving evidence.
- Review the plan after every exercise or incident and update contacts, vendors, access, and recovery priorities.
What is an incident response plan?
A cybersecurity incident response plan is a documented process for identifying, containing, investigating, communicating, and recovering from a security event. It helps a team decide who leads, what must happen first, which systems matter most, and when outside specialists or authorities should be contacted.
The plan should cover realistic events: compromised email, ransomware, stolen credentials, fraudulent payments, lost devices, website compromise, cloud-account takeover, data exposure, and supplier incidents. Its purpose is safe coordination, not perfect prediction.
Assign roles and escalation authority
Name an incident lead and a backup. Identify who can disable accounts, isolate devices, contact the hosting or cloud provider, approve emergency spending, notify customers, and speak publicly. Store the contact list somewhere accessible even if normal email or file sharing is unavailable.
Small businesses often rely on outside IT, legal counsel, cyber-insurance providers, payment processors, or forensic specialists. Record contract numbers and reporting conditions in advance. Insurance policies may require early notice or the use of approved vendors.
- Incident lead and deputy.
- Technical containment and recovery contact.
- Legal, privacy, insurance, and regulatory advisers where applicable.
- Bank, payment processor, critical suppliers, and hosting providers.
- A single authorized communications contact.
Define severity and first actions
Create simple severity levels based on business impact, data sensitivity, number of systems, customer effect, financial loss, and whether the attacker still has access. Employees should know how to report a suspected incident immediately without trying to investigate it alone.
Initial actions may include isolating an affected device from the network, disabling a compromised account, revoking sessions, blocking malicious rules, or calling a bank about a fraudulent transfer. Containment must be careful: powering off or wiping a system can destroy useful evidence.
Preserve evidence and keep an incident log
Record what was observed, who noticed it, the time, affected accounts or systems, and every action taken. Preserve suspicious messages, headers, logs, alerts, screenshots, and relevant files. Use a reliable time zone throughout the record.
Evidence supports technical investigation, insurance, legal advice, regulatory assessment, and lessons learned. Limit access to the record and do not place sensitive evidence in an already compromised system.
Plan communication and notification
Decide how the team will communicate if email, chat, or phone systems are affected. Prepare holding statements, but do not speculate about scope or blame. Give employees clear instructions and provide customers with useful actions only when facts support them.
Notification duties depend on location, industry, contract, and the data involved. Seek qualified legal or regulatory advice promptly. The response plan should identify who assesses those duties and who authorizes notices; it should not rely on a generic deadline copied from another organization.
Recover safely and verify controls
Prioritize essential services, restore from known-good backups, reset exposed credentials, patch the entry point, and monitor for renewed access. Verify backups before relying on them and confirm that recovery does not reintroduce compromised accounts or malware.
Recovery is not complete when a system turns back on. Validate data integrity, transactions, access permissions, customer-facing functions, logging, and security monitoring. Keep enhanced monitoring in place for a period proportionate to the incident.
Test and improve the plan
Run a tabletop exercise at least annually and after major changes to systems, vendors, or staff. Walk through one realistic scenario and ask what each person would do, which information they need, and where a decision would stall.
After an exercise or incident, document root causes, control failures, slow decisions, missing contacts, and recovery gaps. Assign corrective actions with owners and dates. A short plan that is practiced and maintained is more valuable than a comprehensive document that is never opened.
Frequently asked questions
What should a small business do first after a cyber incident?
Report and record the event, activate the incident lead, contain ongoing access carefully, and preserve evidence. Contact qualified IT, legal, insurance, financial, or law-enforcement resources according to the event.
Should an infected computer be turned off?
Not automatically. Disconnecting it from networks may be appropriate, but shutting down or wiping it can destroy evidence. Follow the plan or advice from a qualified responder.
How often should the plan be tested?
Test it at least annually and after major technology, vendor, staffing, or regulatory changes. High-risk businesses should exercise more frequently.

