Tabletop Exercise Scenario Pack: 8 Cyber Scenarios

Most organisations know they should run cyber tabletop exercises, but the work of writing a credible scenario, timed injects and an evaluation method means many never get past the first one. This pack gives you eight ready-to-run scenarios: ransomware with data extortion, identity provider admin compromise, a leaked cloud key, a SaaS supplier breach through stolen OAuth tokens, insider data theft, business email compromise payment fraud, AI agent misuse through prompt injection, and an operational technology (OT) disruption. Each has objectives, participants, a summary, timed injects, discussion questions, expected decisions and evaluation points, followed by a facilitator guide and an after-action report template. The scenarios are defensive and contain no attack procedures. The structure follows FEMA's HSEEP doctrine, CISA's Tabletop Exercise Packages and the NCSC's Exercise in a Box.

How to use this template

Replace text in square brackets, such as [Organisation], [Incident manager] and [crown-jewel system], with your own names, systems and suppliers.
Pick one scenario per session. Run technical scenarios with responders first, then an executive version a few weeks later using the technical findings.
The NCSC is clear that "You should not use exercising to create your response plans; these should be in place already." Circulate the plans under test as read-ahead a few days before.
Times are scenario time (T+0 is the first inject), not wall-clock time. Compress or stretch them to fit a [2 to 4 hour] session.

1. Purpose

This pack enables [Organisation] to test its incident response, crisis management and business continuity plans against realistic cyber scenarios, identify gaps in decision rights, communications, technical capability and supplier arrangements, and track corrective actions to closure. It supports the requirement in the [Incident Response Plan] to exercise the plan at least [annually] and the #StopRansomware Guide recommendation to "Create, maintain, and regularly exercise a basic cyber incident response plan (IRP)".

2. Scope

Discussion-based exercises only. HSEEP defines a tabletop as "A discussion-based exercise in response to a scenario, intended to generate a dialogue of various issues". No live systems are touched.
Plans in scope: [Incident Response Plan], [Crisis Communications Plan], [Ransomware Playbook], [Business Continuity and Disaster Recovery Plan], [Supplier Incident Procedure], [Payment Verification Procedure].

3. Roles and exercise rules

Role	Responsibility
[Exercise sponsor]	Senior owner who sets the objectives and accepts the improvement plan
Lead facilitator	HSEEP: "Facilitators/Presenters deliver scenario information and maintain a focused discussion." Neutral; does not play
Players	People named in the plans under test, with deputies
Scribe and evaluator	Record decisions, timings, assumptions and gaps against the evaluation points, in a non-attribution environment
Simulation cell	Plays the regulator, insurer, press, supplier, bank or attacker's negotiator by phone or message

Read these rules aloud at the start:

Every exercise message starts "EXERCISE-EXERCISE-EXERCISE" and the exercise name, as the NCSC recommends, so nothing is mistaken for a real event.
Do not "fight the scenario", even if it seems unlikely. Decide on the incomplete information you have.
Discussion is non-attributable: the report records what was decided, not who got it wrong.

4. Scenario index

No.	Scenario	Primary audience	Core plans tested	ATT&CK anchor
5.1	Ransomware with data extortion	Technical, then executive	IR plan, ransomware playbook, BCDR, communications	T1486 Data Encrypted for Impact
5.2	Identity provider admin compromise	Technical	IR plan, break-glass procedure	T1078.004 Cloud Accounts
5.3	Leaked cloud access key	Technical	Cloud IR runbook, secrets rotation	T1078.004 Cloud Accounts
5.4	SaaS supplier breach (OAuth token theft)	Technical and legal	Supplier incident procedure, notification	T1528 Steal Application Access Token; T1199 Trusted Relationship
5.5	Insider data theft	HR, legal, security	Insider threat procedure, evidence handling	Map case by case
5.6	BEC payment fraud	Finance, executive	Payment verification, fraud response	Map case by case
5.7	AI agent misuse through prompt injection	Technical, data protection	IR plan, AI use policy	Map case by case
5.8	OT disruption	Operations, engineering, executive	OT incident procedure, BCDR, safety	Map case by case

