Cyber Attack Response Plan for Small Business: 6 Steps

A cyber attack incident response plan is a short written playbook that says who does what when an attack hits: who can declare an incident, who gets called, how affected systems are contained, and how the business recovers and reports. For a small business it fits on a few pages, follows the six steps below, and is kept somewhere you can reach when the network is down. Most small businesses do not have one, so when a breach hits they lose the first critical hours arguing about what to do.

This guide walks through the six steps that matter, then gives you a first-hour checklist, a fill-in template outline and a worked example, so you can write a plan your team will actually use. It reflects NIST's incident response guidance as of October 2026.

The stakes are not abstract. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, a 12 percent increase over the year before and a record high. A small business will not lose millions, but the pattern holds: the longer an attacker sits undetected and the more scattered your response, the more it costs you.

What is an incident response plan, exactly?

An incident response plan is a documented, step-by-step process for detecting, containing, and recovering from a security incident. You will also see it called a cybersecurity incident response plan, or CSIRP. It names the people responsible, defines what counts as an incident worth acting on, and lists the exact actions for the first hour, the first day, and the week after. Good plans fit on a few pages and live somewhere you can reach without your network. Incident response planning is the ongoing work around the document: writing it, testing it, and updating it after every incident or major change.

Why does a small business need one?

Because attacks do not wait for business hours, and panic makes bad decisions. Ransomware crews and business email compromise scammers count on confusion. When nobody knows who has authority to disconnect a server or freeze a wire, the attacker gets more time. A plan replaces "what do we do now?" with "we are on step three." That difference is measured in dollars and downtime.

The six steps of a small business incident response plan

1. Prepare before anything happens

Preparation is the work that pays off during a crisis. Write down your response team and their phone numbers, including your IT provider, your cyber insurance carrier, and outside counsel. Confirm you have working, tested backups. Keep a printed or offline copy of the plan, because if your network is locked, a plan stored only on that network is useless. Read your cyber insurance policy now, too, so you know whether the carrier expects a call to its hotline before you bring in outside help.

2. Detect and confirm the incident

Decide in advance what triggers the plan: a ransomware note, a vendor telling you they were breached, a bank flagging a fraudulent transfer, or an employee reporting a stolen laptop. Someone has to make the call that "this is an incident." Give one or two people that authority so the plan starts moving instead of sitting in someone's inbox. Write down where the evidence will come from: endpoint protection alerts, Microsoft 365 or Google Workspace sign-in and audit logs, firewall logs, and your bank's fraud desk.

3. Contain the damage

Containment is about stopping the spread without destroying evidence. Isolate affected machines from the network rather than wiping them. Disable compromised accounts and reset the passwords tied to them. If money is moving, call the bank immediately to try to recall the transfer. Speed matters most here, which is why the authority question in step two cannot wait for the crisis. The FTC's data breach response guide makes the same point: take affected equipment offline, but don't shut machines down before forensic experts arrive, and don't destroy forensic evidence while you remediate.

4. Eradicate the threat

Once the incident is contained, find and remove what caused it: the malware, the rogue account, the mail rule an attacker set up to hide their tracks. This is where an experienced hand matters. Missing a single hidden foothold means the attacker walks right back in a week later. If your team is thin, this is the moment to lean on a security partner.

5. Recover and restore operations

Bring systems back in a deliberate order, restoring from clean backups you have verified are not themselves infected. Watch restored systems closely for signs the problem returns. Our backup and disaster recovery FAQ covers how to make sure the backups you are counting on will actually work when you need them.

6. Review what happened and fix the gap

Within a week or two, walk through what happened while it is fresh. What let the attacker in? What slowed your response? Update the plan with the answers. Every incident, even a near miss, is a free lesson in where your defenses are thin.

Incident response checklist: the first hour

Print this and keep it with the plan. The order matters more than the speed of any single step.

