---
title: "Tabletop Exercise Ransomware: Instructions and Scenarios"
date: 2026-03-10T09:55:00+01:00
author: FAST LTA
canonical_url: "https://www.fast-lta.de//en/blog/tabletop-exercise-ransomware-2"
section: "Entries: Articles"
---
### 1. What a Tabletop Exercise Is, and What It Is Not [\#](#1-what-a-tabletop-exercise-is-and-what-it-is-not "1. What a Tabletop Exercise Is, and What It Is Not")

#### Definition [\#](#definition "Definition")

A tabletop exercise (TTX) is a discussion-based exercise in which key personnel work through an incident scenario without taking physical actions on real systems. The focus is decision-making: who makes which decision, through which process, with what information?

#### What a TTX delivers [\#](#what-a-ttx-delivers "What a TTX delivers")

- Surfaces gaps in incident response plans before a real incident does
- Tests communication chains and escalation pathways
- Makes crisis responsibilities concrete (rather than leaving them on paper)
- Trains participants in crisis decision-making under time pressure
- Produces audit evidence for NIS2 compliance: Directive (EU) 2022⁄2555 requires incident handling and crisis management as part of risk management, and you must be able to demonstrate that these processes are practised

#### What a TTX does not deliver [\#](#what-a-ttx-does-not-deliver "What a TTX does not deliver")

- No technical recovery test (that is a separate disaster recovery test)
- No verification of backup integrity
- No red-team test of the infrastructure

TTX and technical recovery tests complement each other. They do not replace each other.

---

### 2. Preparation: Who Must Attend and What Is Needed [\#](#2-preparation-who-must-attend-and-what-is-needed "2. Preparation: Who Must Attend and What Is Needed")

#### Participant Profile [\#](#participant-profile "Participant Profile")

- **IT Manager / CISO:** technical decisions, escalation responsibility
- **CEO / Board member:** decision authority over ransom payment and press statements; under NIS2, management carries personal responsibility for cybersecurity oversight
- **Legal / Data Protection Officer:** GDPR notification obligations, liability questions
- **PR / Communications:** customer and press communication during a crisis
- **Owner of critical systems:** ERP, CRM, production systems as applicable
- **Finance / CFO:** cyber insurance, emergency budget
- **Facilitator (internal or external):** introduces scenarios, controls pace, documents outcomes

**Minimum group size:** 5 people. Ideal: 8 to 12. More than 15 makes discussion difficult to manage.

#### Materials and Preparation [\#](#materials-and-preparation "Materials and Preparation")

**Facilitator:**

- Print the scenarios (see Section 4) and keep them ready
- Set the time plan: opening (15 min) plus scenario (45 to 60 min) plus debrief (30 min)
- Designate a note-taker

**Participants:**

- Bring the current incident response plan, printed. This is part of the exercise: does it work when the PC does not?
- Bring the contact list of all external parties (regulatory reporting portal, cyber insurer, IR forensics firm, communications agency)
- Bring recovery runbooks for critical systems

**Important:** The facilitator does NOT announce the scenario in advance. Spontaneous reactions reveal realistic gaps.

#### Timing and Frequency [\#](#timing-and-frequency "Timing and Frequency")

- **Duration:** 2 to 3 hours for one complete scenario with debrief
- **Frequency:** At least annually as part of NIS2-aligned crisis management; recommended: twice per year
- **Scheduling:** Avoid peak workload periods

---

### 3. Facilitation Structure [\#](#3-facilitation-structure "3. Facilitation Structure")

#### Phase 1: Opening (15 minutes) [\#](#phase-1-opening-15-minutes "Phase 1: Opening (15 minutes)")

- The facilitator explains purpose and rules
- Key rule: there are no wrong answers; gaps should become visible, not hidden
- No phones or email during the session
- The note-taker is introduced
- The IR plan is on the table

#### Phase 2: Scenario Injection (3 to 5 minutes) [\#](#phase-2-scenario-injection-3-to-5-minutes "Phase 2: Scenario Injection (3 to 5 minutes)")

The facilitator reads the scenario. Participants listen without acting. Then: the first open question.

#### Phase 3: Discussion (40 to 50 minutes) [\#](#phase-3-discussion-40-to-50-minutes "Phase 3: Discussion (40 to 50 minutes)")

The facilitator poses prepared questions in phases:

