You Have an Incident Response Plan. Has Anyone Actually Tested It?
Your company has a cybersecurity incident response plan.
That's good.
Now imagine it's 8:10 on a Monday morning and employees suddenly can't open their files.
A message appears on several computers demanding payment.
Someone asks whether they should unplug their computer.
Another employee has already restarted theirs.
The owner wants to know whether the company should shut down.
Your IT provider is trying to determine what's affected.
Accounting needs to run payroll.
Someone asks whether cyber insurance should be called.
And then an employee says:
“Are we supposed to notify our clients?”
This is not the best time to open a PDF called Incident Response Plan and discover no one knows what happens next.
An Incident Response Plan Is Only Useful If It Works
Businesses increasingly have documented cybersecurity plans because their insurance carrier, compliance requirements, customers or IT provider told them they should.
But there is a major difference between having an incident response plan and actually being prepared to respond to an incident.
The National Institute of Standards and Technology updated its incident response guidance in 2025 with NIST Special Publication 800-61 Revision 3, emphasizing that incident response should be integrated into an organization's broader cybersecurity risk management—not treated as a document that sits separately from everyday business operations.
CISA goes a step further in its ransomware guidance: organizations should create, maintain and regularly exercise their cyber incident response and communications plans.
That word matters:
Exercise.
Because the first time your organization practices responding to ransomware should not be while ransomware is spreading through the network.
What Is a Cybersecurity Tabletop Exercise?
A cybersecurity tabletop exercise is essentially a controlled rehearsal of a cyberattack.
Nothing is actually encrypted.
No systems need to be taken offline.
Instead, the people who would be involved in a real incident sit together and work through a realistic scenario.
For example:
It is 8:10 a.m. Employees report that files are suddenly inaccessible. Several computers display a ransom note. Microsoft 365 still appears to be working. Your IT provider believes at least one server may be affected.
What happens next?
The exercise progresses from there.
Who makes the decision to disconnect systems?
Who contacts cyber insurance?
Can anyone access the insurance policy if the server is unavailable?
Who is authorized to communicate with employees?
Do you call law enforcement?
What happens if email stops working?
How will employees communicate?
Which systems need to come back first?
Who decides whether clients need to be notified?
Suddenly, a plan that looked perfectly reasonable on paper encounters the realities of running a business.
That's exactly what you want to happen during an exercise rather than during an actual attack.
CISA provides its own Tabletop Exercise Packages specifically to help organizations test roles, responsibilities, information-sharing processes, emergency procedures and recovery plans. Its scenarios include ransomware, phishing and other cybersecurity incidents.
The Exercise Usually Finds Things No One Expected
One of the most valuable parts of an incident response exercise isn't proving that everything works.
It's finding out what doesn't.
A business might discover that its plan says:
“Contact the cyber insurance carrier immediately.”
Simple enough.
Except the insurance policy is stored on the server currently being investigated.
Or perhaps only the controller has access to the insurance portal—and the controller is on vacation.
Another company may discover that its emergency contact list includes an employee who left two years ago.
Someone else may realize the backup system has been running successfully every night, but no one has recently tested whether the company can actually restore the critical application from it.
These aren't necessarily failures.
They're exactly why you test.
Your IT Team Shouldn't Be the Only People in the Room
A cyberattack quickly becomes more than an IT problem.
For a business with 20, 40 or 100 employees, the people involved in a tabletop exercise might include:
ownership or executive leadership;
IT or the company's managed IT provider;
accounting or finance;
operations;
HR;
legal counsel;
communications or marketing; and
anyone responsible for regulatory or client notifications.
Not every company needs every role.
But the exercise should reflect who would actually make decisions during a real incident.
Consider something as basic as shutting down the network.
From a cybersecurity perspective, disconnecting systems may help contain an attack.
From the business side, shutting down could also stop phones, cloud applications, scheduling, payment processing, production or access to critical records.
Someone needs to understand both sides of that decision.
One of the Most Important Questions: Who Is Actually in Charge?
During normal operations, reporting structures are usually clear.
During a cyber incident, they can become surprisingly ambiguous.
The IT provider may understand what needs to happen technically but doesn't have authority to shut down the company.
The office manager may be coordinating employees but shouldn't determine whether clients receive breach notifications.
The owner may expect IT to make every cybersecurity decision while IT assumes the owner is making the business decisions.
A good incident response plan establishes responsibilities before this happens.
A tabletop exercise verifies that everyone understands them.
CISA specifically recommends that incident response and communications plans be reviewed and understood across the organization's chain of command.
Then There's the Backup Question
Most businesses know they need backups.
The better question is:
What happens when you actually need them?
Suppose your primary server has been encrypted.
Can the backup be reached?
Was it affected too?
When was it last successfully tested?
How much data would be lost?
How long would restoration take?
Which system should be restored first?
Can employees work while restoration is underway?
CISA recommends maintaining offline, encrypted backups and regularly testing their availability and integrity in a disaster-recovery scenario.
A green checkmark beside last night's backup job tells you that data was copied.
It doesn't necessarily tell you whether your business can recover.
What Comes Back First?
This question sounds simple until someone has to answer it.
Imagine your company relies on:
Microsoft 365;
accounting software;
a line-of-business application;
shared files;
VoIP phones;
an electronic health record system;
CAD or design applications;
scheduling software; and
remote access.
If everything cannot be restored simultaneously, what comes first?
The answer should be based on business impact, not simply which server is easiest to restore.
For a medical office, scheduling or patient records may be critical.
For an architecture firm, project files may determine whether dozens of employees can work.
For a professional-services firm, email and document access may take priority.
For another company, accounting may be able to wait two days—but payroll cannot.
CISA recommends identifying which systems and data are most critical to operations and understanding their dependencies so organizations can establish restoration priorities before an incident occurs.
Can You Still Communicate If Email Is Down?
This is another common blind spot.
The incident response plan is emailed to everyone.
The emergency contact list is in SharePoint.
The cyber insurance information is stored in the company's document system.
The IT provider's phone number is in Outlook.
Then Microsoft 365 becomes part of the incident.
Now what?
An effective incident response plan needs a backup communication method.
That may include securely maintained offline contact information, alternate communications methods and clearly established procedures for who communicates with employees.
The same issue applies externally.
If clients, patients, partners, regulators or the public need information, who determines what can be said?
CISA specifically recommends maintaining a communications plan alongside the technical incident response plan, including procedures and prepared communications for cyber incidents.
Don't Forget Cyber Insurance Until After the Attack
Cyber insurance can be enormously valuable during an incident.
But the policy may also contain requirements concerning:
who must be contacted;
approved forensic firms;
legal counsel;
ransomware negotiations;
notification procedures; and
documentation.
Your organization should understand those requirements before independently hiring vendors or taking major actions during an incident.
A tabletop exercise is a good opportunity to ask:
Who has the policy?
Who is authorized to make the call?
What number do we call?
Does our IT provider know the process?
Do we already know which outside firms the carrier will involve?
Those are much easier questions to answer on a Tuesday afternoon than at 2:00 a.m. during an active ransomware attack.
What Should a Tabletop Exercise Actually Test?
For most growing businesses, the exercise doesn't need to be an elaborate all-day event.
A useful scenario can often reveal significant gaps by walking through a handful of questions:
Detection: How do we know something is wrong?
Escalation: Who needs to be notified first?
Containment: Who can authorize systems to be disconnected?
Communication: How do employees communicate if normal systems are unavailable?
Insurance: Who contacts the carrier and when?
Legal and regulatory: Who determines whether notification obligations apply?
Recovery: Which business systems are restored first?
Backups: Can the required data actually be restored?
Decision-making: Who has authority to make business-impacting decisions?
Documentation: Who records what happened and what actions were taken?
NIST has long recommended tests, training and exercises as a way for organizations to prepare personnel and evaluate their ability to respond to and recover from disruptive IT events.
The goal isn't to pass the exercise.
The goal is to find the weaknesses.
After the Exercise, Change the Plan
A tabletop exercise shouldn't end with:
“That went pretty well.”
It should end with a short list of improvements.
Maybe accounting needs an offline copy of important insurance information.
Maybe employee emergency contacts need updating.
Maybe the backup recovery process needs to be tested separately.
Maybe executives need a defined decision tree.
Maybe your IT provider needs authorization to take certain containment actions without waiting for someone who may not be reachable.
Maybe the incident response plan itself is three years old and describes technology the company no longer uses.
CISA's ransomware guidance recommends documenting lessons learned following incidents and using them to refine policies, plans and future exercises.
The same principle applies to a tabletop exercise.
Find the gap.
Fix it.
Then test again.
A Plan on Paper Is a Starting Point
The worst time to discover that your incident response plan doesn't work is during a live incident.
You don't need to know exactly what the next cyberattack will look like.
You do need to know how your business would survive a ransomware attack—who will make decisions, how your organization will communicate, where your critical information is stored and how your business will begin operating again.
That's the difference between having an incident response document and having an incident response capability.
For a growing business, a relatively simple tabletop exercise can expose assumptions that would otherwise remain hidden until the company is under enormous pressure.
And that's exactly when you don't want to find them.
Would Your Incident Response Plan Actually Work?
SNH Technologies helps organizations evaluate cybersecurity preparedness, incident response procedures, backups and recovery processes before they're needed in a real emergency.
A tabletop exercise can help identify where responsibilities, technology and business procedures don't line up—and give your organization the opportunity to fix those gaps before an actual cyber incident.
Test your cybersecurity response before an attacker does.