Tabletop scenarios: 8 examples with injects and guiding questions
How is a tabletop scenario structured?
Every scenario consists of three building blocks: a starting situation (the situation at the beginning), a series of injects (situation-related events that escalate the incident step by step) and guiding questions that steer the discussion to where decisions have to be made. The planned sequence of injects is recorded in a master scenario events list (MSEL). Good scenarios are realistic, concern risks the organisation actually has and force the team to decide. Merely presenting information is not enough.
Further English-language tabletop exercise scenarios can be found, for example, in the CISA Tabletop Exercise Packages or in “Exercise in a Box” from the UK NCSC. They serve as a starting point but have to be adapted to your organisation and your reporting paths.
8 tabletop scenarios with injects and guiding questions
The following scenarios cover typical threats to mid-sized organisations. The difficulty ranges from beginner to advanced.
Ransomware in the production network · Advanced
ERP and manufacturing systems are encrypted, a ransom demand has arrived, the extent of the damage is unclear. The scenario tests decisions under uncertainty and the reporting chain.
Example injects:
- The SOC reports large-scale encryption. Production has stopped.
- The attackers threaten to publish exfiltrated data in 24 hours.
- A journalist asks about a rumour of the attack.
Guiding questions:
- Isolate systems or keep operating: who decides?
- Who triggers the NIS2 report (24/72 h), who informs customers?
- By which criteria do you decide whether to pay?
Supply chain attack: compromised software supplier · Advanced
A tampered update from a service provider introduces malicious code. The scenario tests dependencies, supplier communication and containment.
Example injects:
- The vendor confirms a compromised update delivery.
- First signs of lateral movement in your own network.
- Two more sites report suspicious activity.
Guiding questions:
- How do you contain the damage without stopping operations completely?
- Which contractual and legal steps do you take towards the supplier?
- How do you coordinate with affected third parties and authorities?
Data leak: exfiltration and GDPR notification · Intermediate
Customer data has been exfiltrated. The focus is on reporting obligations, informing the data subjects and crisis communication under time pressure.
Example injects:
- A security researcher reports a public data set containing your customer data.
- The 72-hour deadline of the GDPR (Art. 33) is running.
- The works council and first customers are asking questions.
Guiding questions:
- Is notification to the supervisory authority required, and who writes it?
- When and how do you inform the data subjects (Art. 34)?
- Who speaks externally, with which core message?
Insider threat · Intermediate
An employee with elevated privileges is suspected of stealing data. The scenario tests the interplay of IT, HR, legal and management.
Example injects:
- Unusual data access by an administrator outside working hours.
- The suspect announces that they will leave the company at short notice.
- A competitor appears with strikingly similar offers.
Guiding questions:
- How do you secure evidence without making mistakes under employment and data protection law?
- Who is involved when: IT, HR, legal, management?
- How do you prevent further exfiltration without acting rashly?
Cloud/SaaS outage at the central provider · Intermediate
The cloud or SaaS provider through which you run email, collaboration or ERP suffers a large-scale outage. You have no influence on fixing it. The scenario tests dependencies, emergency operation and communication without the usual tools.
Example injects:
- The provider reports a disruption in your region, with no forecast for recovery.
- Email, chat and file storage are gone. The alerting list and the emergency manual are stored there too.
- After four hours the provider no longer rules out data loss.
Guiding questions:
- How does the crisis team reach each other without email and chat?
- Which processes exceed their maximum tolerable period of disruption first?
- What does the contract govern (SLA, data export, exit), and who escalates with the provider?
Outage of a critical IT service provider · Beginner
Your managed service provider, which runs your network and servers, is unavailable for hours. The scenario trains business continuity and emergency operation.
Example injects:
- The service provider reports a large-scale disruption without a recovery time.
- Core processes (ordering, shipping) have stopped.
- Customer complaints are piling up on social media.
Guiding questions:
- Which processes continue in emergency operation (according to RTO/RPO)?
- When do you escalate, when do you communicate proactively?
- Which alternatives and workarounds kick in?
Phishing with account takeover (compromised mailbox) · Beginner
Through a phishing link an attacker has taken over a mailbox in sales and is sending further emails from it. What is rehearsed is how you contain the compromised identity, assess the data access and warn business partners.
Example injects:
- Staff report an internal email with a link to a supposedly shared document. The sender is a real sales mailbox.
- IT finds a forwarding rule to an external address and logins from abroad. MFA was not active.
- A customer asks whether the email with the link came from you.
Guiding questions:
- Who locks the account, sessions and rules, even at night?
- Which data has the attacker read, and is a GDPR notification needed?
- Whom do you warn externally, and through which channel?
CEO fraud / business email compromise · Beginner
A forged payment instruction in the name of management lands in accounting. The scenario tests controls, escalation and the cooperation of finance and management.
Example injects:
- Accounting receives an urgent payment instruction supposedly from the CEO.
- The supposed sender address differs minimally.
- Pressure by phone follows to release the payment immediately.
Guiding questions:
- Do your four-eyes and approval controls hold?
- How do staff check authenticity under pressure?
- What happens after a payment has already been released?
Which scenarios should the ISMS manager prioritise?
The scenarios that reflect your biggest risks. Derive them from the risk register and the business impact analysis, not from headlines. Exercise first where an incident hits the most time-critical processes and where plans have never been tested in practice. Four sources help:
- Risk register: high risks whose treatment relies on reporting paths, crisis team or continuity plans.
- Business impact analysis: processes with a short maximum tolerable period of disruption and their dependencies, such as a cloud service or IT service provider.
- Incidents and near misses in your own organisation and in the industry.
- Open findings from audits and exercises whose remediation a follow-up exercise checks.
Spread the prioritised scenarios over an annual exercise plan; ISO 22301 expects such a planned programme. The order depends on maturity and learning objective. Teams without exercise experience start with bounded scenarios such as CEO fraud or phishing. Where your biggest gaps lie is shown by the readiness check.
Facilitation guide: how to run the exercise
A facilitation guide (facilitator guide) sets out what the facilitator does in which phase. NIST SP 800-84 names as contents the purpose, scope and objectives, the scenario, questions on the exercise objectives and the plan being exercised. The following agenda is designed for 90 minutes, with a condensed variant for 60 minutes:
| Phase | 90 min. | 60 min. | Content |
|---|---|---|---|
| Briefing | 0–10 | 0–5 | Objectives, rules, roles. Plans are tested, not people. |
| Starting situation | 10–20 | 5–10 | Read out the scenario, first situation assessment, clarify who leads. |
| Phase 1: detection and assessment | 20–40 | 10–25 | Classify the incident, alert, escalate. |
| Phase 2: escalation and containment | 40–65 | 25–40 | Decide on containment, check reporting obligations, external enquiries. |
| Phase 3: communication and recovery | 65–75 | 40–50 | Inform stakeholders, prioritise recovery. |
| Hot wash | 75–90 | 50–60 | What went well, what was missing? First actions with owners. |
Keep to the time, do not solve anything for the team and bring the group back when it takes the scenario apart: “Take the situation as given. What do you do now?”
Facilitation questions for every phase
The guiding questions of the scenarios are case-specific. These facilitation questions fit every scenario:
- Detection and assessment: how would we notice this for real? Is this a security incident, and who decides that? Whom do we alert?
- Escalation and containment: which decision has to be taken now, and who is authorised? What do we accept? Which deadlines are running (24 hours for the NIS2 early warning, 72 hours under the GDPR)?
- Communication: what do we tell staff, customers and the press, and who approves it?
- Recovery: in which order do we bring processes back up? How do we know the attacker is out?
- Hot wash: what worked? Where were information or authority missing? What in the plan is out of date?
Observation sheet: what observers look for
Observers do not intervene. They note what happens, with the time. You set the criteria in advance from the exercise objectives. NIST SP 800-84 recommends that too.
| Criterion | Guiding question for observers | Example observation |
|---|---|---|
| Situation awareness and classification | Detected in time and classified by criteria? | “Classified as a security incident only 25 minutes after inject 1, criteria unknown.” |
| Alerting and escalation | Right people reached through the intended channels? | “Deputy of the head of IT missing from the alerting list.” |
| Decisions | Who decided what, with which authority? | “Isolation postponed because it was unclear who approves a production stop.” |
| Reporting obligations | Deadlines recognised, reporting responsibility clarified? | “24-hour deadline recognised, but nobody named as responsible for reporting.” |
| Use of the plans | Was the plan used, and did it hold? | “Emergency manual was only stored in the failed cloud storage.” |
The observations are the raw data for the after-action review: there every observation becomes a finding with an action, a responsible person and a deadline.
Writing injects
An inject is a piece of situation information fed in at a set time, for example as a phone call, ticket, email or press enquiry. Good injects force the team to make a decision. The following helps when writing them:
- Every inject targets an exercise objective and arrives the way it would in a real incident.
- The pressure rises: new parties affected, tighter deadlines, contradictory reports.
- Keep it short: according to NIST SP 800-84, concise scenarios are often more effective than very detailed ones.
- Keep reserve injects ready in case the team is faster or slower.
Timing, sender, content and expected response of every inject are recorded in the MSEL.
From scenario to exercise
A scenario on paper is only half the way. It shows its value in the facilitated delivery. Definition, process and exercise formats are explained on the page Cyber tabletop exercise. With SecDrills you pick a scenario and invite your team by link. Participants do not need an account, and nothing is installed. At the end there is an auditable after-action report with roles, decisions and timestamps that you can present as evidence for NIS2, ISO 27001 and TISAX.
Frequently asked questions
What is a tabletop scenario?
A tabletop scenario is the script basis of a tabletop exercise: a realistic starting situation and a sequence of events (so-called injects) that develop the incident. Based on the injects the team makes decisions and rehearses communication and escalation.
How many injects does a good scenario need?
For a 60 to 90 minute exercise, 4 to 8 injects are usually enough. More important than the number is the arc of tension: the events should raise the pressure and keep forcing new decisions, rather than just stringing information together.
Which scenario is suitable for getting started?
For the first exercise, clearly bounded scenarios such as CEO fraud, phishing with account takeover or the outage of an IT service provider are suitable. Complex scenarios such as ransomware or supply chain attacks show their value once the crisis team already has exercise routine.
Who should facilitate a tabletop exercise?
A person who knows the scenario but does not play a role themselves. Often the ISMS or BCM leads take this on. The facilitator steers time and questions but does not assess. Add at least one observer.