Cybersecurity Tabletop Exercise: 10 Ransomware Scenarios

A tabletop exercise is a facilitated, discussion-based rehearsal in which the people named in your incident response plan talk through a realistic scenario, decide what they would do and expose gaps before a real attack does. Nothing is touched in production. A cybersecurity tabletop exercise usually runs two to eight hours, follows a short scenario fed by timed "injects" and ends with a hotwash and an after-action report. This guide gives you the planning steps, ten ransomware scenarios with injects and questions, a facilitator checklist and a way to turn findings into technical tests.

What Is a Tabletop Exercise?

NIST defines a tabletop exercise as a discussion-based event where people with roles in a particular IT plan meet, discuss their roles during an emergency and their responses to a given situation, while a facilitator presents a scenario and asks questions. In NIST SP 800-84, the federal guide to test, training and exercise (TT&E) programs, a tabletop "is discussion-based only and does not involve deploying equipment or other resources." The same guide calls tabletops cost-effective tools to validate the content of IT plans such as incident response and contingency plans.

Three things make a session a tabletop rather than a meeting:

• A scenario. A short, plausible story, such as ransomware on your file servers, gives the discussion a shared starting point.
• Injects. The facilitator releases new facts over time ("the backup console is unreachable"), and each one forces a decision.
• Objectives and evidence. The group is checking something specific, such as who can authorize isolating a production network, and a data collector records what happens.

In security teams the abbreviation TTX is common, and NIST's glossary entry for tabletop exercise lists it as a synonym. When people say "cyber tabletop" or "incident response tabletop," they mean the same format applied to a security incident.

Tabletop exercise vs functional exercise vs red team vs purple team

A tabletop tests whether people know the plan and can make decisions together. It cannot prove that a detection fires or that a backup restores. That is the job of the hands-on exercises in the table below.

NIST SP 800-84 describes functional exercises as letting personnel validate their operational readiness by performing their duties in a simulated operational environment. For the other two, see our guides to what red teaming is and how an engagement runs and to running a purple team exercise. The most useful programs run all of them in a loop: the tabletop surfaces assumptions, and the technical exercises test them.

Why Ransomware Is the Default Tabletop Scenario

Ransomware touches every part of a response plan at once: detection, containment, backups, legal, insurance, law enforcement, customers, regulators and the board. That makes it the most efficient scenario for a first exercise, and it is common enough to justify the time. Verizon's 2026 Data Breach Investigations Report, which covers incidents from November 1, 2024 to October 31, 2025, says 48% of all breaches now involve ransomware and that 31% of breaches start with the exploitation of software vulnerabilities. For broader context, see our ransomware statistics roundup.

Government guidance points the same way. The CISA #StopRansomware Guide (September 2023) tells organizations to "regularly exercise a basic cyber incident response plan," keep offline, encrypted backups of critical data and use out-of-band communication methods during response. It also points readers to CISA's tabletop packages for ransomware scenarios. A tabletop is the cheapest way to find out whether your plan matches those recommendations before an attacker tests it for you.

How to Plan a Cybersecurity Tabletop Exercise

NIST SP 800-84 breaks a tabletop into four phases: design, development, conduct and evaluation. In practice, two extra steps matter just as much: the hotwash immediately after the session and the work of proving or fixing what the group assumed. The design phase is usually the longest. NIST notes that planning typically starts at least one month ahead for a simple exercise and at least three months ahead for a large, complex one.

Step 1: Choose the plan and set objectives

Start with the document you are testing, which is usually your incident response plan plus any ransomware playbook, business continuity plan and crisis communications plan. NIST SP 800-84 says tabletop objectives should validate three things: the content of the plan and related procedures, participants' roles and responsibilities as written, and the interdependencies the plan documents.

Turn those into three to five specific objectives that an observer can mark as met or not met. Good examples:

