This article is for whoever has to facilitate a recovery tabletop: an IT manager, a service owner, or a continuity coordinator. It assumes you can get six to ten people into a room, or onto a call, for two hours, and that you want the session to find real gaps rather than produce a reassuring slide.
What a tabletop is for
A tabletop exercise is a structured discussion of a scenario. Nothing is restored, failed over or switched off. Participants describe what they would do, in what order, with what information, and the facilitator keeps feeding them new developments.
That makes it the cheapest recovery exercise and the only safe one if you have nowhere isolated to restore into. It is good at finding problems of coordination and knowledge: who decides, who is told, what nobody has written down, which two teams each assume the other owns a task. It is bad at finding technical defects. A tabletop cannot tell you that a backup is corrupt or that a restore takes nine hours, because nobody performs one. People who run only tabletops can build real confidence in a plan whose technical core has never been run. Treat the tabletop as the first rung of a ladder described in designing a recovery drill, not as a substitute for restore work.
Guidance on exercise types, including tabletop and functional exercises, is published in NIST Special Publication 800-84 on testing, training and exercise programmes for IT plans and capabilities; it is worth consulting for vocabulary, though you do not need to follow it to run a useful session.
Before the session
Fix the objectives
Write three or four objectives that the exercise could fail. Examples:
- Confirm that the on-call engineer and the duty manager agree who declares a disaster, and on what information.
- Find out whether anyone outside IT knows how customers would be told.
- Identify every piece of information needed in the first hour that is stored only on the affected systems.
Objectives like “raise awareness” cannot fail and therefore teach nothing.
Choose the participants
Include the people who would actually be involved: the technical operators, the service owner, whoever speaks to customers or staff, and a decision-maker with authority to spend money or accept a risk. Invite the person who knows the unglamorous detail, such as how the backup tapes are retrieved or who holds the registrar login. Tell them in advance that the exercise tests the plan and not them.
Assign a facilitator who does not play a role, and a scribe who does not speak. The scribe’s notes are the output.
Write the scenario and the injects
The scenario is the opening situation. The injects are new facts released at planned times that force decisions. In emergency-management practice the schedule of injects is called a master scenario events list; a simple table works.
Here is a short example for a ransomware-style scenario, using only events that the facilitator announces:
| Time | Inject | Question the facilitator asks |
|---|---|---|
| 0:00 | Monday 07:40. The service desk receives six calls: files on the shared drive will not open and have odd extensions. | Who is told first, and who decides whether this is an incident? |
| 0:15 | A ransom note is found on a file server. The security lead wants the network isolated. | Who has the authority to take systems offline? What does the business lose when you do? |
| 0:30 | Backup console shows the last successful job is 3 days old; the repository is a network share mapped on the domain. | What does this tell you about the backups? Which copy would you trust? Who checks? |
| 0:50 | The managing director asks for a time by which email and the order system will be back. | What do you say, based on what? Does anyone have a measured figure? |
| 1:10 | A major customer emails asking whether their data was affected. | Who replies? What do you know, and what must you not claim yet? |
| 1:30 | The person who holds the offline backup rotation is on leave abroad. | Who else can reach the copy? Is that written down? |
Notice that most injects are about information, authority and communication. Technical injects (“the restore fails at 80%”) are possible but tell you only what people would try; they do not tell you whether the restore would fail.
Keep the scenario plausible for your environment and specific to what you run. A scenario that reads like a vendor brochure invites generic answers.
Running the session
Open by stating the purpose, the ground rules, and the safety rule: this is an exercise, no real systems are touched, nothing said is a performance review. Say that “I don’t know” and “I think someone would know” are valuable answers and will be recorded as findings, not penalised.
Then work the scenario:
- Read the opening situation. Ask each role in turn what they do in the first fifteen minutes and what information they need.
- Release injects on schedule. After each, ask the question in the table, and follow the answers: How would you know that? Where is that written? Who has access? What if that person were unavailable?
- Make the implicit explicit. When someone says “we’d restore from backup”, ask which backup, from where, with whose credentials, in what order, and how long it would take. Ask for the number, then ask where the number came from. The answer “I think it’s about an hour” is a finding about unmeasured RTO (see RTO and RPO).
- Keep time. Cut long technical tangents with “write that down; let’s keep moving”.
- Close with a short round: what surprised you, what would you change first?
A good facilitator’s habit is to ask “and then?” until the participant either runs out of plan or reaches a point where the business is back to normal. The first outcome is the useful one.
Questions that find gaps
Keep a few prompts ready:
- Where is the runbook, and could you open it if the primary site were unreachable?
- Who can authorise spending, or buying hardware, outside business hours?
- Which logins do you need to start, and where are they stored? Could you reach them in this scenario?
- Which dependency would you restore first? Why that one?
- What are customers or staff told at one hour, four hours, a day?
- How would the team communicate if email and chat are unavailable?
- What is the worst decision someone could plausibly make in the next ten minutes, and what would stop them?
What the output should look like
Within a few days of the session, issue a short record containing:
- Date, participants and roles, scenario summary, and the injects used.
- Findings, each written as an observation rather than a judgement (“No participant could say where the offline copy is held”), grouped by theme: decision rights, communication, information and access, technical assumptions.
- For each finding, a proposed action, an owner and a due date.
- The things that went well, so they are not accidentally changed.
- A statement of what the exercise did not test. At minimum: it did not verify any backup, restore or recovery time.
That last line is not decoration. It stops the document being quoted later as evidence of technical readiness. The same applies if the output is shown to a customer, an insurer or an auditor: describe what it was, a discussion-based exercise, and do not describe it as a restore test. For details of tracking the fixes, see the after-action review article.
Making the next one harder
Repeat at a sensible interval, such as once or twice a year, and change something each time: a different scenario, a different incident lead, a key person declared unavailable. Move toward the technical by adding a walk-through where participants open the runbook and show the actual console they would use, and then toward a functional exercise once you have a safe place to restore.
Common mistakes
- The facilitator is also a subject-matter expert. They end up answering questions and defending the plan. Use a facilitator who does not have to be right.
- Too many people, too little structure. More than a dozen participants produces observers, not discussion. Split by service if needed.
- A scenario that cannot fail. If everyone has the right answer, the scenario was too easy or the answers are being given out of politeness.
- Letting the senior person set the answer. Ask juniors first. Their account of what they would actually do differs from what the plan says, and the difference is the finding.
- No follow-through. The notes go into a folder, nothing changes, and the participants conclude that exercises are theatre.
- Calling it a test of the backups. It is not. Say what it was.
What to do next
Write your three objectives and a six-row inject table for the scenario you fear most. If you want a scoped starting point, the drill planner proposes a scenario, roles and success criteria from your answers; it does not run or assess the exercise. The one-page drill checklist covers the parts of the day that are the same for every exercise type.