5. Scenario scripts

5.1 Ransomware with data extortion

Objectives: confirm who authorises isolating the network and shutting down revenue systems; validate restore priorities against the critical asset list; test the decision process on extortion and notification. Participants: [Incident manager], IT operations, SOC, [CFO], [General counsel], communications, [DPO].

Scenario summary: on a Saturday night file servers and the virtualisation cluster are encrypted. On Monday the group posts a sample of [Organisation]'s HR files on its leak site and demands payment to delete the rest. Production at [site] has stopped, as it did in the Jaguar Land Rover cyberattack.

Time	Inject	Discussion questions
T+0 (Sat 23:40)	On-call engineer reports servers unreachable and a ransom note on the hypervisor console.	Who is called first? Who can authorise disconnecting sites? Is email still trustworthy for coordination?
T+3h	Backup console shows the last [7 days] of snapshots deleted; offline copies are [age].	What is restored first, from where, and how do we know it is clean?
T+36h	Leak site post with HR records; journalist calls the press office.	Which notification clocks have started? Who approves the holding statement?
T+48h	Insurer asks whether law enforcement has been contacted; the board asks whether paying would be faster.	Who decides on payment and on what criteria? Is payment lawful for this group?

Expected decisions: isolate affected systems, as the #StopRansomware Guide advises ("Determine which systems were impacted, and immediately isolate them"); move to out-of-band communications; restore by the predefined critical asset list; engage insurer, counsel and law enforcement; record the payment decision. Evaluation points: time to declare an incident; whether anyone knew the restore order; whether privileged and backup credentials were assumed compromised and reset. See the Ransomware Response and Recovery Guide.

5.2 Identity provider admin compromise

Objectives: test how fast a privileged identity can be contained; confirm break-glass access works; test trust decisions when the identity provider (IdP) itself is suspect. Participants: identity team, SOC, service desk lead, [CISO], cloud platform team.

Scenario summary: the service desk resets the password and MFA for a [IdP] super administrator after a convincing phone call, a pattern seen in the MGM Resorts breach. The new session changes sign-in policy and adds an external identity provider.

Time	Inject	Discussion questions
T+0	Identity threat detection alerts on a new MFA method and an admin sign-in from an unfamiliar hosting provider.	Who triages, and who can disable a super administrator?
T+1h	The real administrator says they never called the service desk.	Which sessions, tokens and app consents does that account hold? How are they revoked tenant-wide?
T+2h	Audit log shows a new federated IdP and a Conditional Access exclusion.	Can we still trust sign-ins to the IdP? Who uses break-glass access?
T+4h	The break-glass account fails sign-in because a policy now blocks it.	What is the fallback? When was break-glass last tested?

Expected decisions: disable the account and revoke sessions; remove attacker-added federation and policy changes; invoke break-glass; tighten service desk verification for privileged resets. Evaluation points: time to containment; whether break-glass had been validated recently (Microsoft recommends at least every 90 days, with alerts on every use); completeness of the change review. See the Identity Provider and SSO Security Guide and the Break-Glass Account Guide.

5.3 Leaked cloud access key

Objectives: test revocation of a machine credential without breaking production; test scoping from cloud audit logs. Participants: cloud platform team, DevOps, SOC, application owner, [DPO].

Scenario summary: a long-lived [AWS / Azure / Google Cloud] access key for a deployment pipeline is found in a public repository. Logs show storage listing and new compute in an unused region. Stolen keys have been used to encrypt storage for extortion, as in the Codefinger S3 ransomware campaign.

Time	Inject	Discussion questions
T+0	Secret scanning alert from the code host; provider abuse notice arrives.	Who owns this key? Can we rotate it now without stopping deployments?
T+1h	Audit logs show object reads from [bucket] holding customer exports.	Is this a personal data breach? Which notification clock starts?
T+3h	A new IAM user and access key created by the leaked key are found.	What else was created? Have all regions been checked?

Expected decisions: replace and deactivate the key; remove credentials, roles and resources the attacker created, checking "all resources in all AWS Regions" as AWS advises; assess data exposure. Evaluation points: time from alert to revocation; whether an owner was known; whether short-lived workload credentials are on the remediation list. See the Secrets Management Guide.

