Planning and Conducting a Tabletop Exercise: How to Test Your Emergency Plan

Why Emergency Plans Need to Be Tested

An emergency plan is only as good as its last test. That sounds like a truism, but it hits a reality in which the majority of mid-market companies have never tested their emergency plans, or at best tested them once after creation.

The problem is obvious: an emergency plan is written under calm conditions. At the desk, with plenty of time and a clear head. In an actual emergency, conditions are fundamentally different: stress, time pressure, incomplete information, unsettled employees. And it is precisely under these conditions that the plan reveals whether it works.

The most common problems that surface during tests:

• Unclear responsibilities: The plan names roles, but the specific people do not know they hold that role.
• Outdated contact information: The IT service provider has a new hotline number, the IT manager's mobile number has changed.
• Missing decision authority: Nobody knows who may make certain decisions in the absence of the CEO.
• Unrealistic timeframes: The plan allows 30 minutes for situation assessment, but in practice just reaching the team takes 45 minutes.
• Communication gaps: Everyone focuses on the technical fix, but nobody informs employees or customers.

A tabletop exercise uncovers these weaknesses without requiring you to shut down systems or interrupt business operations. It is the ideal format for getting started with emergency exercises.

Overview of Exercise Types

Before we dive into the details of tabletop exercises, here is an overview of the four common exercise types. They differ in complexity, effort, and realism.

Tabletop Exercise (Wargame)

• Format: Facilitated discussion at a table
• Duration: 2 to 4 hours
• Participants: 6 to 15 people
• Realism: Medium (discussion only, no technical actions)
• Effort: Low (1-2 weeks preparation)
• Suitable for: Getting started, annual routine, testing new scenarios
• Cost: Minimal (staff time only)

The tabletop exercise is the workhorse of emergency exercises. It is relatively quick to prepare, requires no technical infrastructure, and brings the right people to one table. Participants discuss how they would respond to a fictional scenario, step by step, facilitated by an exercise leader.

Walkthrough Exercise

• Format: Detailed walkthrough of the emergency plan based on a scenario
• Duration: 4 to 8 hours
• Participants: 8 to 20 people (including operational teams)
• Realism: Medium to high (processes are reviewed in detail but not executed)
• Effort: Medium (2-4 weeks preparation)
• Suitable for: Validating new or revised plans, training new team members

The walkthrough exercise goes deeper than the tabletop. Here, participants don't just discuss what they would do; they go through the emergency plan step by step: page 5, section 3, step 1 — who does this? How exactly? Where is the instruction? Participants have the emergency plan in front of them and check whether it is complete and understandable.

Simulation

• Format: Realistic exercise with simulated system failures or attacks
• Duration: 4 to 8 hours (active exercise) + preparation and evaluation
• Participants: 10 to 30 people (all operational teams)
• Realism: High (systems are actually restored in a test environment)
• Effort: High (4-8 weeks preparation, possibly building a test environment)
• Suitable for: Validating technical recovery capability, meeting regulatory requirements

In a simulation, things get technical: a restore from backup is performed, recovery times are measured, and teams work under simulated stress conditions. This requires significantly more preparation but also yields the hardest-hitting insights.

Full Exercise

• Format: Complete emergency exercise under realistic conditions, possibly without advance warning
• Duration: 1 to 3 days
• Participants: Entire organization or large parts of it
• Realism: Very high (as close to a real emergency as possible)
• Effort: Very high (2-3 months preparation)
• Suitable for: Organizations with high maturity, regulatory requirements (e.g., critical infrastructure operators)

The full exercise is the gold standard. It is expensive, complex, and disruptive, but delivers insights that no other format can offer. For most mid-market companies, it only makes sense once the basic processes are already stable.

Which Type Fits You?

For SMEs, the tabletop exercise is the right starting point. It offers the best ratio of effort to insight and can be conducted without a dedicated BCM team.

Planning a Tabletop Exercise

Planning a tabletop exercise typically takes one to two weeks. The greatest effort lies in scenario development and scheduling.

Defining Objectives

Before developing the scenario, clearly define what the exercise should achieve. The objectives determine the scenario, participants, and evaluation criteria.

Typical objectives:

• Check whether the escalation chains in the emergency handbook work
• Test whether all participants know their roles and responsibilities
• Identify communication gaps between IT and business units
• Check whether reporting obligations (BSI, data protection) are known within the team
• Sensitize senior management to crisis management topics

