How Do You Test an Incident Response Plan?

The Quick Answer
A written incident response plan that's never been tested isn't a plan, it's a guess. Run it as a live tabletop exercise: a realistic event scenario, with the leadership team talking through decisions out loud as the situation unfolds. It surfaces the gaps a document alone could potentially miss, and it typically takes under two hours.

This is a pattern that shows up again and again, in businesses of every size: the incident response plan lives in a shared drive folder, written by a consultant who's since moved on. Nobody's opened it in a year. If ransomware hit tonight, the plan tells the team to call a number and follow steps stored on the same server that just got encrypted.

A document is not a response.

Having just a plan might make give you a false sense of preparedness. A plan is a set of good intentions written down in a calm moment. A response is what actually happens when systems are down, people are anxious, and decisions need to get made in minutes, not days.

Here's roughly how it plays out in a live tabletop exercise. The scenario starts small: 8:30 on a regular workday, the chief information officer (CIO) gets an alert that sensitive data has been exfiltrated, and early investigation traces it back to a compromised update from a trusted third-party vendor. The room is asked directly: do you have a plan, and what's the first step?

The answers that come back are usually a mix of instinct and gaps. A chief executive officer (CEO) wants an immediate scope assessment. A chief financial officer (CFO) starts thinking about financial exposure. The CIO wants systems isolated and legal engaged. All reasonable. What's often missing is whether anyone actually knows who's on the incident response team, or who's authorized to make the call to disconnect a system.

The plan gets written once and trusted forever.

Writing the plan might feel like finishing the work. Testing it feels like extra effort with no clear trigger, until the exercise itself becomes the trigger.

By the second phase of the scenario, the situation has escalated: the breach has been active for days, several departments are affected, and attackers are threatening to leak the data unless a ransom is paid. The questions get harder. Who talks to customers and media, and who talks to them first? Does the cyber insurance policy actually cover this, and does anyone in the room know who owns that policy or how to activate it? What gets restored first if backups can't come back immediately?

That last question tends to land the hardest, because most leadership teams have never actually worked out, in plain numbers, how much data they can afford to lose and how long they can afford to be down.

The plan you can't access during an outage isn't a plan during an outage.

Systems tend to go down exactly when the plan is needed most. If the plan only exists digitally, on the same network that's compromised, it's unreachable at the one moment it matters, which is why the plan needs an offline copy, a named person responsible for keeping it current, and a walkthrough at least once a year.

Confusion in the first hour costs more than the incident itself.

The numbers back this up more than most people expect. The average data breach in 2024 cost $4.88 million, the highest on record, and organizations took a mean of 194 days just to identify that a breach had happened at all (IBM Cost of a Data Breach Report). Separately, a human element, someone clicking, approving, or trusting something they shouldn't, was involved in the large majority of breaches. Real-world examples follow the same pattern this exercise is built around: the 2020 SolarWinds breach and the 2023 MOVEit breach both started with attackers coming in through a trusted vendor's software, then moving laterally once inside, not through some obvious front-door failure.

A plan you haven't practiced is a guess.

A tabletop exercise closes that gap, and it doesn't need to be elaborate:

1. Pick a realistic scenario, ideally one close to how your business actually operates, and walk it forward in phases as it would actually unfold.
2. Run it as a conversation, not a technical drill. Ask the room what they'd do next, out loud, before moving to the next phase.
3. Capture what breaks down. Where does the group hesitate? Who doesn't know their role? What's assumed but never confirmed, like who owns the cyber insurance policy or where the offline plan actually lives?
4. Document what you learned and revise the plan. The exercise isn't the deliverable. The updated plan is.

InsITe builds these tabletop exercises around what we see happening in businesses all the time. The confusion that shows up in a room during a live exercise is the same confusion that shows up during a real incident, which is exactly why it's worth working through once, in advance, rather than for the first time when it actually counts. The goal was never to get the "right answer" in the room. It's to surface the gaps before something like this happens for real.

If you ran this scenario in a room right now, would your team know who's in charge? Would they know where to find the plan if the network is the thing that's down?