An incident response plan should be tested with a short, discussion-based exercise before a real cyberattack. Put the people who would make decisions in one room, present a realistic scenario in stages, and verify seven things: who is in charge, how the incident is reported, whether critical contacts and accounts are accessible, how the team contains damage, who handles legal and customer communications, whether backups can support recovery, and how lessons become assigned improvements. The goal is not to “win” the exercise. It is to find gaps while they are still inexpensive to fix.
Many small businesses have a response plan that looks reassuring on paper. The problem appears when the office manager cannot reach the IT provider, the backup administrator is on vacation, the cyber-insurance contact is saved only in an inaccessible mailbox, or nobody knows who may shut down a line-of-business system. A practical test turns those hidden assumptions into a short improvement list.
What is an incident response plan test?
An incident response plan test is a rehearsal of how your organization would detect, manage, communicate about, and recover from a cybersecurity incident. For most small businesses, the best first test is a tabletop exercise: participants talk through a scenario while a facilitator introduces new facts and asks what each person would do next.
This is different from a penetration test. A tabletop exercise should not attack production systems, encrypt files, disable accounts, or surprise employees. It tests decisions, information, authority, and coordination. Technical recovery tests can be scheduled separately with safeguards and a defined rollback plan.
The current NIST Cybersecurity Framework 2.0 treats incident response as part of an ongoing cycle that includes governing risk, identifying assets, protecting them, detecting events, responding, and recovering. NIST’s 2025 incident response recommendations also connect preparation and improvement across that entire cycle. In other words, a response plan is not a document to finish and shelve; it is an operating process to exercise and improve.
How often should a small business test its incident response plan?
There is no universal schedule that fits every organization, contract, regulator, insurer, and risk profile. A reasonable operating practice for many small businesses is a discussion-based test at least annually, with another exercise after a major technology, staffing, vendor, insurance, or regulatory change. Higher-risk organizations may need more frequent or more technical testing.
Your schedule should reflect written obligations and business risk. Review contracts, cyber-insurance requirements, professional guidance, and applicable laws with qualified advisers. Set a date and owner; “when things slow down” is not a schedule.
Test 1: Can everyone identify the incident leader and decision makers?
Start the exercise with an ordinary prompt: an employee reports that a shared folder is suddenly full of renamed files and a ransom note appears on one computer. Ask who receives the report and who becomes the incident leader.
Your incident response plan should name roles, not depend on one person always being available. Identify a primary and backup for business leadership, technical response, communications, documentation, legal coordination, insurance notification, and operational recovery. Then clarify authority. Who may disconnect a server? Who may authorize emergency spending? Who decides whether the office closes or switches to a manual workflow?
If every answer is “call the owner,” the plan has a bottleneck. If nobody can decide, it has a vacuum.
Test 2: Does the reporting path work when normal tools are unavailable?
Introduce a second fact: the suspected incident involves Microsoft 365, so employees have been told not to trust company email or Teams. Ask how staff report new information and how the response team communicates.
Test an alternate channel that does not depend on the affected system. That may be a phone tree, a separate emergency conference number, or another approved method. Keep an offline or otherwise independently accessible contact list for key employees, the IT provider, insurer, legal counsel, critical vendors, banking contacts, and law enforcement resources where appropriate.
Also test the first-report instructions for employees. They should know how to preserve what they saw, whom to contact, and which well-intended actions—such as deleting messages or repeatedly rebooting a device—could interfere with the response. Tailor those instructions with your technical and legal advisers.
Test 3: Can the response team reach systems, records, and outside partners?
Now assume the primary administrator account is locked and the usual password manager cannot be reached from an affected computer. Can authorized personnel still access domain registration, Microsoft 365 administration, firewall management, endpoint security, backups, business phones, and other critical services?
Verify that the business—not only an employee or outside vendor—has appropriately controlled administrative access, current recovery methods, and escalation paths. Do not read passwords aloud. Confirm that access exists and test it later through a controlled procedure.
Ask each outside partner what information they need when an incident is reported, how after-hours escalation works, and where responsibilities change hands. A managed IT provider can coordinate technical response, but business leaders, insurers, legal counsel, communications advisers, and specialized forensic firms may have different roles.
Test 4: Can the team contain damage without creating a second outage?
Add a difficult choice: activity appears on several devices, but the accounting team is processing time-sensitive payments. Ask what the team would isolate first and who can approve that step.
Your incident response plan should help people move quickly without improvising destructive actions. The right containment step depends on the evidence and environment. Disconnecting a workstation, disabling an account, blocking a network path, or taking a server offline can limit harm, but it can also interrupt operations or destroy useful evidence if done carelessly.
During the exercise, require participants to state what they know, what they are assuming, who is advising the decision, what business process will be affected, and how the action will be documented. The test is not whether a nontechnical leader knows every command. It is whether the right people can make a controlled, informed decision.
Test 5: Are legal, insurance, and communications decisions assigned?
Next, reveal that customer information may have been accessed and a reporter has called the front desk. Who determines notification obligations? Who contacts the cyber insurer? Who approves statements to employees, customers, vendors, regulators, or the public?
Do not make the exercise a quiz on breach law. Duties depend on the facts, jurisdiction, contracts, policy language, and information involved. Test whether the organization knows whom to consult and can provide accurate records quickly.
Create pre-approved holding-language principles rather than inventing a detailed public statement during the exercise. Communications should be accurate, coordinated, and limited to verified facts. Front-desk staff should know where to route questions and should not speculate.
Test 6: Can backups support the recovery the business expects?
Change the scenario again: affected systems are contained, but the team must restore operations. Ask which processes come back first, how clean restore points are selected, how restored data is validated, and what employees do while systems are unavailable.
A checkbox saying “backups completed” is not enough. Connect recovery to documented recovery time and recovery point objectives. A controlled restoration test should confirm that data is usable, credentials are available, dependencies are understood, and the recovery time is realistic.
Do not turn a tabletop into an unplanned production restore. Record the technical questions that need proof, assign a safe recovery test, and define success before that work begins. See ABS’s guide to RTO and RPO for the business decisions behind those targets.
Test 7: Does the exercise produce owners, deadlines, and a better plan?
Finish with an after-action review. Ask what slowed decisions, which information was missing, which responsibilities overlapped, and which assumptions proved false. Then convert each important finding into a specific task with an owner and due date.
Good findings are concrete: add an alternate insurer contact, document who can disable a Microsoft 365 account, verify an offline employee phone list, schedule a controlled restore, or clarify the managed IT provider’s after-hours escalation path. “Improve communication” is too vague to manage.
Update the incident response plan after the exercise, track unfinished actions, and schedule the next test. CISA offers customizable cybersecurity tabletop scenarios, including ransomware, phishing, and insider-threat situations. Those resources can help a facilitator build a realistic discussion without inventing every prompt from scratch.
A simple 60-minute cybersecurity tabletop exercise agenda
Keep the first exercise manageable:
- Ten minutes — set boundaries. Explain that the exercise is discussion-based, identify the scenario, and state that no production system will be changed.
- Ten minutes — initial report. Test reporting, leadership, documentation, and the first decision.
- Fifteen minutes — escalation. Add unavailable systems, compromised accounts, or conflicting operational priorities.
- Fifteen minutes — communications and recovery. Test external coordination, backup decisions, and temporary business processes.
- Ten minutes — after-action review. Capture strengths, gaps, task owners, deadlines, and the next exercise date.
A neutral facilitator helps keep the conversation moving and prevents the most senior person from answering every question. Someone else should take notes. The notes should record decisions and gaps without collecting unnecessary sensitive details.
Common incident response plan testing mistakes
- Testing only the IT team. Owners, office managers, communications staff, and outside advisers make critical decisions too.
- Using an impossible blockbuster scenario. Start with a credible incident your business could actually face.
- Trying to prove the plan is good. A useful exercise exposes weaknesses; an easy exercise protects egos.
- Changing production systems without safeguards. Keep the tabletop discussion-based and schedule technical tests separately.
- Ignoring vendors and insurers. Contact and escalation assumptions often fail at organizational boundaries.
- Ending without assigned work. Findings without owners and deadlines disappear.
What this means for Tallahassee and Thomasville businesses
Small businesses in Tallahassee, North Florida, Thomasville, and South Georgia rarely have a full internal security team. That makes coordination more important, not less. Your incident response plan should clearly connect business leadership with the local IT provider, cloud vendors, phone provider, copier and network support, insurer, and professional advisers that may be involved.
Advanced Business Systems can help document the technology side of that response: critical systems, administrative access, provider responsibilities, backup and recovery dependencies, escalation paths, and safe technical test plans. Our role is to help your team understand and operate its technology; legal, regulatory, insurance, and public-communications decisions should remain with the qualified advisers responsible for them.
If you want to turn a written plan into a practical exercise, call ABS at (850) 222-2308 or request a managed IT review. We can help you identify the technology questions your leadership team should be able to answer before an incident.
Frequently asked questions
Does a small business really need a written incident response plan?
If the business depends on email, cloud applications, customer data, payments, or networked systems, a written plan helps people coordinate under pressure. The plan can be concise, but it should identify roles, contacts, decision authority, critical systems, communications, containment, recovery, documentation, and follow-up.
Is a tabletop exercise the same as a penetration test?
No. A tabletop is a guided discussion that tests decisions and coordination. A penetration test actively evaluates technical defenses under a defined scope. Both can be useful, but they have different objectives and safeguards.
Should our managed IT provider run the exercise?
Your provider can facilitate or participate, but business leadership should remain involved. The exercise must test decisions that only the organization can make, including operational priorities, communications, spending authority, and coordination with legal counsel or an insurer.
What should we do after the exercise?
Write a short after-action report, assign each material gap to an owner, set due dates, update the plan, and schedule any technical validation that could not be performed safely during the discussion. Track the work to completion.