5.4 SaaS supplier breach through OAuth token theft

Objectives: test discovery and revocation of third-party OAuth grants; test contract and notification duties. Participants: SaaS administrators, third-party risk, legal, SOC, [CRM owner].

Scenario summary: a [sales engagement] supplier announces that OAuth tokens it held for customers' [CRM] tenants were stolen and used to export data, the pattern in the Salesloft Drift breach.

Time	Inject	Discussion questions
T+0	Supplier security bulletin with indicators; no direct contact yet.	Do we use this integration? Who owns it, and what scopes does it hold?
T+2h	[CRM] logs show bulk queries from the integration's identity last week.	Revoke now, or wait for the supplier? What business process breaks?
T+6h	Exported records contained API keys pasted into support cases.	Which secrets must be rotated, and who owns each?

Expected decisions: revoke the integration's tokens and disable the connected app; rotate secrets found in exported data; invoke contract notification clauses; assess customer notification. Evaluation points: whether an inventory of OAuth grants existed; time to revoke; whether data in free-text fields was considered. See the SaaS and OAuth App Governance Guide.

5.5 Insider data theft

Objectives: test HR, legal and security coordination; test evidence handling and revocation of every credential the person created. Participants: HR, legal, security investigations, line manager, [IT].

Scenario summary: a support team member who has resigned is found exporting customer records. A tip suggests outside payment, as in the Coinbase insider breach.

Time	Inject	Discussion questions
T+0	DLP alert: [n] records uploaded to a personal cloud drive.	Who decides whether to suspend access, and is HR informed first?
T+1d	The employee also created a personal access token and a mail forwarding rule.	How do we find every credential they created?
T+3d	Customers report targeted scam calls citing their account details.	Notification, law enforcement and customer support decisions?

Expected decisions: preserve evidence before confronting the person; revoke accounts, tokens and forwarding rules together; notify as legal advises. Evaluation points: whether legal privilege and employment law were considered; completeness of credential revocation. See the Insider Threat Programme Guide.

5.6 Business email compromise payment fraud

Objectives: test payment verification controls and the recall process. Participants: [CFO], accounts payable, treasury, security, legal.

Scenario summary: accounts payable receives new bank details from a known supplier's real mailbox, followed by a short video call with someone appearing to be the CFO approving an urgent payment. Deepfake video was used to trigger transfers in the Arup fraud.

Time	Inject	Discussion questions
T+0	Bank detail change request and [amount] invoice.	What does the procedure require before a bank detail change?
T+2d	The real supplier chases an unpaid invoice.	Who calls the bank, how fast, and with what information?
T+2d+2h	Mailbox audit shows a forwarding rule on the supplier's side and a login to our AP mailbox.	Is this a fraud or an account compromise, or both?

Expected decisions: the FBI advises victims to "contact your financial institution immediately" and report to IC3; verify changes "with the person making the request" by a known number; investigate the mailbox. Evaluation points: whether call-back verification was mandatory; time to contact the bank. See the Email Identity and BEC Guide.

5.7 AI agent misuse through prompt injection

Objectives: confirm who can switch off an AI agent; test scoping of the agent's credentials and actions. Participants: AI platform owner, security, application owner, [DPO], legal.

