Tabletop Exercise Scenarios: 7 Proven Cyber Drills for 2026

Tabletop exercise scenarios are the cheapest way to find out whether your incident response plan works before an attacker runs the test for you. Well-built tabletop exercise scenarios put the people who would make real decisions in a room, feeds them incomplete information in stages, and records where the plan helped, where it was silent and where nobody knew who was in charge.

This post is about cyber incidents. Search results for the term mix in fire drills, evacuations and general business continuity exercises, and those test different plans. The seven tabletop exercise scenarios below are original outlines for security incidents, each with sample injects and a note on what it tests, followed by how to run the session and how to evaluate it.

Why NIST cares about tabletop exercise scenarios

NIST SP 800-61 Rev. 3 rates Subcategory ID.IM-02 as High priority: improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties. Its notes say exercises can provide information for program evaluation and prepare staff and third parties, such as critical service providers and product suppliers, for future incidents. Our NIST incident response lifecycle post explains where that improvement loop sits in the Rev. 3 model.

For method, Rev. 3 points to NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, published in September 2006. It dates from 2006, and its approach to designing, running and evaluating discussion-based exercises still applies. Rev. 3 also asks you to synchronize business continuity plans with incident response plans (ID.IM-04.R1), which makes continuity owners natural participants in several of the tabletop exercise scenarios below.

How to build tabletop exercise scenarios that test something

The story is the least important part of tabletop exercise scenarios. Start with the decisions you want to watch being made, then write a story that forces them.

• Pick two or three objectives. For example: who declares the incident, who may authorize shutting down a critical service, and who talks to the regulator. Rev. 3 Section 2.2 notes that leadership may hold decision authority on high-impact actions such as shutting down or rebuilding critical services, so test whether that authority is clear.
• Use your own environment. Tabletop exercise scenarios built on real system names, real suppliers and the real on-call rota expose gaps that a generic company never will.
• Write injects that demand a decision. Each inject adds new information and ends with a question for a named role.
• Withhold information. Real incidents arrive half-understood. Ambiguity is part of the test.
• Bring in a third party. ID.IM-02 calls out exercises with suppliers, so some of your tabletop exercise scenarios should include an inject that depends on a provider, partner or customer.

Seven cyber tabletop exercise scenarios

The table summarizes the set. All seven tabletop exercise scenarios are hypothetical; adapt the details to your systems and suppliers.

#	Scenario	Main decision tested	Rev. 3 hooks
1	Ransomware before a long weekend	Shutdown authority, clean restore, the payment decision path	RS.MA-04, RC.RP-03, PR.DS-11
2	Identity provider takeover	Redeploying the primary authentication platform	Section 2.3, RS.MI
3	The stranger’s email	Validating an outside report, the legal hand-off	RS.MA-02.R2, RS.CO-02
4	Managed service provider compromise	Contractual authority to act	Section 2.2, GV.SC-08, ID.IM-02
5	The departing insider	HR, evidence and the policy-violation incident	RS.CO-03.R3, RS.AN-07
6	Denial of service on the customer portal	Pre-authorized provider containment, continuity	RS.MI-01.C2, ID.IM-04
7	The quiet beacon	Declare or not; observe or contain	DE.AE-08, RS.MA-03.R3, RS.MI

1. Ransomware before a long weekend

Late on the last working day before a holiday, the service desk takes calls about renamed files on shared drives, and endpoint protection alerts on several file servers.

• Inject 1: A ransom note appears, claiming data was copied out first and threatening publication.
• Inject 2: The backup administrator reports that the backup console was accessed earlier in the week from an unfamiliar workstation.
• Inject 3: A journalist emails the press office asking for comment.

What it tests: who may take file services offline; whether backups are checked for indicators of compromise before use (RC.RP-03.R1); and whether the payment question goes straight to executive leadership and legal counsel, who must assess sanctions and reporting exposure first, instead of being debated on the technical bridge. Our ransomware playbook post covers the response itself.

2. Identity provider takeover

The identity team spots a new global administrator account in the cloud identity provider, created overnight, and finds that sign-in restrictions have been relaxed.

• Inject 1: Logs show the new account has signed in to email, file storage and the cloud management console.
• Inject 2: The legitimate administrators’ multi-factor devices have been re-registered.
• Inject 3: Leadership asks whether to force every user to sign out, which would also lock the response team out of its own chat tool.

What it tests: Rev. 3 Section 2.3 calls for procedures for urgent processes such as redeploying the primary authentication platform. This scenario finds out whether you have one, whether break-glass accounts work, and whether responders have an out-of-band channel.

3. The stranger’s email

A security researcher writes to your general enquiries address, saying they found an export of your customer records on an open server, and attaches a redacted sample.

• Inject 1: The message sat unread in a shared mailbox before anyone forwarded it to security.
• Inject 2: The sample matches a data format used by a marketing analytics supplier, not your own systems.
• Inject 3: The researcher mentions a planned publication date.

What it tests: RS.MA-02.R2 asks for mechanisms that let third parties report possible incidents, and says such reports should be monitored carefully and taken seriously. It also tests the supplier contract, and the hand-off to counsel on whether any breach definition applies.

