An exercise brief says the scenario must be relevant to the energy sector, a government function or a financial organisation. The first draft changes the organisation's name and adds a familiar attack. It still leaves the exercise team guessing which operational decisions participants should make.
Industry relevance needs more than vocabulary. The scenario must explain what the organisation does, which dependencies matter and why a technical event creates a decision for a particular role. Otherwise, a plausible attack can lead to an implausible exercise.
ObsidianCorps' approach begins with a deep investigation of the customer's industry and operational context. The recommendations below show how to translate that principle into scenario-design work. The examples are illustrative; they are not accounts of named clients or past outcomes.
Investigate the operation before selecting the attack
Start with the service or activity the exercise concerns. Ask an operational owner to explain what happens during normal work, what would be disrupted by loss of a supporting system and what alternatives are actually available.
Security staff provide essential technical context, but they may not own all the decisions in the scenario. A service owner may understand an operational workaround. A manager may hold the authority to accept disruption. Another organisation may control information that participants need before they can act.
The purpose of discovery is to identify these relationships. It is not to collect every available document or reproduce an entire sector in the range. Concentrate on the details that determine the participant tasks.
Useful inputs may include an agreed description of the operation, relevant system dependencies, role responsibilities and current response procedures. Treat incomplete or disputed information as a design assumption to resolve, rather than quietly filling the gap with a convenient invention.
Use questions that change the design
The following interview worksheet is a recommendation. It is not a claim that ObsidianCorps uses a fixed proprietary questionnaire in every engagement.
| Discovery question |
Design decision it informs |
| What service or activity must continue? |
The operational objective and consequences of disruption |
| Which systems and external parties support it? |
The relevant architecture and represented roles |
| Who can authorise a disruptive action? |
The participant roles and escalation path |
| What information would normally support that decision? |
Evidence and briefing material |
| What is uncertain during an incident? |
Useful ambiguity within the scenario |
| What can this participant group already do? |
Challenge, preparation and guidance |
| What result would make the exercise worthwhile? |
Evaluation criteria and scope boundaries |
Ask for examples of the reasoning behind an answer. “Operations approves containment” is less useful than knowing which operational consequence must be considered and what information the approver expects. Those details help a facilitator recognise meaningful decision-making later.
For defence and government customers, the relevant operation may be a mission or a service involving several organisations. For enterprise buyers, it may be a business process with internal and supplier dependencies. These are starting questions, not assumptions about how any particular organisation works.
Define an objective participants can demonstrate
An objective such as “raise awareness” leaves room for many formats. An objective such as “assess whether the team can decide how to contain suspicious access while maintaining an agreed service” points towards specific participant actions and evidence.
Write the objective before choosing the attack sequence. Then ask whether the proposed scenario gives the participants a fair opportunity to demonstrate it. If the important decision occurs outside their authority, either involve the relevant role, represent it through the exercise team or change the objective.
The ENISA Cybersecurity Exercise Methodology provides a current official reference for planning, running and evaluating exercises. Its lifecycle perspective is useful here: decisions about objectives and stakeholders have consequences throughout delivery. This article's worksheet is our recommendation, not a claim of ENISA certification or endorsement.
Connect the story to evidence and decisions
For every important event, identify what changes, who can observe it and which action or decision it invites. A story event that nobody can discover does not automatically become a fair test of detection. An operational decision based on information no participant receives may test guesswork rather than judgement.
Here is a hypothetical mapping for an exercise involving suspicious access to a shared service:
| Story development |
Participant information |
Decision or action |
Evidence for evaluation |
| Unusual access is reported |
Selected access records and a user report |
Investigate what is known and uncertain |
Reasoning tied to available evidence |
| Restricting access may interrupt an operation |
A description of the service dependency |
Escalate and choose a containment approach |
Authority, trade-offs and rationale |
| A control is changed |
Observable behaviour in the range |
Verify the effect and update other roles |
Service checks and an accurate briefing |
This is not an attack recipe or a historical exercise timeline. It shows how the story, technical environment and assessment can share an objective. The exact events and evidence need to be developed for the customer's context.
Preserve useful uncertainty without introducing contradictions
Participants should sometimes work with incomplete information. That can reveal how they state uncertainty, request help and make proportionate decisions. But missing information is useful only when the exercise remains coherent.
Distinguish information that is deliberately unavailable from evidence that the range team forgot to implement. A participant can explain a decision under uncertainty. They cannot reasonably infer a technical fact that the scenario requires but the environment contradicts.
Recommend a consistency review across the story, network description, service behaviour and participant briefings. Check the names, roles and dependencies that appear in more than one place. If two roles receive different information, establish why that difference exists and whether coordination can resolve it.
A change during scenario development also needs to reach the technical team. Moving an event earlier may change the logs required. Changing the operational consequence may alter the service that must remain available. Maintain a record of such dependencies rather than reviewing the narrative in isolation.
Check feasibility with the range team
Before finalising the story, confirm which services can be provided, what software is available and where custom development is needed. A scenario that relies on inaccessible software has an unresolved engineering requirement, not a minor production detail.
The article on realistic cyber range environments explains how to map participant tasks to implemented behaviour. Use that mapping to decide whether a function must run in the range or can be represented through exercise material.
Make the resulting limits explicit. A facilitated message can represent an external organisation's response. It cannot establish how that external organisation would actually perform. A simplified application may support a selected investigation task without reproducing the original product.
For a cyber range provider, this review also identifies where specialist support is needed: story development, architecture, a custom function, technical scenario work or execution. It helps separate work packages while keeping their shared dependencies visible.
Match the challenge to the participants
The expert philosophy behind this content values learning over winning. An industry-specific scenario should challenge participants enough to reveal limitations and create opportunities to improve. It should not make unfamiliar sector detail an unexplained obstacle.
Decide what participants should know before the exercise and what they are expected to discover. Provide preparation where knowledge is a prerequisite. Reserve uncertainty and difficulty for the capability being explored.
A useful review asks whether a participant could explain their next step using the briefing, observable evidence and their role. If the answer depends on a secret assumption held only by the scenario writer, revise the scenario or its guidance.
Review the scenario as one connected exercise
Bring the operational owner, scenario designer, range engineer, facilitator and evaluator through the main decision sequence. These are recommended responsibilities; one person may hold more than one role in a smaller exercise.
For each objective, confirm that participants can encounter the relevant event, obtain appropriate evidence, perform the intended action and receive an observable consequence. Record what the evaluator should capture and how assistance will be treated.
The next step is execution planning. Our guide to coordinating tabletop and technical exercise activity explains how to keep the different participant roles connected as the situation develops.
If you have an exercise objective but need a scenario grounded in your industry's operations, ObsidianCorps offers cyber exercise design and delivery expertise. Bring the operational context, the participant group and the decisions you want to explore. Contact us.