- Phase A: initial response (0 to 15 minutes after incident detection)
- Phase B: escalation and decision-making (15 to 60 minutes)
- Phase C: recovery and communication (60 minutes onward)

The facilitator intervenes when needed: what happens if a key person is unreachable? Who decides if the CEO is on holiday?

#### Phase 4: Debrief (30 minutes) [\#](#phase-4-debrief-30-minutes "Phase 4: Debrief (30 minutes)")

All participants answer three questions:

1. What worked well?
2. What did not work or was unclear?
3. What is the single thing we should have implemented by next quarter?

The note-taker records everything. Output: an action list with owners and deadlines.

---

### 4. The Three Scenarios [\#](#4-the-three-scenarios "4. The Three Scenarios")

#### Scenario 1: Targeted Ransomware, the Classic Enterprise Attack [\#](#scenario-1-targeted-ransomware-the-classic-enterprise-attack "Scenario 1: Targeted Ransomware, the Classic Enterprise Attack")

**Difficulty:** Medium | **Recommended for:** First TTX

**Scenario text:**

Tuesday, 06:47. The first employee to log in sees an error message on screen. Within minutes, three more call the helpdesk. The helpdesk system is unreachable. The IT manager is notified and finds that on the file server, instead of normal folders, there are hundreds of files with an unfamiliar extension, plus a ransom note demanding contact within 72 hours.

Initial check: Active Directory still reachable. Email system: unreachable. ERP system: unreachable. Backup repository: status unknown; the backup server does not respond to ping.

Time: 07:15. The morning shift begins in 45 minutes.

**Phase A questions (initial response):**

1. Who decides whether the morning shift starts as planned, or whether employees are sent home?
2. Which systems must be isolated immediately, and who has the authority to do that?
3. What is the first internal communication? To whom? In what form (email may be down)?
4. When is the CEO informed, and by whom?

**Phase B questions (escalation):**

1. The backup repository is compromised. What does this mean for the recovery time estimate?
2. Do you have an air gap backup that the attacker could not reach? Do you know how current it is?
3. An external IT forensics firm needs to be engaged. Who decides that? Do you already have a retainer agreement?
4. When and how is the incident reported to the competent authority? (NIS2: early warning within 24 hours, notification within 72 hours)
5. When and how are affected customers informed? Who drafts the message?
6. The attackers have issued a ransom demand. Who decides whether to pay, and based on what criteria?

**Phase C questions (recovery):**

1. In what order are systems restored? Who determined that?
2. The ERP system needs an estimated 36 hours to restore. Production is halted. What manual emergency processes are available?
3. When is the incident ​“resolved”? How do you know?
4. What happens to data created between the last backup and the attack?

#### Scenario 2: Supply Chain Attack, a Compromised Service Provider [\#](#scenario-2-supply-chain-attack-a-compromised-service-provider "Scenario 2: Supply Chain Attack, a Compromised Service Provider")

**Difficulty:** High | **Recommended for:** Second TTX, NIS2-obligated organizations

**Scenario text:**

Thursday, 14:30. Your managed service provider calls: they have a security incident in their environment, customer systems may be affected, and they recommend disabling VPN access to their environment immediately.

Two hours later: three of your servers show unusual behavior. On one database server, data is being automatically transferred to an external address. The backup system, managed by the MSP, is unreachable.

Time: 16:45. In 15 minutes, a client meeting begins with one of your largest customers, which was planned to include access to shared system data.

**Phase A questions (initial response):**

1. Does the client meeting proceed? If yes: how do you behave without revealing the situation?
2. Which connections to the MSP must be severed immediately? Who does that, the MSP or your IT team?
3. How do you assess the reliability of information from the MSP? Does the MSP have an interest in downplaying the extent of the incident?
4. Which systems do you operate completely independently, without MSP involvement?

**Phase B questions (escalation):**

1. The MSP had access to your backup systems. How reliable are your backups now?
2. Do you have audit logs showing which actions the MSP performed in your environment?
3. What are your contractual rights against the MSP? Do you have audit rights? (NIS2 explicitly requires supply chain security measures.)
4. Is there a GDPR reporting obligation? Data is flowing to an external address, potentially personal data (Article 33: 72 hours to the supervisory authority).
5. Do you inform the customer arriving in 15 minutes? What do you tell them?

**Phase C questions (recovery):**

1. Can you restore systems without MSP support? Do you have access to all necessary data and documentation?
2. How do you replace the MSP over time, and which dependencies must be resolved first?
3. What changes do you make to supplier evaluation and monitoring going forward?

