.svg)
How to Conduct a Realistic Cyber Crisis Simulation
Most organizations have a cyber incident response plan. Far fewer have stress-tested it. There is a significant difference between knowing what to do in theory and executing it when systems are down, information is incomplete, the clock is ticking, and every decision carries business consequences.
A cyber crisis simulation bridges that gap. Conducted well, it does not just test your playbook; it exposes gaps in your team's decision-making, communication, and coordination before a real incident forces them into the open. This guide explains how to design and run one that actually prepares your organization, not just your documentation.
Why Most Crisis Exercises Fall Short
The most common format for crisis preparedness is the tabletop exercise: a group of people in a meeting room discussing how they would respond to a hypothetical scenario. It is useful for reviewing processes, but it is not a simulation, and confusing the two is expensive.
Tabletop exercises measure what people say they would do. A realistic crisis simulation measures what they actually do under pressure. These are different things. Under stress, people improvise, miss steps, defer to the wrong person, or stall waiting for information that will never arrive in complete form.
"If a simulation is comfortable, it's useless. To train for pressure, you must induce the fog of war." — Kev Marriott, Senior Manager, Cyber, Immersive
A realistic simulation is designed to make teams uncomfortable — not as punishment, but because discomfort is the only way to surface the behaviors that will emerge in a real crisis. That is the starting point for any exercise worth running.
Get the Right People in the Room
One of the most common mistakes in crisis simulations is treating them as purely a technical exercise. Security analysts run through detection and containment steps, but the wider organization is absent. We are missing the people who will be making business decisions, communicating with customers, and fielding regulatory questions.
A realistic simulation tests the entire incident command chain, not just the blue team. That means:
- Technical responders — detecting, investigating, and containing the threat
- Incident commanders and SOC managers — coordinating the response and setting priorities
- Executive stakeholders — making business-critical decisions about customer notification, regulatory reporting, and resource allocation
- Legal, communications, and HR — handling the stakeholder and reputational dimension
"Cyber drills give you the capability to actually demonstrate resilience all through your organization — from the blue teamers responding and containing, through to the execs making the wider business decisions. It gives a real opportunity to prove the capability of your whole end-to-end incident crisis management team." — Kev Marriott, Senior Manager, Cyber, Immersive
Including executives in the exercise is not ceremonial. Crisis decisions — whether to shut down operations, who to notify first, when to engage law enforcement — belong to leadership. They need the same practice as the technical team.
Design for Pressure, Not Comfort
The scenario itself is where most simulations either succeed or fail. If participants can see a clear path forward, the exercise is a puzzle. Real cyber crises are rarely puzzles. They are, as crisis practitioners describe them, "wicked problems" — situations where every available path carries a cost, and the goal is to find the least bad option.
Three design principles help create that kind of pressure:
1. Inject incomplete and contradictory information
In real incidents, information is partial and often wrong. Teams receive conflicting alerts, discover that logs have been tampered with, and find that the infrastructure diagram does not match what is actually running. Design your scenario to replicate this. Feed teams information in fragments. Tell them 50% of servers are affected; then inform them five minutes later that the backup site is also compromised. Force decisions before the full picture is available — because that is exactly how real incidents unfold.
2. Create dilemmas, not just incidents
Build decision points where every option has a visible downside. Should you isolate affected systems now to stop the spread but halt operations? Or investigate first, maintaining business continuity but risking further compromise? Should you notify customers immediately, even if it means accepting reputational and legal exposure? Or wait until you understand the full scope, accepting a different legal exposure?
The Kobayashi Maru principle from crisis training applies here: design exercises where every path has a cost. This is the environment in which executives and teams will operate during a real incident.
3. Compress time and escalate organizational pressure
Use a Master Scenario Events List (MSEL) that moves at an accelerated pace. Alongside the technical response, introduce organizational pressure: an email from the board requesting a status update, a journalist requesting comment, and a regulator inquiry landing in parallel. This is the multi-dimensional reality of cyber crisis management, and teams need to practice navigating it.
"A lot of times when you're in a high crisis incident, there is going to be no best decision to make. There will be the least worst. Sometimes you'll hit that, sometimes you'll hit the worst — and you just have to build that ability to come back." — Kev Marriott, Senior Manager, Cyber, Immersive
Measure What Actually Matters
The outcome of a crisis simulation is only as valuable as what you measure from it. Subjective assessments — "the team performed well" or "we identified some gaps" — do not hold up in the boardroom and do not drive meaningful improvement.
Focus your measurement on observable, objective performance data:
- Time to Detect — from when the attack began to when the team recognized an incident was underway.
- Time to Escalate — from initial detection to executive notification
- Investigation Accuracy — what percentage of the scope did teams identify? What did they miss?
- Decision quality under uncertainty — were executive decisions made on the right information, at the right time, by the right people?
- Communication effectiveness — was the right information passed between technical and leadership layers without distortion or delay?
These metrics do two things: they give you a baseline, and they give you something to improve against. When you run the next simulation, you are not asking "did we do well?" — you are asking "did we detect faster, escalate more accurately, and make better decisions than last time?"
What boards and senior stakeholders reject are metrics that measure intent rather than execution: compliance pass rates, training completion percentages, or the existence of a playbook. These measure paperwork. Crisis simulations measure performance.
Treat It as a Program, Not a One-Off
A single crisis simulation is useful. A recurring simulation program is transformative. The difference lies in what organizations discover after the first run: that improvement takes cycles, not events.
The operational pattern that works is straightforward: prove what you can do, close the gaps the simulation identified, then prove again. That cycle — run, measure, improve, run again — is how organizations build genuine resilience rather than documented preparedness.
"The more you do it, the more capable you are. The more you practice it, the more capable you are. You have to get used to being comfortable in the uncomfortable." — Kev Marriott, Senior Manager, Cyber, Immersive
The quarterly cadence is the standard for organizations treating this seriously. It is frequent enough to maintain momentum and surface new gaps as threats and teams evolve, but spaced enough to allow genuine improvement between cycles.
The most common failure mode is losing that cadence. An incident occurs, an exercise is run, gaps are fixed, confidence returns — and then the program quietly stops because there has been no other incident. This is the moment organizations are most vulnerable, because skills atrophy, new staff have not been through a drill, and the muscle memory built in earlier exercises is fading.
Programs that sustain themselves share three characteristics:
- Someone owns them with clear accountability,
- They are funded as a line item rather than a discretionary expense, and
- Their results appear in board reporting alongside other resilience metrics.
What Good Looks Like: First 90 Days
For organizations building a crisis simulation program from scratch, the first 90 days should follow a clear structure:
- Days 1–30: Run a baseline simulation. Do not fix anything yet. The goal is an honest picture of where you are — detection speed, escalation paths, decision quality, and communication breakdowns.
- Days 30–60: Close the one or two most critical gaps the simulation surfaced. Run targeted capability-building on the specific failures teams experienced. Measure improvement on the metric that matters most.
- Days 60–90: Run the simulation again. Prove the improvement is real, not assumed. Show the board: here is where we were, here is where we are, here is the evidence.
Basically, this is the foundation of a security improvement program that holds up to scrutiny. It replaces "we think we're prepared" with "here is what we demonstrated."
Run a Crisis Simulation with Immersive
Immersive's Crisis Simulations are designed to test your whole organization — technical teams and leadership — against realistic, multi-dimensional scenarios with no clean answers. Built-in performance metrics give you objective data on where you stand and a baseline to prove improvement over time.