Running a Recovery Drill: Tabletop Exercises That Find Your Gaps

RedHub AI Editorialupdated October 5, 20266 min read

A sealed, dusty drill kit box lit red on a long training-room table, the chairs stacked against the wall.
Jump to a section7

Run a tabletop exercise by putting the people who would respond to an incident in one room, reading them a realistic scenario, and asking each of them what they would do next, step by step. No real system gets touched. NIST SP 800-84 describes it the same way: a discussion-based exercise in which a facilitator presents a scenario and asks questions about it. The hour exposes the human gaps in a recovery plan: a decision nobody is empowered to make, a contact nobody has, a step that assumes something false. Finding those around a table is cheap. Finding them at 2 a.m. during a real attack is not.

TL;DR: A tabletop exercise is a talk-through of a realistic incident with the people who'd respond, with no real systems touched. Describe the scenario, walk each person through their steps, and write down every "I don't know" and "who does that?" Those are your gaps. Fix them, then run it again. A tabletop tests people, not backups, so pair it with a timed restore. The Ransomware & AI-Outage Recovery Readiness Drill ($79) scores your incident runbook and your restore as separate controls. Part of the guide on recovery readiness.

Why a talk-through beats a document review

Read a recovery plan and it looks complete. Reading is passive, and it lets your brain fill every gap with "we'd figure that out." A tabletop drags the gaps into the open by making people answer out loud, in order: "It's 9 a.m. Your files are encrypted and a ransom note is on the screen. What's the first thing you do?" The moment someone has to answer in real time, the vague parts of the plan show up: who declares the incident, who has the vendor's number, whether the person who runs restores can even be reached.

How to run one

  1. Get the right people in a room. Everyone who'd have a role in a real incident: the owner, whoever handles IT, whoever talks to customers, key operations people. An hour of their time is the whole cost.
  2. Pick a realistic scenario. "Ransomware locked our main systems this morning," or "our core AI tool is down and so is our backup login." Specific and plausible beats dramatic. You don't have to write one from scratch: CISA publishes Tabletop Exercise Packages with template scenarios and discussion questions, and ransomware is one of the topics they cover.
  3. Walk it minute by minute. First detection, first decision, first hour, first day. At each step, ask the responsible person what they would do, and push for a concrete answer.
  4. Write down every gap. Every "I'm not sure," "who handles that?" or "wait, is that backed up?" is a finding. Don't solve them mid-exercise; capture them and keep moving.
  5. Fix, then re-run. Turn the gaps into fixes, then run the scenario again later to confirm they're closed.
The gaps are the deliverable. A tabletop where nobody hesitates usually means the scenario was too easy or people were guessing to look prepared. A good one is a little uncomfortable, because it surfaces real "we never decided that" moments. Those findings are what the hour was for.

Gaps worth probing for

Some gaps are worth testing for on purpose. Nobody is clearly empowered to make the big calls, such as shutting systems down or how to respond to a ransom demand, which carries legal questions of its own and is one reason counsel belongs on the contact list. The emergency contacts (vendor, insurer, a technical helper) aren't gathered anywhere reachable. The communication plan is "we'll post something," with no message drafted yet. A dependency everyone assumed was covered turns out not to be. Every one of these is a decision or coordination gap, and a talk-through finds them faster than a systems test does.

What a tabletop can't tell you

A tabletop tests what people say they would do. It can't test whether the backup restores, how long the restore takes, or whether the person who says "I'd call the insurer" can find the number at 2 a.m. with their laptop locked. A smooth tabletop on an untested backup is still a plan that would fail. That's why the Readiness Drill scores the incident runbook (14 of its 100 points) and the timed end-to-end restore (22 points) as separate controls, and only the restore can force WOULD NOT RECOVER on its own. How well a calm hour in a meeting room predicts behavior under real stress is a question no exercise fully answers.

Make it a habit, not a one-off

One tabletop is far better than none, but readiness decays. People change roles, tools change, and last year's plan stops matching how the business runs. A short drill on a regular cadence keeps the plan honest and keeps the response fresh enough to be closer to habit than a document nobody has opened in a year. The Readiness Drill's own runbook gives the same advice for its incident-runbook control: walk the runbook in a tabletop exercise so the first time someone reads it isn't during the incident. Every gap you find feeds back into the ransomware recovery plan you're testing.

Score the plan your tabletop just tested

After a tabletop, put the findings into marks. The Ransomware & AI-Outage Recovery Readiness Drill rates each critical system 0, 1 or 2 on six controls, from an incident runbook and a comms and notification plan to a timed end-to-end restore and a fallback for load-bearing AI dependencies. Each system reads RESILIENT, GAPS or WOULD NOT RECOVER, and where a control is short, the drill names the one to drill first.

Get the Recovery Readiness Drill — $79

Pairs well with

The AI Incident Postmortem & Readiness Gate ($79) is the after-the-real-thing version: it grades a finished postmortem and returns CLEARED TO CLOSE AS DESCRIBED, FINISH ACTIONS or NOT CLOSEABLE. The Shadow AI Discovery & Risk-Triage Kit ($69) finds the AI tools your scenario forgot, with an amnesty inventory of what your team uses. The AI Vendor Reliability & Spend-Justification Scorecard ($79) grades the vendors whose numbers your tabletop found missing, on reliability and value.

More in this guide

What is a tabletop exercise for recovery?

It's a talk-through of a realistic incident with the people who'd respond. You describe a scenario and walk through each person's steps in real time, without touching real systems. NIST SP 800-84 calls it a discussion-based exercise led by a facilitator. Its job is to surface gaps cheaply, before a real incident does.

Who should be in a recovery tabletop?

Everyone who'd have a role in a real incident: the owner, whoever handles IT, the person who'd talk to customers, and key operations people. It's usually an hour of their time, which is the whole cost of the exercise.

What do tabletop exercises usually find?

Decision and coordination gaps more than technology failures: nobody empowered to make the big calls, missing emergency contacts, a communication plan with no message drafted, or a dependency everyone wrongly assumed was covered.

How is a tabletop different from testing a backup?

A backup test checks that the technology restores. A tabletop tests the people: who decides, who acts, who communicates. You need both. A working backup nobody can coordinate a restore around fails, and so does a great plan resting on a broken backup.

How often should we run a recovery drill?

Regularly, because readiness decays as people and tools change. A short drill on a steady cadence keeps the plan matching reality and keeps the response fresh, closer to habit than a document nobody has opened in a year.

What if our tabletop goes perfectly smoothly?

Be a little suspicious. It often means the scenario was too easy or people guessed to look prepared. A good drill is mildly uncomfortable and surfaces real "we never decided that" moments. A frictionless one may not be testing hard enough.

How it decides
Diagram of the Ransomware & AI-Outage Recovery Readiness Drill: six weighted controls, an untested-recovery gate, and a sample scoring 78 that still reads WOULD NOT RECOVER.

The gate this post refers to, drawn from the tool’s own logic. See the tool.