Formulate objectives concretely and measurably. "Test the emergency plan" is too vague. "Check whether escalation from level 2 to level 3 occurs within 15 minutes and the correct people are informed" is concrete enough to evaluate afterward whether the objective was met.

Developing the Scenario

The scenario is the heart of the exercise. It must be realistic enough to be taken seriously and complex enough to trigger genuine discussions.

Characteristics of a good scenario:

• Realistic: It could actually happen to your organization. A ransomware attack on a mechanical engineering company is realistic. An asteroid impact is not.
• Gradually escalating: The scenario starts harmlessly and becomes increasingly serious. This creates natural discussion points and shows when participants escalate.
• Ambiguous: Not all information is available immediately. Participants must make decisions under uncertainty — just like in a real emergency.
• Time-sensitive: There are deadlines (NIS2 reporting deadlines: 24 hours, DSGVO (GDPR): 72 hours) that must be considered.
• Cross-functional: The scenario touches not only IT but also management, communications, legal, and business units.

Example Scenario: Ransomware Attack (three phases)

Phase 1 (Discovery): Monday, 8:30 AM

Several employees contact the help desk: they cannot log in to the ERP system. The help desk determines that the ERP server is unreachable. A message with a ransom demand of 2 Bitcoin (approximately EUR 180,000) appears on the server console. Files on the server are encrypted.

Questions for participants:

• What are your first three actions?
• Who do you inform first, and through which channel?
• Which escalation level applies?

Phase 2 (Escalation): Monday, 10:00 AM

The investigation shows: not only the ERP server is affected. The file server and two additional servers are also encrypted. The attackers appear to have been in the network for at least three days. Customer data and personnel data were stored on the file server. This is where the GDPR data breach topic becomes relevant. Initial media inquiries arrive — a customer has posted on LinkedIn that they received no delivery and the company is unreachable.

Questions for participants:

• How do you assess the situation now?
• Who communicates what externally?
• What reporting obligations exist? To whom and by when?
• How do you handle the ransom demand?
• What data has potentially been exfiltrated? What does this mean?

Phase 3 (Recovery Decision): Monday, 2:00 PM

The backups have been checked. The last undamaged full backup of the ERP server is from Friday, 10:00 PM. The transaction log backups from Saturday and Sunday are also encrypted. This means: in the best case, you lose the data from Monday before the attack (approximately 2 hours of work); in the worst case, all data since Friday 10:00 PM. The external forensics provider is not available until tomorrow morning. Production remains at a standstill.

Questions for participants:

• How do you prioritize the recovery?
• Can you safely restore systems without letting the attackers back into the network?
• How long can production remain idle?
• Do you need external help? If so, whom?
• How do you communicate the status to employees and customers?

Selecting Participants

The participant selection determines the quality of the discussion. Invite the people who would actually be involved in a real emergency.

Core group (should attend every exercise):

• Senior management (at least one member)
• IT manager and deputy
• Information security officer (if applicable)
• Data protection officer

Extended group (depending on scenario):

• Head of production / operations
• Head of sales / customer service
• Head of HR
• Head of finance
• Corporate communications / PR
• External IT service provider (optional but valuable)

Roles during the exercise:

• Exercise leader (Facilitator): Leads the discussion, presents the scenario, asks targeted questions, maintains focus. Ideally someone who is not part of the emergency team.
• Observer/note-taker: Documents the discussion, notes findings, records decisions and open items. At least one person, preferably two.
• Participants: Everyone else. They discuss, make decisions, identify gaps.

Checklist: Preparing the Tabletop Exercise

PLANNING (2-4 weeks in advance)
□ Exercise objectives defined
□ Scenario developed (with phases and questions)
□ Participant list created and schedules aligned
□ Exercise leader designated
□ Observer/note-taker designated
□ Room reserved (with projector/screen, whiteboard, flipchart)

PREPARATION (1 week in advance)
□ Invitation sent with: date, location, duration, exercise objective (NOT the scenario!)
□ Participants asked to read the current emergency plan beforehand
□ Scenario materials prepared (handouts for each phase)
□ Evaluation form prepared (which aspects to observe?)
□ Current emergency plan printed in sufficient copies
□ Name cards with roles prepared (exercise leader, observer, participant)

ON THE DAY OF THE EXERCISE
□ Room prepared (seating, technology, beverages)
□ Emergency plan and handouts distributed
□ Name cards placed
□ Protocol template ready
□ Schedule posted on the wall or on a slide

Conducting a Tabletop Exercise

Schedule (Plan for 3 hours)

Welcome and Ground Rules