#### Scenario 3: Insider Threat, Sabotage by a Former Employee [\#](#scenario-3-insider-threat-sabotage-by-a-former-employee "Scenario 3: Insider Threat, Sabotage by a Former Employee")

**Difficulty:** Very high | **Recommended for:** Advanced TTX, critical infrastructure operators

**Scenario text:**

Monday, 09:00. The IT team notices that on Friday night, several backup jobs silently aborted, without alerting, because the monitoring system was simultaneously disabled. Additionally, three weeks of backup generations are missing: the jobs were logged as successful but stored no data.

IT forensics reveals: an administrator account belonging to an employee who left the company six weeks ago performed the manipulation. The account was not disabled after the departure.

Current backup status: the last valid backup is five weeks old. All more recent backups are empty.

**Phase A questions (initial response):**

1. What data loss has occurred? How do you assess the extent?
2. Why was the account active six weeks after departure? What does your offboarding process say about that?
3. Who else knew about this account?

**Phase B questions (escalation):**

1. Is there a GDPR reporting obligation? (Data integrity may be affected.)
2. Is there a criminal offense? (Computer sabotage laws may apply.) Will charges be filed, and when?
3. How do you communicate the incident internally without causing panic?
4. What other inactive accounts might exist in your environment? Do you have an inventory?

**Phase C questions (recovery):**

1. Five weeks of data are missing. Which data can be reconstructed from other sources (transaction logs, email attachments, external systems)?
2. Do you have an air gap backup that was not affected by the manipulation, because it was physically isolated and a stopped backup job would have triggered an alert?
3. What changes do you make to the user offboarding process? To backup monitoring?

---

### 5. Evaluation Framework: What Happens After the TTX [\#](#5-evaluation-framework-what-happens-after-the-ttx "5. Evaluation Framework: What Happens After the TTX")

#### Immediate Record (same day) [\#](#immediate-record-same-day "Immediate Record (same day)")

The note-taker summarizes:

- Which decisions were delayed or not made at all?
- Which processes did not work as expected?
- Which documents were missing or outdated?
- Which contacts were unavailable?

#### Action List (within one week) [\#](#action-list-within-one-week "Action List (within one week)")

For each identified gap:

- Action (what will be done?)
- Owner (who is responsible?)
- Deadline (by when?)
- Verification (how will completion be confirmed?)

#### Typical Findings from Ransomware TTX Exercises [\#](#typical-findings-from-ransomware-ttx-exercises "Typical Findings from Ransomware TTX Exercises")

- **Regulatory reporting obligations unknown or unclear:** very common. Remedy: training plus a deadline checklist (NIS2: 24h/​72h/​1 month; GDPR: 72h) in the IR plan.
- **No decision process for ransom payment:** common. Remedy: document the decision tree in advance.
- **DR plan not available offline:** common. Remedy: print and secure.
- **No air gap backup:** common. Remedy: introduce an air gap layer.
- **No pre-agreed external IR firm:** moderate. Remedy: establish a retainer agreement.
- **Customer communication without approved message templates:** moderate. Remedy: prepare communication templates.
- **Offboarding process incomplete (Scenario 3):** common. Remedy: add an IT step to the offboarding checklist.

---

### Further Resources [\#](#further-resources "Further Resources")

→ IT Resilience: Guide for Resilient Organizations (/en/blog/it-resilienz-leitfaden/) → From Level 2 to Level 4: The Most Efficient Path to Resilience (/en/blog/from-level-2-to-level-4-resilience/) → NIS2 Audit Preparation: Checklist for IT Managers (/en/blog/audit-preparation-nis2-checklist/) → Incident Response Plan: Template and Guide (/en/blog/incident-response-plan-vorlage/) → Air Gap as Resilience Layer (/en/blog/air-gap-resilienz-layer/)

### KRITIS (Critical Infrastructure)

KRITIS refers to organizations and facilities whose failure or impairment would cause significant supply shortages or threats to public safety — KRITIS operators are subject to heightened IT security requirements under §8a of the German BSI Act and must demonstrate compliance to the BSI every two years.

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/kritis-critical-infrastructure)

### Air Gap

An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/air-gap)

### GDPR

The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)

### GDPR

The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)

### GDPR

The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)

### GDPR

The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)

### Disaster Recovery

Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage.

[Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery)
