Using a Cyber Security Simulation Exercise to Test More Than Technology

Your incident response plan looks solid on paper. But the last time you ran a simulation exercise, you were testing whether your SIEM fired, not whether your people could function under pressure, communicate across teams, or make sound decisions at 2 a.m. with incomplete information.

Most organizations design cyber security simulation exercises around their detection stack. Tooling gets validated. Containment procedures get walked through. Then the exercise ends, the report gets filed, and the team goes back to normal operations with a quiet confidence that may or may not be warranted. The harder gaps (who calls legal, who owns the board message, what happens when your identity provider is part of the incident) go untested until a real breach forces the answer.

This guide covers how to design simulation exercises that stress-test people, processes, and communications alongside your technology, so your team can respond from a position of strength when the real call comes in.

Why Most Simulation Exercises Produce False Confidence

The industry average tells a clear story: roughly 40% of organizations run tabletop exercises with any regularity. Of those, a significant portion run scenarios that are essentially documentation reviews. A facilitator walks through a ransomware scenario, the IR team nods along, and the exercise is marked complete. The technology is tested. The human system around it is not.

That false confidence is expensive. The average IR team activation time is five hours from the moment an incident is declared to the moment the full response team is operational. Five hours. Organizations that build and test their processes ahead of time cut that to less than one hour. That speed comes from the discipline of having tested what happens before the tools become relevant: the notifications, the calls, the decisions, the coordination.

85% of ShadowHQ users run tabletop exercises versus 40% of the broader industry. That gap is not explained by intent. Most security teams want to run exercises more often. The gap is execution: no platform, no scenario library, no structured facilitation process, and a cost structure that prices quarterly exercises out of reach for most budgets. External tabletop facilitators run $30,000–$50,000 per engagement. At that cost, most teams run one exercise per year, which effectively means they're testing where their program was twelve months ago.

Building a sound preparation framework requires frequency, not just depth. One well-designed annual exercise is better than no exercise, but one exercise per year cannot keep pace with the rate at which your team composition, threat environment, and technology stack change.

The Three Dimensions Most Exercises Ignore

A well-designed simulation exercise covers three dimensions that most standard tabletops leave on the table: people, processes, and communications. Technology is the fourth dimension, well-represented in most exercises and the least likely to be the point of failure in an actual incident.

People

The question most simulation exercises do not answer is whether your team can function under realistic stress conditions. Running a playbook against a sandbox environment is not the same as working through the moment when you realize your lead analyst is unreachable, your CISO is traveling, and someone needs to decide whether to take a production system offline.

Who has the authority to make that call? Who thinks they have the authority but does not? What happens when two people in the room reach different conclusions? These are not exotic scenarios. They are the scenarios that determine whether your response accelerates or stalls in the first thirty minutes.

Exercises should surface human gaps directly. Introduce personnel unavailability mid-simulation. Build in role conflicts. Ask participants to articulate who owns a decision before they make it. The goal is not to embarrass anyone; it is to find the confusion before an attacker benefits from it. Designing this kind of decision structure in advance is what separates teams that respond with clarity from teams that respond with chaos.

Processes

Playbooks that have never been tested under realistic conditions are not playbooks. They are documentation. The process gaps that cause incidents to spiral are rarely the ones anyone anticipated. They are the missing handoffs: the moment when IT has contained the environment and nobody has told legal, or when the escalation criteria for notifying regulators exist in a document nobody can find.

Every exercise should answer one question about your processes: does this hold when something unexpected happens mid-incident? Not mid-exercise, mid-incident. The scenarios should include complicating variables that force improvisation and expose where your process has undocumented assumptions baked in.

Compliance frameworks make tested processes non-optional. Regulators and insurers are not satisfied with documentation of a process that has never been executed. They want evidence of execution. An exercise that produces a written after-action report with tracked remediation items is compliance evidence. An exercise that produces a verbal debrief and a deck nobody will look at again is not. Documented, tested playbooks also reduce the risk of being found negligent when an incident is later reviewed. For teams building or auditing their playbooks, the incident response plan templates and cost breakdown is a useful reference.