The exercise leader opens the exercise with a brief introduction:

• Purpose: This is a learning and improvement exercise, not an exam. There is no right or wrong.
• Confidentiality: What is discussed in this exercise stays in this room. No one will be exposed for wrong answers.
• Realism: Please respond as you would in a real emergency, not as the plan says you should. If you don't know the plan, say so. That is a valid finding.
• Timeframe: We have three hours. I will guide the discussion and move on if we spend too long on any one point.
• Phones: Please put them on silent. We need everyone's full attention.

Running the Scenario Phases

The exercise leader presents Phase 1 of the scenario, ideally via projector or as a handout. Participants have a few minutes to grasp the situation. Then the discussion begins.

Tips for the exercise leader:

• Ask open questions: "What would be your first three actions?" rather than "Would you shut down the server?"
• Probe deeper: If someone says "I would call the service provider," ask: "Which service provider? Do you have the number? How do you reach them outside business hours?"
• Involve quieter participants: "Ms. Schmidt, from the accounting perspective — what does the ERP outage mean for your department?"
• Manage group dynamics: Don't let the loudest person dominate the conversation. In a real crisis, everyone needs to be heard.
• Simulate time pressure: "It's now 10:00 AM. The 24-hour deadline for the BSI report has been running since 8:30 AM. Who has prepared the report?"
• Reference the emergency plan: "Look at the emergency plan: what does it say for this scenario? Can you find the information quickly?"

What Should Be Observed

The observer pays attention to the following aspects and documents their observations:

Communication:

• Is the escalation chain followed?
• Are all relevant people informed?
• Are customers and partners considered?
• Is internal communication to employees addressed?

Decision-making:

• Who makes which decisions?
• Is there clear decision authority?
• Are decisions documented?
• How is uncertainty handled?

Emergency plan usage:

• Is the emergency plan consulted?
• Can participants find the relevant information quickly?
• Is the information complete and current?
• Is information missing that would be needed in a real emergency?

Reporting obligations:

• Are reporting obligations (BSI, GDPR) recognized?
• Do participants know the deadlines?
• Does anyone know how to practically submit the report?
• Is it clear who drafts and submits the report?

Collaboration:

• Do IT and business units work together or side by side?
• Is senior management involved?
• Are external partners (service providers, forensics) contacted in time?

Evaluation and Feedback

The final 25 minutes of the exercise are at least as important as the scenario itself. This is where insights are distilled.

Evaluation structure:

1. Quick round: Each participant states their most important insight in one sentence.
2. What went well: Which aspects worked? What did the team do well?
3. What needs improvement: Which gaps were identified? Where did things get stuck?
4. Top 3 priorities: Jointly identify the three most important improvement measures.
5. Next steps: Who does what by when?

Documenting and Evaluating Findings

Documenting findings is the lever that turns a discussion into a measurable improvement. Without proper documentation and follow-up, the insights evaporate.

Finding Categories

Structure findings into categories so they can be prioritized and assigned:

Finding Assessment Matrix

Not all findings have the same urgency. A simple assessment matrix helps with prioritization:

Exercise Report

The exercise report is the formal result of the tabletop exercise. It documents the process, the findings, and the derived measures. For regulatory requirements (NIS2, ISO 27001), it simultaneously serves as evidence that you test your emergency plans.

Exercise report structure:

EXERCISE REPORT: TABLETOP EXERCISE [Date]

1. Framework Data
   - Date, location, duration
   - Participants (with roles)
   - Exercise objectives

2. Scenario Description
   - Summary of the scenario with all phases

3. Progress
   - Summary of discussion and decisions per phase
   - Observer's notes

4. Findings
   - Tabular listing of all findings with category and rating

5. Action Plan
   - Prioritized list of measures
   - Responsible person and deadline per measure

6. Conclusion and Recommendations
   - Overall assessment
   - Recommendation for next exercise (type, scenario, timing)

Follow-Up: Turning Findings into Actions

The real work begins after the exercise. Findings must be converted into concrete measures and tracked. Otherwise, the exercise was a pleasant team-building activity but not an improvement.

Creating an Action Plan

For each finding rated "Critical" or "High," a measure is defined:

Follow-Up Tracking

The action plan is not created once and then forgotten. Schedule a fixed date 4 to 6 weeks after the exercise to review the status of the measures. Open items are worked through until all measures are completed or consciously deferred.

In ISMS Lite, findings are captured as action items and can be tracked with responsible persons, deadlines, and status — 500 Euro pro Jahr for all modules without user limits. The next tabletop exercise then shows whether the measures have actually taken effect.