1. Write down the time, who reported what, and what they saw. Start an incident log and keep it going.
2. Call the incident lead and the technical lead. The incident lead decides whether this is an incident.
3. Disconnect affected computers from the network by unplugging the cable or turning off Wi-Fi. Don't wipe, reimage or power them off unless the technical lead says so.
4. If an account is involved, reset its password, sign it out everywhere, and check for new MFA methods, inbox rules and mail forwarding.
5. If money moved or is about to, call the bank's fraud line and ask for a recall, then report it to the FBI's Internet Crime Complaint Center (IC3), which says reports can in some cases help freeze stolen funds.
6. Call your cyber insurance carrier's claims or breach hotline before you hire outside help, if your policy asks for that.
7. Preserve evidence: keep logs, ransom notes, suspicious emails and screenshots. Don't delete the attacker's messages.
8. Hold outside communication until the incident lead and counsel agree on what to say.

Who should be on the response team?

For most small businesses it is a small group: an owner or manager who can authorize decisions and spending, whoever handles IT, someone for customer and staff communication, and outside experts on call. You do not need a large security department. You need clear roles, current phone numbers, and one person with the authority to act when minutes count. A virtual CISO can fill the security-leadership seat without a full-time hire.

An illustrative roles table for a 20-person firm. Swap in your own people and backups:

Role	Typical owner	Authority to write into the plan
Incident lead	Owner or operations manager	Declare an incident, approve spending, approve taking systems offline
Technical lead	IT provider or in-house IT	Isolate devices, disable accounts, preserve logs and evidence
Communications	Office manager or owner	Staff instructions, and customer statements after counsel reviews them
Legal and insurance	Outside counsel and the cyber insurance carrier	Notification decisions and engaging forensic firms
Finance	Controller or bookkeeper	Call the bank, hold or recall payments

What does NIST say about incident response plans?

NIST's guidance changed in April 2025. NIST SP 800-61 Revision 3 superseded the 2012 Revision 2 and its four-phase life cycle (preparation; detection and analysis; containment, eradication and recovery; post-incident activity). Revision 3 maps incident response onto the six functions of the NIST Cybersecurity Framework 2.0 instead:

• Govern, Identify and Protect are the preparation work: policy, roles, asset inventory, backups, and the controls that prevent incidents.
• Detect, Respond and Recover are the incident response itself: finding and analyzing the attack, containing and eradicating it, restoring operations, and handling reporting and communication.
• Improvement, a category inside Identify, feeds lessons back into everything. NIST says lessons should often be shared as soon as they are identified, not held until recovery ends.

NIST also says organizations should use the life cycle model that suits them best. The six steps above are the older model in plain language, which most small businesses find easier to run under pressure. If you already use the framework, our NIST CSF 2.0 guide for small business shows how the functions fit together.

Incident response plan template: what to include

NIST doesn't publish a fill-in template, but SP 800-61 Revision 3 lists the elements most incident response policies share: a statement of management commitment, purpose and objectives, scope, definitions of events and incidents, roles, responsibilities and authorities (including who can disconnect or shut down systems), guidelines for prioritizing incidents and estimating severity, and performance measures. A small business plan built on those elements usually runs a few pages, plus a page for each playbook:

1. Purpose, scope and owner. One paragraph, signed by the owner, saying the plan covers all company systems, data and staff, and naming who maintains it.
2. Contact sheet. The response team with a backup for each role, your IT provider, the insurer's hotline and policy number, outside counsel, your bank's fraud line, and key vendors. Phone numbers, not just email addresses.
3. Definitions and severity levels. What counts as an event, an incident and a breach for your business, with two or three severity levels and an example of each.
4. Authority. Who can declare an incident, take systems offline, approve spending, and speak to customers, regulators and the press.
5. First-hour checklist. The list above, adapted to your systems.
6. Playbooks for your top scenarios. One page each for ransomware, a compromised email account, payment or wire fraud, and a lost or stolen laptop.
7. Notification and reporting. Who decides on notices, which laws and contracts apply to your data, and where crimes get reported.
8. Recovery priorities. The order in which systems come back, and where the tested backups are.
9. Post-incident review. A short incident report form and a deadline for updating the plan.
10. Testing and version history. When the plan was last exercised and last updated.

Keep a printed copy, and a second copy outside your main systems that the owner can reach from a personal device.

Incident response plan example: a wire fraud attempt

This scenario is illustrative, not a NetSys client case. A bookkeeper at a 20-person accounting firm receives an email, apparently from a long-time vendor, with new bank details for an invoice that is due. She pays it. Two days later the real vendor asks where its money is.

