How to Run a Crisis Simulation: Coordinating Tabletop and Cyber Range Activity

Reviewed 10 September 2026.

Your technical team is investigating suspicious activity while the people responsible for operations need to decide what can be interrupted. One group has incomplete technical evidence; the other needs to understand the consequence of waiting or acting. A useful crisis simulation gives them a reason and a way to work together.

A tabletop exercise lets participants discuss a developing situation and make decisions. A technical exercise adds hands-on work in an environment where participants can investigate and defend systems. You can use either format, or combine them when the objectives require both.

This guide recommends a planning and facilitation approach for exercise owners and cyber range providers. It draws on the expert interview's emphasis on connecting the story, technical environment, participant guidance and evaluation. The examples are hypothetical, and the proposed planning aids are recommendations rather than records of established ObsidianCorps procedures.

Agree the purpose before selecting the format

Begin with the question the exercise should help answer. Do participants understand their roles? Can they assess uncertain information and decide who should act? Do they need to demonstrate technical investigation or containment? Different objectives require different opportunities to practise and different evidence.

For a discussion objective, a tabletop may be sufficient. For a practical objective, the team needs relevant systems and observations. A combined exercise is useful when decisions and technical actions depend on each other, but it also creates coordination work that must be planned.

The ENISA Cybersecurity Exercise Methodology provides an official lifecycle reference for planning, running and evaluating exercises. Use such guidance to structure your questions while keeping the customer's actual objectives and constraints central.

Write down what the exercise will not attempt to establish. A discussion of restoring a service does not demonstrate that a technical restoration worked. A successful technical task does not establish that an organisation's whole crisis response is effective.

Investigate the operational context

Ask how the relevant service or operation works, which dependencies matter and who holds authority for disruptive decisions. ObsidianCorps begins with a deep investigation of the customer's industry and operational context because these details shape both the story and the participant tasks.

Bring together the people who can explain those relationships. A technical lead may know what can be isolated. An operational owner may know which activity would stop. A crisis lead may know how a decision is escalated and communicated.

For government and defence exercises, dependencies may cross organisational boundaries. For an enterprise, a supplier or internal service owner may hold an essential piece of information. Identify the relevant relationships from the customer's context rather than assuming every exercise needs the same participant list.

If you need a structured way to develop the story, see our guide to industry-specific cyber exercise scenarios. Keep operational discovery separate from simply choosing a familiar attack theme.

Define participant and exercise-team responsibilities

Participants need to know the role they are playing, what authority they have and where to request clarification. The exercise team needs responsibility for facilitation, technical operation and observation. One person may hold several responsibilities, but the work still needs to be accounted for.

Recommend identifying who can introduce new information, change the exercise pace, clarify a rule or pause activity. Also identify who records observations. A facilitator actively guiding discussion may not be able to capture every important decision without support.

Represent external roles deliberately. If an organisation is simulated by the exercise team, make its permitted responses and knowledge consistent with the scenario. Avoid having it know information that nobody could reasonably have obtained within the story.

Keep the briefing proportionate. Explain the exercise boundaries and how to ask for help. Provide prerequisite information that participants need to perform their roles. Do not withhold basic operating instructions merely to increase difficulty.

Build one plan for events, evidence and decisions

An inject is information or an event introduced into the exercise. It may be a message, a report, a question from a represented stakeholder or a development that participants encounter through the technical environment.

For each significant inject, connect its story purpose to the information participants receive and the decision or action it enables. In a combined exercise, also identify the technical dependency. A discussion should not assume that a technical finding exists before the team can obtain it.

The following table is a recommended planning aid. It is not a product feature or a historical exercise timeline.

The plan should allow legitimate alternative responses. Participants may choose a defensible action that differs from the writer's expected path. Decide how the exercise team will interpret such choices without forcing the group back onto a script simply to preserve the planned ending.

Keep the tabletop and technical activity connected

Technical investigations and discussions progress at different speeds. A participant may need time to inspect evidence while another role is ready for a decision. The facilitator's job includes keeping that difference meaningful rather than letting the two groups drift into unrelated exercises.

Recommend asking for a provisional assessment when the objective concerns decisions under uncertainty. The technical team can explain what it knows, what it does not know and what it needs next. The decision-maker can then reason about the available information rather than wait for a perfectly complete report.

If a technical problem is caused by the exercise environment, treat it differently from an intended scenario challenge. Record the fault and decide whether to repair, pause or represent the missing behaviour. The evaluation needs to know which choice was made.

Agree how simulated time relates to the session. A story may represent developments over a longer period, but observers should not report those compressed intervals as measured real-world response times.

Use participant guidance deliberately

Guidance can clarify the developing situation, explain exercise mechanics or help a participant continue learning. Its level should match the objective and the group's maturity.

Distinguish clarifying a rule from revealing an answer. Both may be appropriate, but they support different conclusions about independent performance. Record significant assistance if the exercise also includes assessment.

Scenarium guides participants through dynamic tabletop exercises and can operate alongside a cyber range to guide participants throughout an exercise. In a combined format, the range provides the technical environment while Scenarium provides participant guidance as the situation develops.

The informal interview phrase “tabletop++” describes that complementary idea. It is not a formal exercise standard or a separate product tier. This description does not claim integrations, automatic scoring, reporting or other unconfirmed capabilities. Planning the shared story and facilitation remains part of the exercise work.

Rehearse the main handoffs

Before execution, recommend walking through the important information exchanges using the material and environment participants will encounter. Check whether an inject refers to the right system, whether the relevant role can access the evidence and whether the proposed action has an observable consequence.

Rehearse likely points of divergence, such as a request for information that is not in the prepared material. Give the exercise team enough shared context to answer consistently without inventing a new operational reality during the session.

Also check practical access and instructions. An exercise should challenge the intended capability, not accidentally test whether participants can guess an unfamiliar tool's setup process. The appropriate preparation depends on what the objective expects them to know already.

Debrief decisions and practical actions

After the exercise, ask participants to explain an important action using the information available at the time. What did they know, what was uncertain and why did they act? Compare that explanation with technical observations and the facilitator's record.

Preserve effective behaviour as well as limitations. A useful learning point may concern an accurate briefing, a well-judged request for assistance or a service check that prevented an unsupported conclusion. Not every finding is a failure.

Turn the important findings into a next step with an owner. Some require practice; others require a procedure change, a clearer responsibility or a correction to the exercise itself. Our article on evaluating cyber exercises beyond scores proposes ways to connect these observations to assessment criteria.

ObsidianCorps provides cyber exercise design, participant guidance and delivery support for commissioning organisations and range providers. If the tabletop discussion and technical activity need to work as one coherent scenario, Contact us.