How Often Should You Exercise?

The answer depends on your BCM maturity level:

Minimum: Once per year a tabletop exercise. This is the recommendation for organizations just getting started and also the minimum frequency that auditors expect for ISO 27001 or NIS2.

Recommended: Twice per year, with different scenarios. A ransomware scenario in spring, a data center outage in fall. This way you cover different threat types.

Advanced: Quarterly with different formats. Q1: Tabletop exercise, Q2: Restore test, Q3: Walkthrough with new scenario, Q4: Simulation or announced emergency test.

In addition to planned exercises, a lessons-learned workshop should take place after every real security incident to feed the insights from the incident into the emergency plan.

Scenario Library: Five Scenarios to Get Started

If you need inspiration for scenarios, here are five suggestions that are relevant and realistic for mid-market companies:

Scenario A: Ransomware with Data Exfiltration

The classic described above. Encryption plus potential data exfiltration. Tests: incident response, communication, reporting obligations, backup/restore decision, handling ransom demands.

Scenario B: Cloud Provider Outage

Your Microsoft 365 tenant has been unreachable for 6 hours. Email, Teams, SharePoint, OneDrive — all offline. Microsoft reports a "service degradation" with no ETA for resolution. Tests: dependency on cloud services, communication without email, manual workarounds, customer communication strategy.

Scenario C: Insider Threat

A recently terminated employee copied large amounts of data to a USB drive before their departure. Access rights were only revoked three days after the last working day — a typical problem when user lifecycle management is lacking. The data includes engineering drawings and customer lists. Tests: offboarding process, access control, evidence preservation, legal actions, communication.

Scenario D: Supply Chain Attack

A software update from your antivirus vendor has a bug: after installation, computers no longer boot (blue screen). 80% of workstations and 60% of servers are affected. Tests: handling a mass outage, prioritizing recovery, coordinating with the software vendor, alternative work environments.

Scenario E: Physical Incident

Water pipe burst above the server room over the weekend. The caretaker notices the damage on Sunday evening. Several servers and the storage system show water damage. The UPS has shut down. Tests: emergency chain outside business hours, insurance notification, alternate site, restore from offsite backup.

Common Mistakes in Tabletop Exercises

Mistake 1: The Scenario Is Too Simple

"The mail server goes down. What do you do?" There is a quick, obvious answer, and the exercise is over in 20 minutes. A good scenario escalates, contains ambiguities, and forces difficult decisions.

Mistake 2: Senior Management Is Absent

Without senior management, the decision-makers who determine budget, external communication, and strategic decisions in a real emergency are missing. At the same time, the exercise is an opportunity to raise management awareness of the topic.

Mistake 3: Only Technical Issues Are Discussed

Tabletop exercises frequently revolve exclusively around technical questions: Which server do we restore first? Which backup do we use? The more important questions are often organizational: Who informs the customers? Who submits the BSI report? Who decides on the ransom demand?

Mistake 4: No Follow-Up

The exercise was productive, participants learned a lot, findings are documented. And then nothing happens. Six months later, nobody has addressed the identified gaps. Without follow-up, the exercise is worthless.

Mistake 5: Blame Assignment

If the exercise turns into a search for culprits ("Why don't you have the number?"), participants will stay silent next time. A tabletop exercise is a learning event, not a tribunal. The exercise leader must establish this atmosphere from the very beginning.

Next Steps

You now have everything you need to plan and conduct a tabletop exercise. The pragmatic approach:

1. Find a date — Block 3 hours when IT management and senior management can attend. This is often the hardest step.
2. Choose a scenario — For the first exercise, the ransomware scenario is recommended. It is realistic, relevant, and experience shows it generates the best discussions.
3. Have the emergency plan ready — The exercise only reveals gaps when participants actually consult the plan. If you don't have one yet, read the article on IT emergency handbooks.
4. Conduct the exercise — Follow the schedule, capture findings.
5. Implement measures — This is the step that makes the difference. No findings without measures, no measures without a deadline and a responsible person.

Further Reading

• IT Emergency Handbook: Structure, Content, and PDF Template
• Creating an Incident Response Plan: Template and Practical Example
• Creating a Recovery Plan: Guide with Template for SMEs
• Recognizing, Assessing, and Reporting Security Incidents — The Complete Process
• Backup Strategy and Restore Tests: Because Backups Alone Are Not Enough

As a next step, you can combine the exercise with a technical restore test — the article on backup strategies and restore tests will help with that.