4. Managed service provider compromise

Your managed service provider tells you one of its remote management servers was compromised and that scripts may have been pushed to client environments.

• Inject 1: The provider will not yet share full indicators, citing confidentiality obligations to other customers.
• Inject 2: You find its remote access agent ran an unknown script on three of your servers.
• Inject 3: Leadership wants all provider access cut, but the same provider runs your patching and backups.

What it tests: Rev. 3 Section 2.2 expects contracts to define responsibilities, information flows, coordination and authority to act, including restrictions such as sharing sanitized incident information with other customers. GV.SC-08 asks for suppliers to be included in incident planning, response and recovery. Invite the provider to the exercise.

5. The departing insider

An engineer who has resigned triggers data loss alerts for large uploads to a personal cloud storage account.

• Inject 1: Their manager says the engineer is “just keeping their own notes”.
• Inject 2: Their last day is tomorrow and they still hold production access.
• Inject 3: HR asks whether the issue can be raised in the exit interview.

What it tests: whether the team recognizes a policy-violation incident with no outside attacker (see our security event vs incident post), RS.CO-03.R3 on notifying human resources of malicious insider activity, and RS.AN-07 on collecting evidence with the possibility of prosecution in mind.

6. Denial of service on the customer portal

The customer portal becomes unreachable during peak trading as traffic floods in from many sources.

• Inject 1: The internet service provider offers mitigation but needs approval from a named contact who is on leave.
• Inject 2: Sales asks to post a status update blaming “planned maintenance”.
• Inject 3: While everyone watches the portal, the SIEM flags a suspicious sign-in to the finance system.

What it tests: RS.MI-01.C2 suggests authorizing providers to act automatically against incidents such as large-scale DDoS attacks. ID.IM-04 notes that business continuity planners may be valuable in planning for denial-of-service conditions. The last inject tests whether a loud incident hides a quiet one.

7. The quiet beacon

Threat intelligence from your sector sharing group lists a domain, and DNS logs show one server contacting it at regular intervals. Nothing else has alerted.

• Inject 1: The asset inventory says the server was decommissioned.
• Inject 2: An analyst proposes leaving the connection open to watch the attacker.
• Inject 3: The sharing group asks for your indicators.

What it tests: declaration on ambiguous evidence (DE.AE-08), and the RS.MA-03.R3 trade-off between quick recovery and observing the attacker. Rev. 3 notes that redirecting an attacker to a sandbox delays containment and should be discussed with the legal department first.

How to run tabletop exercise scenarios

Assign five roles: an executive sponsor who owns the outcome, a facilitator who does not play, a scribe who records every decision with who made it and why, the participants, and one or more evaluators. Our incident response roles and responsibilities post covers who should be at the table.

Set the ground rules at the start. The session is no-fault. Participants use the plan as written and say so when it is silent. Questions that cannot be answered in the room go on a parking list with an owner. Timebox each inject so the session reaches the end, and close with a short hot wash while memories are fresh.

Run one of the tabletop exercise scenarios per session and rotate through the set. When a scenario involves a supplier, invite them; ID.IM-02 treats those joint exercises as a source of improvement in their own right.

Evaluating tabletop exercise scenarios

What to observe	Evidence to capture	Where the fix lands
Was the incident declared against written criteria?	Inject at which it was declared, and by whom	Declaration criteria, policy
Were the right people engaged?	Who was called, who could not be reached	Contact lists, roles
Was decision authority clear?	Who approved shutdowns and public statements	Policy authorities, escalation procedure
Was the plan used or improvised?	Plan sections cited, gaps noted	Plan, playbooks
Did third-party coordination work?	Contract terms consulted, contacts reached	Supplier contracts
Were communications accurate?	Draft internal and external messages	Communication procedures

Tabletop exercise scenarios only pay off when findings change something. Write each finding as an action with an owner and a due date, then track it to closure. ID.IM-04.R2 says plans should be reviewed periodically or when a need for significant improvement is identified, and a tabletop is one of the clearest ways to identify that need. The next exercise should re-test the fixes.

Tabletop exercise scenarios FAQ

How many tabletop exercise scenarios should we run each year?

Rev. 3 sets no number. A workable rule: over each planning cycle, cover every incident type you rank as high priority and every critical supplier at least once, and run an extra session after any major change to systems or people.

Who should attend?

The people who would make the real decisions in that scenario: the incident lead, the technical owners, legal, communications and HR where relevant, leadership for high-impact choices, and the suppliers involved.

Should tabletop exercise scenarios be realistic or extreme?

Plausible for your environment, with at least one inject that removes an assumption, such as an unavailable key person or a failed backup.

Is a cyber tabletop the same as a business continuity exercise?

No. Business continuity and fire exercises test other plans. Because Rev. 3 asks you to synchronize the two, two of these tabletop exercise scenarios, 1 and 6, work well as joint sessions.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Tabletop Exercise Facilitator Guide, the Tabletop Exercise Briefing Deck and the Ransomware Tabletop Scenario plus five other scenarios — for $99.