Communications

Out-of-band communication is the most underprepared element in most incident response programs, and the most consequential when it fails. The assumption that kills response speed is simple: your team assumes it will use Slack, Teams, or email during an incident. Those platforms depend on the same identity provider your attacker may now control.

The SSO risk is real and underappreciated. One stolen credential against a single sign-on provider gives an attacker access to every system that trusts it. That includes your communications tools. The Suncor breach made this point clearly. The response team was coordinating a ransomware reaction while the attackers were listening on the call. That is not a technology failure. It is a communications architecture failure.

Simulation exercises should explicitly test whether your team can communicate when primary channels are unavailable. Who calls whom, in what order, through what backup channel? What is the notification chain to the board? How does the public communications team get coordinated? At what point does your legal counsel get pulled into the conversation? These chains need to be tested under exercise conditions before they get tested under real ones. The Virtual Bunker datasheet outlines what out-of-band architecture looks like at the platform level for teams evaluating their infrastructure.

How to Design a Simulation That Tests All Three Dimensions

Define What You Are Actually Testing

Write objectives before writing scenarios. Technology objectives are obvious: detection fidelity, containment capability, recovery tooling. But people objectives, process objectives, and communication objectives require equal definition. Who makes the decision to declare? What is the test for playbook fidelity? Is the team able to reach all required participants through backup channels? Each objective generates specific observable behaviors during the exercise. If you cannot observe whether the objective was met, it is not a useful objective.

Build Scenarios With Realistic Friction

Standard scenarios flow in one direction: incident happens, team detects, team responds, incident resolves. Real incidents do not flow that way. Build scenarios with complicating variables from the start: primary communications are down, key personnel are unavailable, the initial information is incomplete or contradictory. Introduce injects mid-exercise: a second threat vector surfaces, a vendor is involved, a journalist calls for comment. These injects surface how your team improvises and judges under pressure.

Rotate scenario types deliberately. Ransomware is process-heavy and will test your playbook fidelity. Data exfiltration, on the other hand, pulls in legal coordination and communications under time pressure. Insider threats stress people dynamics in ways that external attack scenarios simply do not, and a third-party vendor compromise forces you to coordinate across organizational boundaries where your authority ends. Each type reveals different gaps.

Include the Right Participants

IR exercises are not just for the SOC. The cross-functional gaps that cause incidents to stall are never found in a single-team exercise because the missing party is not in the room. Required seats include legal, HR, executive leadership, communications and PR, and finance for ransomware scenarios where payment decisions may arise. External counsel, the cyber insurance carrier, and key vendors add valuable friction when available.

Cross-functional participation is also where the crisis response management disciplines become visible, or invisible. A team that has never coordinated across these functions under pressure will show it quickly in a well-designed exercise, which is exactly the point.

Use an Out-of-Band Exercise Environment

Running a simulation inside your primary environment creates a structural problem: the exercise cannot validate whether your team can operate without that environment. If your exercise infrastructure relies on the same platforms that would be affected in a real incident, you are not testing availability under pressure. You are assuming it.

A virtual bunker model addresses this directly. The exercise runs in a dedicated, separate environment. The act of conducting the exercise itself validates whether participants can find, access, and operate the out-of-band platform. Document findings in real-time within that environment, and the exercise automatically produces audit-ready output rather than a set of notes someone has to organize after the fact.

Debrief With Structure

A hot wash immediately after the exercise captures what is still fresh. A formal after-action report within 48 hours captures what the hot wash missed. The debrief format should be consistent: what happened, what was expected, what the gap is, who owns remediation, and when. Findings tracked as work items with named owners and timelines get addressed. Observations in a report nobody rereads do not.

