At 2 a.m., nobody wants to debate whose call it is. Someone has to decide whether to unplug the file server. Someone has to decide whether to call clients. If your plan doesn’t name that person, you don’t have a plan yet.
Most small and midsized businesses have an incident response plan on paper. Many wrote it for an insurance renewal and haven’t opened it since. A plan in a folder won’t help when ransomware locks your files on a Friday night.
Here’s how to build one that works. It follows our First 24 Hours workbook and current NIST guidance. It also covers where AI helps during an incident, and where it can hurt you.
Why the plan matters more than the tools
NIST updated its incident response guidance in April 2025. Special Publication 800-61 Revision 3 ties response to overall risk management and the Cybersecurity Framework 2.0. The message is simple. Response isn’t a side project for IT. It’s a business discipline that starts before anything goes wrong.
Time matters too. IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million. It also found that breaches took an average of 247 days to identify and contain. The longer an attacker stays hidden, the more the breach costs.
1. Name people, not departments
Start with an incident command map. List six roles: incident commander, communications lead, technical lead, legal lead, executive sponsor, and insurance or IT partner. Name a primary and a backup for each. “The IT team” isn’t an answer at 2 a.m.
Then settle who can make each big call before anything happens:
- Isolating or shutting down systems: the technical lead, with the incident commander told right away.
- Notifying clients and partners: the communications lead, with the commander’s approval.
- Engaging outside counsel or filing an insurance claim: the legal lead, with commander and executive approval.
- Paying a ransom: executives or the board only, after counsel and your insurer weigh in.
Settling this takes an hour. Debating it mid-attack costs far more.
2. Ask what your tools can actually tell you
Tools don’t replace decisions. They give you evidence. Answer four questions honestly:
- Who logged in, from where, and when?
- What ran on the computer, and did it spread?
- Can we rebuild the last 30 days of activity?
- When did we last test a full restore?
Any “not sure” is a gap. Here’s the harder version. If someone sat inside your systems for 30 days, would your tools have caught it?
3. Plan the first 30 minutes
Panic-driven actions often make incidents worse. Write the first steps down, in order, so nobody improvises.
Minutes 0 to 5: Stop the spread
- Don’t click or open anything suspicious.
- Call your IT partner right away. Don’t try to fix it alone.
- Unplug affected computers from the network. Leave servers powered on unless told otherwise, because memory holds evidence.
- Write down what’s on the screen. Ransom notes, error messages, and timestamps all count as evidence.
Minutes 5 to 15: Contain and protect
- List every device that may be affected or connected.
- Disable remote access tools, such as VPN and remote desktop, if you can.
- Don’t delete logs, emails, or messages.
- Tell leadership, and call your cyber insurance carrier.
Minutes 15 to 25: Assess and notify
- Decide what type of incident you’re facing.
- Check whether regulated or personal data may be involved, such as HIPAA, payment card, or client data.
- Engage legal counsel if data exposure is confirmed or suspected.
Minutes 25 to 30: Stabilize
- Name one internal point of contact.
- Set the time of the next update.
- Set up another way to communicate if email may be compromised.
- Start a written incident log.
One rule holds throughout. Don’t pay a ransom demand until you’ve talked to legal counsel, your insurer, and your IT partner.
Print the checklist and your contact tree. Keep one copy in a binder, one with leadership, and one offsite. Your systems may be down when you need them.
4. Write your messages before you need them
Silence in a crisis can look like incompetence or concealment. A rushed message can create legal trouble. The fix is drafting templates ahead of time for four audiences: employees, clients, vendors, and your board.
Every template does the same job. States what you know. Tells what you don’t know yet. It says what you’re doing. And it names a specific time for the next update.
Skip “we’ll update you when we know more.” Pick a time and keep it. Route every outside message through your IT partner and legal counsel first. Don’t post about the incident on social media, even vaguely.
Leadership needs a different message. Skip the technical walkthrough. Tell them what happened, what’s at risk, what you’re doing, and what decisions they may face. Brief ownership by phone first, then follow up in writing.
5. Decide your recovery order in advance
You can’t restore everything at once. Trying to is one of the most common recovery mistakes. Sort your systems into tiers before a crisis:
- Critical: back within 4 hours. The business can’t function without it.
- High: back within 24 hours. Downtime causes significant disruption.
- Standard: back within 72 hours. Operations can continue short-term.
Your tiers will differ. Work with your IT partner to set realistic recovery time and data loss targets. Unrealistic targets are one of the most common gaps that tabletop exercises uncover.
Then test your backups. An untested backup is an assumption. Restore a critical system, confirm its services start, and write down how long it took. Back up Microsoft 365 with a separate solution too. Microsoft’s built-in retention isn’t a backup.
Your insurance carrier cares about all of this. Carriers ask harder questions at every renewal, and they want documented evidence. Ask yours how long you have to report a claim. Hours and days are very different answers.
Where AI helps, and where it doesn’t
AI is already changing defense. IBM found that organizations using security AI and automation extensively contained breaches roughly two months faster. They also paid close to $2 million less. That’s the security side, run by professionals.
Your team’s everyday AI use during an incident is a different matter. It can save real time. It can also create a second incident. Our workbook uses one ground rule: AI organizes and drafts. Humans decide, notify, and approve.
Good uses
- Drafting staff, client, and vendor notices for human review.
- Turning raw notes into a clean incident timeline.
- Explaining the incident type to executives in plain language.
- Building an agenda for the leadership call.
- Outlining the post-incident report.
Keep AI away from
- IP addresses, computer names, usernames, or system names.
- Raw logs, error output, or malware samples.
- Network diagrams or firewall settings.
- Customer, health, financial, or other regulated data.
Even “sanitized” data can be traced back to you if it carries naming patterns unique to your company. When in doubt, leave it out.
Describe the situation generically instead. Don’t paste a server name and a time stamp. Ask, “A mid-size company’s main domain controller was encrypted overnight and backups are offline. What are the immediate containment steps?” You get a useful checklist without exposing a thing.
Three more habits help. Treat every AI answer as a first draft. Have a named person review it before anyone acts on it or sends it. And log what you asked, what came back, and what you did with it.
Know when to stop and call your IT partner. Do it when:
- Regulated data may be involved.
- Ransomware is active and you can’t tell how far it spread.
- Two hours have passed with no clear path to containment.
- You’re drafting a public, legal, or regulatory notice.
- An AI tool tells you something that contradicts your IT partner.
Put your rules in writing before you need them. IBM’s 2026 report found that 92% of organizations with an AI-related security incident lacked proper AI access controls. A one-page AI usage policy is a good first step.
Three tests of a real plan
Run your plan through three tests:
- Written. It has named people, named numbers, and named first moves. Not role titles.
- Tested. Your team walked through it in a tabletop exercise within the last 12 months.
- Known. More than one person can run it from memory, under pressure.
Fail any one, and you have a PDF instead of a plan.
Your next step
Score yourself honestly. Our workbook includes a gap scorecard covering readiness before, during, and after an incident, plus AI use. Pick your top five gaps. Give each one an owner and a date, and aim to close them in 30 days.
Then test the plan with your leadership team. A tabletop exercise finds problems that a document never will.
ADNET can help. We’ll walk through the workbook with you and validate your recovery targets. We can also run a private tabletop exercise built around your business. Start with a 30-minute Incident Response Gap Review. Reach out at Engagement@thinkadnet.com.
Sources: NIST SP 800-61 Rev. 3 (April 2025); IBM Cost of a Data Breach Report 2026.
ADNET Technologies | Engagement@thinkadnet.com
Rocky Hill, CT 860.409.1700 | Albany, NY 518.458.9300