• Detect. The bookkeeper calls the incident lead, who declares an incident under the plan's definition of payment fraud.
• Contain. The finance lead calls the bank's fraud line to request a recall, and the firm files a report with IC3. The technical lead checks the firm's mailboxes for unfamiliar sign-ins, forwarding rules and new MFA methods, because the fake request may have come from a compromised internal account.
• Eradicate. If a firm mailbox was compromised, the technical lead resets it, revokes its sessions and removes the attacker's rules. If the vendor's mailbox was the one compromised, the firm tells the vendor.
• Recover. Payments to changed bank details now require a call-back to a phone number already on file.
• Review. The payment fraud playbook gets the call-back rule, and staff get a short refresher on spotting payment-change requests.

Frequently asked questions

How long should an incident response plan be?

Short enough to use under pressure. A few pages is plenty for most small businesses: a contact list, the definition of an incident, and the actions for the first hour, first day, and first week. A 40-page document nobody reads is worse than a one-page checklist people actually follow.

Is there a NIST incident response plan template?

Not a fill-in one. NIST SP 800-61 Revision 3 describes what an incident response policy and plan should cover and maps incident response to the CSF 2.0 functions, and it points to CISA's incident response playbooks as examples of how to format procedures. The ten-part outline above follows NIST's policy elements and is sized for a small business.

Do we legally have to report a data breach?

Often yes. According to the FTC's breach response guide, all states, the District of Columbia, Puerto Rico, and the Virgin Islands have laws requiring notification of breaches involving personal information, and rules also vary by industry and the type of data exposed. Healthcare, financial, and firms handling personal data face specific timelines. Build the reporting question into your plan and confirm the details with counsel and your insurer before an incident, not during one. For the crime itself, the FTC suggests calling local police and, where they aren't equipped for it, the local FBI or Secret Service office.

Should we pay a ransomware demand?

Paying is a last resort with no guarantee you get your data back, and it can carry legal risk. The better answer is tested, offline backups that let you restore without paying. Decide your position ahead of time, in writing, so the choice is not made in a panic at 2 a.m.

How often should we test the plan?

At least once a year, and after any major change to your systems or staff. A short tabletop exercise, where you talk through a realistic scenario for an hour, surfaces gaps like out-of-date phone numbers or unclear authority long before a real attacker finds them. Our tabletop exercise guide covers how to run one.

What should an incident report include?

A timeline from the first sign through detection, containment and recovery; the systems and data affected; how the attacker got in; what was done and by whom; the notifications made; the costs; and the fixes, each with an owner and a date. Keep it factual, and let counsel review it before it leaves the company.

Do we need incident response software?

Not to start. A small business needs a written plan, a contact sheet, tested backups, and the logs its existing tools already keep, such as endpoint protection alerts and Microsoft 365 audit logs. Dedicated incident management platforms help larger teams coordinate. If the gap is people watching alerts at night, that is what a managed detection and response service adds.

Is this the same as the National Cyber Incident Response Plan?

No. CISA's National Cyber Incident Response Plan describes how federal agencies, state and local governments and private-sector organizations coordinate on significant cyber incidents at the national level. Your plan covers how your own business responds.

What is the difference between an incident response plan and disaster recovery?

Incident response handles the security event itself: detecting, containing, and removing the threat. Disaster recovery handles getting operations back after any disruption, including fires and outages, mostly through backups and restore procedures. They overlap during a cyberattack and work best written together.

Get help before you need it

The worst time to write your first incident response plan is during an attack. If you do not have one, or you are not sure the one you have would hold up, book a call with The NetSys Group. We will walk your systems, pressure-test your response, and help you put a plan in place while things are quiet. Our incident response planning and retainer service covers the written plan, tabletop exercises and a first-hour playbook, and it is included for NetSys managed clients. Learn more about our cybersecurity services.

By Joel Baum for The NetSys Group, which has delivered managed IT, cybersecurity, and cloud services since 1998. Our engineers hold degrees in electrical and computer engineering and are certified Microsoft and Cisco instructors, working on site across New York City, Long Island, Westchester, the Hudson Valley, North Jersey and Fairfield County, Connecticut, and remote-first everywhere else.