The business continuity planning connection matters here too. Exercise findings should feed directly back into your BCP program as evidence of a continuous improvement cycle, not as one-off corrections. Documented outcomes also support audit readiness across SOC 2, NIST, ISO 27001, and DORA requirements.

The Cost Problem With Traditional Tabletop Exercises

At $30,000–$50,000 per engagement, external tabletop facilitation is priced for an annual cadence at best. Many organizations run one exercise every 18 months or longer. That frequency is not sufficient to maintain a calibrated understanding of your team's actual readiness. Your team composition changes quarterly, your technology stack shifts with every deployment, and the threat environment moves even faster. One exercise per year is a snapshot of where you were, not where you are.

The right cadence is quarterly exercises, each targeting a different dimension, with an annual full-scope simulation that includes cross-functional participation and a full after-action. That program, built around external facilitation, would cost $150,000–$200,000 per year before any internal time is accounted for.

A platform-based approach changes the cost structure without reducing the quality of the program. Structured exercise platforms eliminate the per-engagement cost, support distributed participation, provide scenario libraries, and produce audit-ready documentation as a byproduct. The exercises become a repeatable operational capability rather than a periodic procurement event. Organizations that have made this shift, including a US-based bank that reinforced its incident response program and H.I.G. Capital strengthening its incident governance, demonstrates what program maturity looks like at that cadence.

What Good Looks Like: Program Benchmarks

A mature simulation program runs four or more exercises per year, with different scenarios covering different risk dimensions. At least one of those exercises should be cross-functional, pulling in legal, HR, executive leadership, and communications alongside the IR team. The annual cycle should cover people, process, and communication dimensions, not just technology. Every exercise produces a written after-action with tracked remediation items and named owners, because findings without accountability do not get fixed.

Out-of-band validation belongs in the program explicitly. At least one exercise per year should take primary communications out of scope, forcing the team to operate through the backup channel and proving the virtual bunker actually works when it needs to. That exercise also validates that every participant knows where to go and how to operate there before it matters.

Activation speed is the operational benchmark. IR team activation in less than one hour from declared incident to full team operational is achievable for organizations that have pre-tested their notification and coordination processes. The readiness assessment offers a structured way to measure where your program stands against these benchmarks today.

Choosing the Right Approach for Your Program

If your program is mature, your playbooks documented and tested, and your scenario library deep enough to avoid repeating exercises, internal-only facilitation can carry the load. That said, it still requires exercise infrastructure that supports structured injects, participation tracking, and post-exercise reporting.

Bringing in an external facilitator makes the most sense when your program is new, when internal teams are too close to the gaps to see them clearly, or when a board-level or regulatory review benefits from third-party validation.

For teams that need to run exercises more than once per year without a five-figure spend per engagement, a platform-based approach changes the equation. It supports distributed participation, builds out-of-band communication into the exercise design rather than treating it as an assumption, and produces audit-ready documentation as a byproduct.

The combination that produces the most capable programs: a platform for frequency and internal capability, with an external facilitator engaged for the annual full-scope review. Out-of-band environment as a standard exercise requirement, not a special configuration. The Canadian utility that moved from ad hoc to incident ready illustrates what that transition looks like in practice.

Before an Incident Shows You the Gaps

Most organizations have tested their technology but not the team that has to operate it under pressure. The gaps that surface in real incidents (who calls whom, what channel to use when email is down, who has the authority to take a system offline) are gaps a well-designed simulation would have found first.

Running exercises that cover people, processes, and communications is a discipline choice. The infrastructure for it exists. The cost barrier to doing it frequently has dropped. What remains is the decision to treat simulation as an operational program rather than an annual compliance checkmark.

ShadowHQ is built for security teams that want to respond from a position of strength. The platform provides out-of-band infrastructure, automated playbooks, and a tabletop exercise environment designed to run that program without a consultant invoice attached to every exercise. If you want to know where your program actually stands before a real incident answers the question for you, the Readiness Assessment is the right starting point, or book a demo to see the tabletop exercise platform in action.