Scenario summary: a customer service agent with tool access reads a support ticket containing hidden instructions (indirect prompt injection in OWASP's terms) and sends customer records to an external address, then deletes the ticket. Agents with over-privileged tokens have already destroyed data, as in the PocketOS database deletion.

Time	Inject	Discussion questions
T+0	Customer complains they received another customer's data from the agent.	Who can disable the agent now? Is there a kill switch?
T+2h	Agent logs show tool calls but not the prompts that caused them.	Can we reconstruct what happened? What credentials does the agent hold?
T+1d	The vendor says the model behaved "as designed".	Who is accountable, and what do we tell the regulator?

Expected decisions: disable the agent and revoke its tokens; reduce its privileges to the minimum and require human approval for sensitive actions, as OWASP LLM01:2025 recommends. Evaluation points: whether the agent had a named owner and a credential inventory; quality of agent logging. See the AI Agent Observability and Incident Response Guide.

5.8 OT disruption

Objectives: test the decision to shut down operations as a precaution; test IT and OT coordination and safety escalation. Participants: plant or operations manager, OT engineering, IT security, health and safety, [executive].

Scenario summary: ransomware on the IT network reaches billing and scheduling systems at [site]. The OT network is not yet affected, but the business cannot invoice or track output. Colonial Pipeline halted its pipeline after an intrusion that began with an unused VPN account; see the Colonial Pipeline attack.

Time	Inject	Discussion questions
T+0	IT incident declared; OT remote access runs through a shared jump host.	Do we disconnect IT from OT? Who decides, and can operations run manually?
T+4h	An engineering workstation shows the same suspicious file.	What is the safe state? Who talks to the equipment vendor?
T+1d	Customers and regulators ask when supply resumes.	What restart criteria must be met?

Expected decisions: segregate IT and OT; disable shared remote access; prioritise safety; agree restart criteria. Evaluation points: whether manual operating procedures exist and were known. See the OT Security Guide.

6. Facilitator guide

Four weeks before: agree objectives with the sponsor, tailor the scenario, brief the simulation cell, confirm players and deputies.
One week before: walk through the injects with a trusted colleague. Write the expected action for each one; the NCSC advises being "clear what each inject is designed to do, and the expected actions it will prompt".
A few days before: send players the plans under test and the exercise rules.
On the day (3 hours): 15 minutes of introduction and rules; three modules of about 40 minutes; 30 minutes of hot wash.
During play: keep to objectives, bring quiet participants in by role, and use a contingency inject if the group solves a problem too fast.
Hot wash: HSEEP describes it as "a meeting that provides an opportunity to discuss exercise strengths and areas for improvement".

7. Evaluation

For each evaluation point, the evaluator records a rating, the evidence and any plan gap:

Rating	Meaning
Met	The group reached the expected decision using the plan, in a realistic time
Partly met	The right decision, but slowly, by improvisation or with unclear authority
Not met	The decision was not reached, or the plan, contact or capability was missing

8. After-action report template

Section	Content
Exercise overview	Name, date, scenario, sponsor, facilitator, participants by role, plans tested
Objectives and ratings	Each objective with its rating and evidence from section 7
Strengths	What worked and should be kept
Areas for improvement	Observation, impact, root cause (plan, people, process or technology)
Participant feedback	Summary of feedback forms on realism, timing and logistics
Improvement plan	Corrective actions tracked in the table below

Ref	Finding	Corrective action (SMART)	Owner	Due date	Status	Retest in exercise
[TTX-2026-01-01]	[Break-glass account blocked by Conditional Access]	[Exclude break-glass group from blocking policies and test sign-in quarterly]	[Identity lead]	[Date]	[Open]	[Next identity scenario]

HSEEP expects corrective actions to be specific, measurable, achievable, relevant and time-bound, and the NCSC says to "Ensure any recommendations are implemented ahead of delivering subsequent cyber exercises."

9. Source references

Implementation guidance

Choose by risk: start with the two scenarios that match your top risks in the risk register, usually ransomware and identity compromise.
Plan a year: four tabletops a year (two technical, one executive, one supplier or fraud) cover the pack in two years.
Pair with drills: a tabletop cannot prove a restore time or a break-glass sign-in. Follow each finding of that kind with a drill.
Close the loop: report corrective actions to [governance forum] monthly and retest them in the next relevant scenario.

Small organisations can start with the NCSC's free Exercise in a Box and one scenario from this pack, run by an internal facilitator. Large or regulated organisations should use an independent facilitator for executive sessions. Useful measures: exercises run against plan, percentage of corrective actions closed by due date, time to key decisions compared between exercises, and repeat findings. See the Incident Response Guide and the Business Continuity and Disaster Recovery Guide.

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Incident Response Guide · Ransomware Response and Recovery Guide · Business Continuity and Disaster Recovery Guide · Digital Forensics (DFIR) Guide

Tabletop Exercise Scenario Pack