Why Crisis Simulations Are Non-Negotiable
Every organisation has an incident response plan. Very few have tested it under pressure. The gap between having a plan and being able to execute it when alarms are firing, phones are ringing, and the CEO is asking for answers is enormous. Crisis simulations, often called tabletop exercises, bridge that gap.
Over the past several years, we have designed and facilitated more than ten crisis simulation exercises for organisations ranging from 20-person startups to multinational financial institutions. What follows is a distillation of what works, what fails, and what we wish someone had told us before our first exercise.
Core principle: The purpose of a crisis simulation is not to test whether your plan is perfect. It is to reveal where your plan breaks down so you can fix it before a real incident does the revealing for you.
The Framework: How We Structure Every Exercise
After experimenting with various approaches, we settled on a framework that consistently produces meaningful results. It has five phases:
Phase 1: Scoping and Objectives (2-4 weeks before)
This is where most exercises succeed or fail, long before anyone sits down at the table. You need to answer three questions:
- What are we testing? Be specific. "Test our incident response" is too vague. "Test our ability to detect, escalate, and communicate a ransomware event within our 4-hour SLA" is testable.
- Who needs to participate? The most common mistake is limiting exercises to the IT team. Include legal, communications, management, and HR. In a real crisis, they will all be involved.
- What scenario is realistic for our organisation? The scenario must be plausible. An exercise about a nation-state APT targeting a 30-person accounting firm will not generate useful insights. A phishing-to-ransomware scenario will.
Phase 2: Scenario Design and Inject Timeline (1-2 weeks before)
The scenario is the backbone of the exercise. We build it as a series of injects: pieces of information delivered to participants at specific times that advance the scenario and force decisions.
A well-designed inject timeline follows a realistic escalation curve. Here is a simplified example for a ransomware scenario:
| Time |
Inject |
Target |
Decision Point |
| T+0 |
Help desk receives three tickets about slow file access on shared drives |
IT Support |
Escalate or troubleshoot? |
| T+15min |
SIEM alert: unusual PowerShell execution on domain controller |
SOC / IT Security |
Investigate or escalate to incident? |
| T+30min |
Ransom note appears on 40% of endpoints. File extensions changed. |
All participants |
Declare incident? Activate crisis team? |
| T+45min |
Journalist calls asking about "outage reports" from your customers |
Communications / Management |
What do you say? Who approves the statement? |
| T+60min |
Attacker contacts you via email demanding 15 BTC. Threatens data leak. |
Management / Legal |
Engage? Involve law enforcement? Pay? |
| T+75min |
CIRCL contacts you: they have intelligence on the threat actor group |
IT Security |
Share IOCs? Accept assistance? |
| T+90min |
Customer data confirmed exfiltrated. GDPR 72-hour clock starts. |
Legal / DPO / Management |
CNPD notification? Customer notification? Timeline? |
| T+105min |
Backup integrity check: 2 of 3 backup sets are encrypted. One offline backup is 48 hours old. |
IT Operations |
Recovery strategy? Accept data loss? |
| T+120min |
Board member calls demanding a full briefing in 30 minutes |
Management |
What do you report? What decisions do you need? |
Each inject is designed to test a specific capability: detection, escalation, communication, decision-making, or technical response. The scenario should be challenging but not impossible.
Phase 3: Logistics and Preparation (1 week before)
- Venue: A dedicated room, away from daily distractions. We have seen exercises derailed by participants checking email or taking calls.
- Materials: Printed inject cards, copies of relevant plans and procedures, a whiteboard or flip chart for tracking decisions and actions.
- Roles: You need a facilitator (who runs the exercise), an observer/scribe (who documents everything), and optionally a "simulation cell" that plays external roles (journalist, attacker, regulator).
- Ground rules: No phones, no judgment, no blame. The exercise is a safe space to make mistakes.
Phase 4: Execution (2-3 hours)
The facilitator is the most important person in the room. Their job is to:
- Deliver injects on schedule (or adapt timing based on participant progress)
- Prompt discussion when participants get stuck: "What would you do next? Who do you need to call?"
- Prevent dominant personalities from monopolising the conversation
- Keep the exercise moving while allowing enough time for meaningful discussion
- Introduce curve balls when things are going too smoothly
We typically run exercises for 2 to 2.5 hours. Shorter than that and you cannot develop enough pressure. Longer and participants lose focus.
Phase 5: Debrief and Reporting (immediately after + 1 week)
The debrief is where the real learning happens. Immediately after the exercise, while everything is fresh, conduct a structured hot wash:
- What went well? Start positive. Acknowledge effective actions and good decisions.
- What surprised you? These surprises are the exercise's most valuable output.
- Where did we struggle? Be specific. Was it a process gap, a communication failure, a knowledge gap, or a resource constraint?
- What are the top three things we need to fix? Limit to three. Trying to fix everything at once fixes nothing.
Follow up within one week with a written report that documents findings, assigns owners to remediation actions, and sets deadlines.
Lessons from 10+ Exercises: What We Have Learned
Lesson 1: Communication Fails Before Technology Does
In every exercise we have facilitated, the first failure is never technical. It is always communication. People do not know who to call. Escalation paths are unclear. The crisis communication plan exists but nobody has read it. The CEO's mobile number is not in the contact list. Fix your communication tree before you buy another security tool.
Lesson 2: Participants Vastly Underestimate Time Pressure
NIS2 requires an early warning within 24 hours and a full notification within 72 hours. GDPR requires notification to the CNPD within 72 hours. When participants experience simulated time pressure for the first time, the realisation hits hard. Most teams discover they cannot produce a quality incident notification within the required timeframe because they have never practised writing one.
Lesson 3: The Legal and Compliance Team Is Never Ready
Technical teams are accustomed to incident pressure. Legal, compliance, and communications teams often are not. Including them in exercises is not optional; it is essential. In Luxembourg, with its multi-regulatory environment (CSSF, CNPD, ILR), knowing who to notify, in what order, and with what information is a complex coordination challenge.
Lesson 4: Playbooks Without Practice Are Fiction
We have seen beautifully written incident response playbooks that fell apart within the first 15 minutes of an exercise because nobody had ever walked through them. The map is not the territory. Exercises reveal the difference between theoretical procedures and operational reality.
Lesson 5: Management Engagement Changes Everything
When the CEO or a board member participates in the exercise, the quality of discussion and the seriousness of follow-up actions increase dramatically. When management delegates to their teams, the exercise findings often gather dust. Push hard for senior participation.
How We Use Scenarium for Exercise Management
As exercises grew more complex, we found that managing injects, tracking decisions, and coordinating between facilitators using paper and spreadsheets became unwieldy. This is one of the reasons we developed Scenarium, our dedicated crisis simulation platform.
Scenarium allows us to design scenario timelines with branching paths (if participants make Decision A, they get Inject Set A; if they choose B, they get Inject Set B), manage multi-team exercises where different groups receive different information simultaneously, and capture real-time observations that feed directly into the post-exercise report. It is purpose-built for the kind of exercises we run.
That said, you do not need specialised software to run a good exercise. A well-prepared facilitator with printed inject cards and a stopwatch can deliver excellent results. The tool matters less than the preparation and facilitation quality.
Measuring Exercise Effectiveness
If you cannot measure it, you cannot improve it. Here are the metrics we track across exercises:
- Time to detect: How long from the first indicator to someone recognising there is a problem?
- Time to escalate: How long from detection to activating the crisis team?
- Time to first external notification: Could you meet the NIS2 24-hour early warning requirement?
- Decision quality: Subjective assessment by observers. Were decisions informed, timely, and well-communicated?
- Communication effectiveness: Did the right information reach the right people at the right time?
- Plan adherence: Did participants follow documented procedures? Where did they deviate, and why?
- Participant confidence: Pre- and post-exercise survey measuring self-assessed readiness (1-10 scale)
Track these metrics across multiple exercises to demonstrate improvement over time. This data is also valuable evidence for regulatory compliance, particularly under NIS2's requirement to test business continuity and incident response procedures.
Common Mistakes That Ruin Exercises
- Making the scenario too easy: If everyone is comfortable, nobody is learning. The scenario should create genuine dilemmas.
- Skipping the pre-exercise briefing: Participants need to understand the format, ground rules, and their roles before the exercise starts.
- Allowing devices: The moment someone opens their laptop to check email, they are mentally out of the exercise.
- Not assigning a dedicated scribe: Without documentation, the exercise's value evaporates within days. Every significant observation, decision, and action must be recorded.
- Failing to follow up: The exercise report should include remediation actions with owners and deadlines. Without accountability, nothing changes.
- Running the same scenario twice: Participants remember the answers. Vary your scenarios to test different capabilities and avoid "teaching to the test."
Getting Started: Your First Exercise
If you have never run a crisis simulation, start simple. A 90-minute tabletop exercise with your IT team and one or two members of management, based on a ransomware scenario, will reveal more about your readiness than any audit report. You do not need external facilitators for your first exercise, although an objective external perspective adds significant value.
The most important thing is to start. An imperfect exercise that happens is infinitely more valuable than a perfect exercise that remains on the planning whiteboard. Your team will learn, your plans will improve, and when the real incident comes, you will be glad you practised.