• Confirm who can declare a security incident and who can authorize isolating production systems, and how fast each can be reached outside business hours.
• Validate the decision path for engaging outside counsel, the cyber insurer and an incident response firm.
• Test whether the team can identify which systems must be restored first and which backups they would use.
• Check that the communications plan names who approves internal, customer, media and regulator messages.
• Confirm when and how the organization would contact law enforcement.

Avoid objectives such as "improve ransomware readiness." Nobody can score that.

Step 2: Pick the audience and the level

NIST recommends running senior-level and operational-level teams in separate tabletops at first, because their responsibilities differ, and then combining them to test coordination. It gives typical lengths of two to four hours for senior-level exercises and two to eight hours for operational ones.

Keep the room to people who own a decision or a task in the plan. Observers who will not speak make participants cautious. If a key role (for example, your managed service provider or cyber insurer's breach coach) cannot attend, assign someone to play it from a short brief.

Step 3: Assign the exercise roles

NIST SP 800-84 names two core staff roles: a facilitator who leads the discussion and a data collector who records what happens. CISA's tabletop packages add planners, evaluators and participants. A practical cast looks like this:

Step 4: Write the scenario and injects

NIST calls a common misconception the belief that scenarios must be very detailed. Long scenarios make participants debate the story instead of the objectives. Write a one-paragraph opening situation, then let injects carry the detail.

An inject is a timed piece of new information. Each one should push the group toward a decision tied to an objective:

Write six to ten injects for a three-hour session. Escalate pressure, but keep each inject plausible for your environment. If you use technical details, take them from public sources such as MITRE ATT&CK techniques T1486 Data Encrypted for Impact and T1490 Inhibit System Recovery, not from guesses.

Step 5: Prepare materials and logistics

NIST SP 800-84 lists four documents for a typical tabletop:

• Briefing: agenda, ground rules and logistics.
• Facilitator guide: purpose, scope, objectives, the scenario, the full question list and a copy of the plan being exercised.
• Participant guide: the same material without the full question list, plus a shorter set of orienting questions. NIST suggests sending it about one week before the exercise if you send it in advance.
• After-action report template: built around evaluation criteria written before the exercise, so the data collector knows what to capture.

Book the room or video bridge, confirm attendance in writing and decide whether the session is in person, remote or hybrid. In-person sessions produce better cross-team discussion; remote sessions should use a separate chat channel for the data collector and strict speaking order.

10 Ransomware Tabletop Exercise Scenarios

The scenarios below are written for a mid-sized organization with a SOC (in-house or outsourced), a Windows and cloud estate and a cyber insurance policy. Adjust names, systems and times to your environment. Each scenario lists injects, discussion questions and the technical test that would confirm what the room concluded. All scenarios are illustrative and contain no attack instructions.

Scenario 1: Encryption starts on the file servers

Setup: At 2:10 a.m. on a Tuesday, your SOC sees mass file renames on two file servers. Users in one office cannot open shared documents when they log in.

Injects:

• T+0:00, SOC: an alert shows thousands of file renames in ten minutes on two servers.
• T+0:20, help desk: users report unreadable files and a ransom note in every folder.
• T+0:45, IT operations: the backup console is unreachable and last night's jobs appear deleted.
• T+1:15, attacker email: the group claims it stole data and sets a 72-hour deadline.
• T+1:45, communications: a reporter asks about an outage.
• T+2:30, executive: sales asks whether to warn key customers today.

Discussion questions:

1. Who has authority to declare an incident at 2 a.m., and how is that person reached?
2. Do we isolate the affected segment now, or watch to learn scope first? Who decides?
3. Which systems must be restored first to keep the business running?
4. When do we call the insurer, outside counsel and law enforcement, and in what order?
5. Which communications channels do we trust if email and chat may be compromised?

What to test afterward: the time from first encryption activity to a confirmed alert, using a purple team exercise in a lab or approved scope.

Scenario 2: Data theft with no encryption

Setup: No systems are encrypted. A ransomware group posts your company name and a sample of internal files on its data leak site and emails your CEO.

Injects:

• The sample contains customer records and an HR spreadsheet.
• The group threatens to publish everything in five days and to contact customers directly.
• A customer's security team emails asking whether their data is affected.
• Finance confirms the company is publicly traded.

Discussion questions:

1. How do we confirm what was taken when nothing is encrypted and logs may be incomplete?
2. Who decides whether the incident is material, and how is that decision documented? For public companies, the SEC's Form 8-K Item 1.05 disclosure is generally due four business days after the company determines an incident is material.
3. Which state, sector or contractual notification duties could apply to the records in the sample?
4. Do we engage with the extortion group at all? Who is allowed to?

What to test afterward: whether data staging and bulk transfer out of the environment would be detected, through a purple team or red team objective focused on exfiltration.

Scenario 3: Backups deleted before encryption

Setup: Encryption begins on Saturday morning. Investigation shows the attacker used an administrator account to delete snapshots and backup catalogs two days earlier.

Injects:

• The most recent restorable copy is 19 days old, on an offline tape or immutable store.
• The backup administrator account was used from an unusual host.
• The recovery time the business expects is 24 hours.

Discussion questions:

1. Which backups are truly offline or immutable, and who can prove it today?
2. How do we confirm a backup is clean before restoring it?
3. What data loss is acceptable for each critical system, and who signs off?
4. Are backup administrator credentials separated from domain administrator credentials?

What to test afterward: a timed restore of one critical system from the offline copy into an isolated environment. The CISA guide's emphasis on offline, encrypted backups is only useful if the restore works.

Scenario 4: Compromise through a managed service provider

Setup: Your managed service provider (MSP) tells you that one of its remote monitoring and management (RMM) consoles was compromised. Several of its clients report ransomware.

Injects:

• Your environment shows the MSP's agent running scripts outside the maintenance window.
• The MSP cannot say which client tenants the attacker reached.
• Your contract does not specify incident notification times.

Discussion questions:

1. Can we cut the MSP's access quickly without losing the ability to operate?
2. Who in our company owns the relationship and the contract terms?
3. Which other vendors have similar remote access, and do we know their accounts?
4. How do we coordinate investigation with a vendor whose own systems are compromised?

What to test afterward: a third-party access review plus an assumed-breach test that starts from the vendor's access path. Our guide to third-party risk management covers the contract side.

Scenario 5: Help desk MFA reset leads to ransomware

Setup: A caller claiming to be a traveling executive persuades the help desk to reset multifactor authentication. Within hours, the account is used to reach admin tools and ransomware is staged.

Injects:

• The help desk followed the script, but the script allows resets with knowledge-based questions.
• The real executive is on a flight and unreachable.
• The account has access to the virtual desktop environment and finance applications.

Discussion questions:

1. How does the help desk verify identity for high-risk requests, and who can override it?
2. How fast can we disable a compromised executive account, and who has to approve that?
3. Which logs would show what the account did after the reset?

What to test afterward: an authorized social engineering penetration test of the reset process.

Scenario 6: Hypervisors encrypted, mass outage

Setup: The attacker encrypts virtual machine files at the hypervisor layer. Hundreds of servers go down at once, including domain controllers and the ticketing system.

Injects:

• Email, chat and the incident response plan (stored on a file share) are unavailable.
• The virtualization team's credentials were stored in a password vault hosted on the encrypted cluster.
• Leadership asks for an estimated time to recovery within the hour.

Discussion questions:

1. Where is the offline copy of the plan, contact lists and network diagrams?
2. Which out-of-band channel do we use, and has everyone got access to it?
3. What is the rebuild order for identity, infrastructure and business applications?
4. How do we avoid restoring the attacker's access along with the systems?

What to test afterward: a rebuild and restore drill for core identity services, plus a check that break-glass credentials are stored outside the infrastructure they recover.

Scenario 7: Cloud and SaaS data extortion

Setup: An attacker uses stolen session tokens to download data from your cloud storage and a SaaS platform, then demands payment. On-premises systems are untouched.

Injects:

• The SaaS provider's default log retention covers only part of the window.
• The tokens came from an infostealer infection on a contractor laptop.
• A regulator in one market asks for a preliminary report.

Discussion questions:

1. Can we revoke all active sessions and tokens across cloud and SaaS quickly? Who can?
2. Which cloud and SaaS logs do we collect, and for how long?
3. What does each provider contract say about forensic support and notification?

What to test afterward: a cloud logging and configuration review, and a purple team check of whether token misuse would be detected.

Scenario 8: Attack during a holiday weekend

Setup: Ransomware is detected on the Friday evening before a holiday weekend. The CISO is on leave abroad and the incident response lead is unreachable.

Injects:

• The on-call engineer is two months into the job.
• The incident response retainer requires a named contact to activate it.
• A board member hears about it and calls the CEO.

Discussion questions:

1. Who has delegated authority when primary decision makers are away?
2. Are contact lists current, and do they include personal phone numbers stored offline?
3. Can the on-call engineer start containment without waiting for approval?

What to test afterward: an unannounced out-of-hours call-tree test that measures how long it takes to reach each decision maker.

Scenario 9: The ransom payment decision

Setup: Recovery from backups will take two weeks. The attacker offers a decryptor and promises to delete stolen data in exchange for payment.

Injects:

• The insurer's breach coach asks whether the company has a payment policy.
• Counsel notes that the threat actor may be linked to a sanctioned group.
• The board asks for a recommendation by end of day.

Discussion questions:

1. Do we have a written position on ransom payments, approved before an incident?
2. Who checks sanctions exposure? The U.S. Treasury's Office of Foreign Assets Control (OFAC) issued an updated advisory on sanctions risks of facilitating ransomware payments in September 2021.
3. When do we involve law enforcement? The CISA guide advises consulting federal law enforcement about possible decryptors, even if mitigation actions are possible.
4. What would payment actually buy, and what would it not guarantee?

What to test afterward: no technical test; a policy review with legal, finance and the board, and a check of insurance terms. For context on how often victims pay, see our ransomware payout statistics.

Scenario 10: Reinfection after recovery

Setup: Two weeks after restoring operations, the SOC sees the same remote access tool beaconing from a restored server, and a new ransom note appears.

Injects:

• Some service account passwords were not reset during recovery.
• The restored server came from a backup taken after the initial access.
• Executives ask why the first response did not remove the attacker.

Discussion questions:

1. How did we decide the environment was clean, and what evidence did we use?
2. Which credentials, keys and tokens were rotated, and which were missed?
3. What extra monitoring runs for how long after recovery?

What to test afterward: a compromise assessment or red team engagement after recovery, focused on persistence and credential reuse. The CISA guide warns responders to take care not to re-infect clean systems during recovery.

Facilitator Checklist

Use this checklist to run any of the scenarios above. It combines the logistics and documentation steps in NIST SP 800-84 with practices that keep a cyber tabletop on track.

Before the exercise

• Executive sponsor has approved the date, scope and objectives in writing.
• Three to five measurable objectives are written and linked to plan sections.
• Participants are confirmed, including role players for outside parties.
• A trusted agent has reviewed the scenario for technical plausibility.
• The inject list has times, sources, expected decisions and fallback questions.
• The facilitator guide, participant guide and AAR template are ready.
• The data collector has a capture sheet organized by objective.
• Copies of the plan, contact lists and network diagrams are available offline.
• Ground rules are written: no-fault discussion, phones away, decisions over debate.
• Room or video bridge, timer and backup channel are tested.

During the exercise

• Open with introductions, objectives, ground rules and the "this is a safe space" message.
• Present the opening situation in under five minutes.
• Release injects on schedule; do not let one discussion consume the session.
• Ask "who decides?" and "how do you know?" more often than "what would you do?"
• Redirect debates about scenario realism back to the objectives.
• Capture parking-lot items instead of solving them in the room.
• Watch for silent participants and ask them directly.
• Keep time-stamped notes of key decisions and disagreements.

After the exercise

• Run a 15 to 30 minute hotwash immediately: what went well, what needs training, which plan sections must change.
• Collect participant feedback forms the same day.
• Draft the after-action report within about two weeks, while memory is fresh.
• Assign every recommendation an owner, a due date and a verification method.
• Brief the executive sponsor and schedule follow-up technical tests.
• Update the incident response plan and record the version change.

An illustrative three-hour agenda

After-Action Reporting

The after-action report (AAR) is where a tabletop turns into change. NIST SP 800-84 says the report should describe the exercise background (purpose, objectives, participants and scenario), the observations made by the facilitator and data collector, and recommendations for improving the plan. It also says evaluation criteria should be written before the exercise so data collectors know what to capture. The U.S. Homeland Security Exercise and Evaluation Program (HSEEP), whose latest revision was released in February 2020, pairs the report with an improvement plan in a single After-Action Report/Improvement Plan (AAR/IP).

A practical AAR for a cyber tabletop has six parts:

1. Exercise overview: date, scenario, objectives, participants and the plan version tested.
2. Summary for executives: three to five sentences on what worked and the most important gaps.
3. Results by objective: met, partially met or not met, with the evidence for each.
4. Strengths: decisions or behaviors worth keeping.
5. Areas for improvement: each gap stated as an observation, not a blame statement.
6. Improvement plan: the table below.

Illustrative example rows.

Keep the AAR factual and no-fault. Participants who expect to be blamed will stop speaking openly in the next exercise.

Turning Tabletop Findings Into Tests

A tabletop produces statements, not proof. Phrases such as "we would see that," "our backups are isolated" or "the help desk would never reset that" are assumptions until someone tests them. The highest-value output of a cybersecurity tabletop exercise is a short list of those assumptions, each converted into a technical test with an owner and a date.

Three practices make the bridge work:

• Write assumptions down during the session. Ask the data collector to tag every "we would" statement. These become the test backlog.
• Pick the right test type. Detection questions suit a purple team exercise, where red and blue run techniques in the open and tune detections on the spot. Questions about whether a realistic attacker could reach the crown jewels at all suit a covert red team engagement. Repeated checks of known techniques suit breach and attack simulation.
• Bring results back to the next tabletop. If a purple team found that encryption precursors went undetected for hours, the next tabletop's first inject should reflect that. Track improvements with metrics such as mean time to detect (MTTD).

The loop also works in reverse. A red team report shows what an attacker did; a tabletop built on that attack path shows whether the organization would have made the right decisions once it noticed. Running the tabletop on a real attack narrative is often more persuasive for executives than a hypothetical one.

Free Tabletop Exercise Resources

You do not need to write everything from scratch. Three free, government-backed resources cover most needs:

Open the resources: CISA Tabletop Exercise Packages (CTEPs), Exercise in a Box and NIST SP 800-84.

NIST SP 800-84 dates from September 2006, so treat its logistics checklist (which mentions CD-ROMs) as dated, but its exercise method still holds. For incident response planning itself, NIST replaced SP 800-61 Rev. 2 with SP 800-61 Rev. 3 in April 2025, which ties incident response to the Cybersecurity Framework (CSF) 2.0. Make sure your tabletop tests the plan you actually have, aligned to current guidance.

Common Tabletop Exercise Mistakes

• Testing the scenario instead of the plan. If the room spends 40 minutes arguing whether the attack is realistic, the scenario is too detailed or the facilitator is not redirecting.
• Only inviting the security team. Ransomware decisions sit with legal, finance, communications and executives too.
• Making it a blame session. People hide gaps when they expect consequences.
• No measurable objectives. Without them, the AAR becomes a list of opinions.
• Skipping the hotwash. The best observations come in the first 30 minutes after the session ends.
• An AAR with no owners. Recommendations without names and dates rarely get done.
• Treating the tabletop as proof. A discussion cannot confirm that detections fire or backups restore; schedule the technical test.
• Running the same scenario every year. Rotate scenarios and raise difficulty as the plan matures.

How Often Should You Run a Tabletop Exercise?

NIST SP 800-84 says organizations should run tabletop exercises periodically and also after organizational changes, plan updates or new exercise guidance. It notes that federal agencies must exercise or test system contingency plans at least annually under NIST SP 800-53. A practical cadence for most organizations is at least one full ransomware tabletop a year for executives, more frequent short operational exercises for the response team, and an extra session after any major change such as a merger, a new MSP, a cloud migration or a significant incident. Our incident response plan guide recommends supplementing annual tabletops with red or purple team engagements, which is the loop this guide describes.

Frequently Asked Questions

What is a tabletop exercise in cybersecurity?

A cybersecurity tabletop exercise is a facilitated discussion in which the people responsible for incident response walk through a realistic attack scenario, such as ransomware, and talk through their decisions and actions. NIST describes tabletops as discussion-based only; no systems are touched. The goal is to validate the incident response plan, roles and handoffs, and to find gaps before a real incident.

What is an example of a tabletop exercise?

A common example is a ransomware scenario: the SOC sees mass file encryption overnight, backups turn out to be deleted, the attacker claims to have stolen data and a reporter calls. Participants decide who declares the incident, what to isolate, what to restore first and who to notify. The ten scenarios in this guide are ready-to-adapt examples.

How long does a tabletop exercise take?

NIST SP 800-84 says tabletops typically last two to eight hours. Senior-level sessions usually run two to four hours and operational sessions two to eight. A three-hour session with six injects and a 30-minute hotwash works well for a first ransomware exercise.

Who should participate in a cyber tabletop exercise?

Everyone with a role in the incident response plan: the incident response lead, SOC, IT operations, identity and backup owners, legal, communications, finance and an executive decision maker. NIST recommends separate sessions for senior and operational teams at first, then a combined one.

What is an inject in a tabletop exercise?

An inject is a timed piece of new information released by the facilitator during the exercise, such as "the backup console is unreachable." Each inject should force a decision tied to an exercise objective.

What goes in a tabletop exercise after-action report?

Background (purpose, objectives, participants, scenario), observations recorded by the facilitator and data collector, and recommendations for improving the plan, according to NIST SP 800-84. Add an improvement plan with an owner, a due date and a verification method for each recommendation.

Is a tabletop exercise the same as a penetration test or red team?

No. A tabletop tests people, decisions and the plan through discussion. A penetration test or red team engagement tests real systems and controls. They complement each other: the tabletop shows what the organization assumes, and technical testing shows whether those assumptions hold.

Next Step: Put Your Tabletop Assumptions to the Test

A good cybersecurity tabletop exercise leaves you with a better plan and a short list of things the room believed but could not prove. Pick one scenario from this guide, run it with the facilitator checklist, write the after-action report within two weeks and turn the top three assumptions into tests.

When the open question is whether a real attacker could get from a phished user to a ransomware-ready position without being noticed, you need an adversary's view. DeepStrike's red teaming services include ransomware deployment simulation as a campaign objective and measure your SOC, alerting and response workflows against realistic tradecraft. The debrief gives your teams attacker pathways, evidence, remediation priorities and retest-ready next actions, which you can feed straight into your next tabletop. To discuss scope, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• NIST SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (September 2006)
• NIST CSRC Glossary: Tabletop Exercise
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025)
• CISA Tabletop Exercise Packages (CTEPs)
• CISA #StopRansomware Guide
• UK NCSC: Exercise in a Box
• FEMA: Homeland Security Exercise and Evaluation Program (HSEEP)
• Verizon 2026 Data Breach Investigations Report
• U.S. SEC press release 2023-139: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (July 26, 2023)
• U.S. Treasury OFAC: Publication of Updated Ransomware Advisory (September 21, 2021)
• MITRE ATT&CK T1486: Data Encrypted for Impact
• MITRE ATT&CK T1490: Inhibit System Recovery