Ransomware tabletop exercise guide for security and IT teams

A ransomware tabletop exercise is a structured, discussion-based simulation where your incident response, legal, communications and leadership teams talk through a fake ransomware attack, step by step, to find the gaps in your plan before a real attacker does. It's not a live drill, no systems get touched, and nobody loses access to anything. It's a room (or a video call), a scenario, and a facilitator forcing hard decisions.

If you're planning your first one, or your fifth, here's where to start this week:

1. Pull the official templates first. Download CISA's Tabletop Exercise Packages and the StopRansomware Guide before you write anything yourself.
2. Set two to four decision-focused objectives (escalation timing, executive communications, vendor coordination) rather than trying to test everything at once.
3. Book your cross-functional group now. IT, security operations, legal, communications, one senior executive, and your managed security provider all need a calendar hold, because scheduling is usually the slowest part of this whole process.

The rest of this guide walks through participant roles, four ready-to-use scenario cards with timed injects, facilitation mechanics, and how to turn your after-action report into changes that actually stick.

Key Takeaways

A ransomware tabletop exercise works because it forces decisions under time pressure and produces an owner-assigned action plan, not just a conversation about hypothetical risk.

Table of Contents

• What is a tabletop exercise and when should you run one?
• What does a ransomware tabletop exercise actually accomplish?
• Who needs to be in the room, and what should they bring?
• Building a repeatable planning checklist for your tabletop
• Four ransomware scenarios you can run this quarter
• How to run the exercise without it turning into a lecture
• Turning the exercise into an after-action report that gets used
• Mapping your findings back to real response playbooks
• How Nexus runs ransomware tabletop exercises for clients
• What actually separates a useful tabletop from a wasted afternoon
• How Nexus can help you plan and run your next exercise
• Templates and authoritative resources worth reusing
• Frequently asked questions
• Sources

What is a tabletop exercise and when should you run one?

A tabletop exercise is a conversation, not a test of your tools. Participants sit down with a scenario, receive a series of "injects" (new pieces of information that escalate the situation), and talk through what they'd actually do. Nobody types a command. Nobody isolates a real server. The entire value comes from exposing what your team assumes will happen versus what would actually happen when the ransom note shows up on 40 workstations at 6:45 a.m.

That distinction matters when you're deciding between a tabletop and something more intensive. A functional exercise or a live-fire red team engagement actually exercises your tools: your backup restoration process, your EDR alerting, your network segmentation. A tabletop exercise tests judgment, coordination and communication under pressure. If you've never run any kind of exercise, start with the tabletop. It's cheaper, it's faster to organize, and it surfaces the process failures that no amount of technical hardening will fix, like nobody knowing who has legal authority to approve a ransom conversation with law enforcement.

Scope your tabletop deliberately across three domains: incident response (who does what, in what order), business continuity (how the organization keeps operating while systems are down), and crisis communications (what gets said, to whom, and when). Most organizations that run a single narrow "IT only" tabletop miss the fact that a ransomware event is a business crisis long before it's fully a technical one. A cyber incident response plan built without this cross-functional lens tends to fall apart at the exact moment executives start asking questions the IT team can't answer alone.

What does a ransomware tabletop exercise actually accomplish?

The point isn't to "raise awareness." It's to produce a specific, testable answer to questions your plan currently only assumes the answer to. Good tabletop exercise objectives are decision-focused: can your team decide, within an acceptable window, whether to isolate a segment of the network, notify a regulator, or authorize a conversation about ransom payment?

Four objective categories consistently produce the most useful results:

• Escalation speed: how long does it take from initial detection to the right decision-maker being briefed and empowered to act?
• Communications discipline: does the team have a pre-approved holding statement, or does someone start improvising language to the press or to customers?
• Recovery prioritization: does the group know which systems get restored first, and who makes that call when finance and operations both claim priority?
• Vendor and MSSP coordination: does everyone know exactly what your managed security provider is contractually obligated to do versus what your internal team owns?

Tie each objective to a measurable success criterion. "Time to escalation" should have a target timeframe to notify the incident commander. "Number of action items with assigned owners" is a fair proxy for whether the exercise produced anything durable, versus just a good conversation. Practitioner guidance on designing tabletop objectives consistently points to the same failure mode: exercises with too many objectives produce a mile-wide, inch-deep discussion that nobody can act on afterward. Pick a small number of objectives rather than too many.

Who needs to be in the room, and what should they bring?

Ransomware incident response is never an IT-only problem, and your participant list should reflect that from the first invitation. CISA's tabletop packages emphasize broad stakeholder engagement specifically because coordinated response across IT, legal, communications and leadership is where most real-world response plans break down.

Core stakeholder groups to invite:

• IT operations and infrastructure leads
• Security operations (SOC analysts, threat detection owners)
• Legal counsel (internal or outside breach counsel)
• Communications or PR lead
• One senior executive with real decision authority, not just an observer
• Procurement or vendor management
• Facilities (if physical access or badge systems are in scope)
• Your MSSP or third-party security provider, if you outsource any part of detection or response

Each participant should walk in with specific homework, not just goodwill. Ask them to prepare in advance:

1. Their decision authority: what can they approve alone, and what needs sign-off from someone else?
2. Current contact lists for their function, including after-hours numbers.
3. Any service-level assumptions they're relying on (e.g., "our MSSP guarantees detection within 15 minutes").
4. Quick-reference data: system inventories, data classification maps, insurance policy numbers.

If you're bringing in external partners, like your cyber insurance broker or an outside forensics firm, settle disclosure boundaries and NDA coverage before the session starts, not mid-exercise. Nothing derails a tabletop faster than a legal debate about what a vendor is allowed to hear.

Building a repeatable planning checklist for your tabletop

A reproducible design cycle beats reinventing the process every time. Public-sector exercise guidance from the EPA lays out an eight-step exercise tool that maps cleanly onto ransomware planning: identify objectives, select participants, develop the scenario, conduct the exercise, run a hot wash, then produce an AAR and improvement plan. Steal that structure.

Here's the sequence in practice:

1. Set two to four decision-focused objectives.
2. Select participants and confirm their prework assignments.
3. Develop a scenario matched to your actual environment (not a generic template).
4. Draft your injects, timed to escalate realistically.
5. Prepare materials: situation manual, slide deck, feedback forms, AAR template.
6. Set the date and time, ideally two to three weeks out to give people room to prep.
7. Run a short pre-brief with the facilitator and evaluators so everyone knows their role.
8. Confirm logistics: room, video conferencing, whiteboard or shared doc for capturing action items live.

Pro Tip: Resist the urge to test every system and every team function in one session. A tabletop with four sharp objectives and a two-hour runtime produces more usable action items than a sprawling half-day exercise where energy collapses after ninety minutes.

Four ransomware scenarios you can run this quarter

Generic "a ransomware attack happens" scenarios produce generic discussions. These four scenario cards are built around distinct attack vectors, each with a clear objective, a narrative setup, and timed injects that force real decisions rather than just narration.

Scenario 1: Supplier compromise cascades into your environment Objective: test vendor coordination and third-party escalation protocols. Setup: Your managed payroll provider notifies you at 8:00 a.m. that they've detected ransomware activity on a shared file transfer system your organization uses weekly.

• Inject 1 (0 min): Vendor's initial notification arrives via email, low detail.
• Inject 2 (+15 min): Vendor confirms data exfiltration occurred; unclear if your data was included.
• Inject 3 (+30 min): Your own SOC flags unusual outbound traffic on a workstation that connects to the vendor portal.
• Inject 4 (+45 min): Legal asks whether this triggers a regulatory notification obligation.
• Discussion questions: Who owns the decision to disconnect the vendor integration? What does your contract say about the vendor's breach notification duty?

Scenario 2: Internal credential theft and lateral movement Objective: test detection-to-containment speed and internal communications discipline. Setup: A help desk employee reports a suspicious password reset request that wasn't initiated by them.

• Inject 1 (0 min): Help desk flags the anomaly.
• Inject 2 (+20 min): SOC confirms the account was used to access a file server overnight.
• Inject 3 (+40 min): Ransomware note appears on three shared drives.
• Inject 4 (+55 min): An employee posts about "IT being down" on social media.
• Discussion questions: Who decides to force an organization-wide password reset? Who manages the social media exposure?

Scenario 3: Encrypted backups discovered during recovery Objective: test recovery prioritization and executive decision-making under pressure. Setup: Twelve hours into containment, your backup administrator discovers the last three weeks of backups are also encrypted.

• Inject 1 (0 min): Backup team reports the issue to the incident commander.
• Inject 2 (+10 min): Finance asks how long payroll processing will be delayed.
• Inject 3 (+25 min): Insurance broker asks whether ransom negotiation is being considered.
• Inject 4 (+40 min): A board member requests a written update within the hour.
• Discussion questions: What's your actual offline or immutable backup coverage? Who is authorized to discuss ransom payment, and with whom?

Scenario 4: Physical intrusion via USB device Objective: test physical security coordination and facilities/IT crossover response. Setup: A visitor badge is used to access a server room, and an unknown USB device is later found connected to a workstation.

• Inject 1 (0 min): Facilities reports the badge anomaly to security.
• Inject 2 (+15 min): IT discovers the USB device and unusual process activity on the connected machine.
• Inject 3 (+30 min): Ransomware begins encrypting files on a shared network drive.
• Inject 4 (+45 min): Facilities asks whether law enforcement should be called for the physical intrusion.
• Discussion questions: Who coordinates between physical security and the cyber incident response team? Is there a documented handoff process?

A facilitator script excerpt for delivering an inject might sound like this: "It's now 9:45 a.m. Your backup administrator just told the incident commander that the last three weeks of backup data show signs of encryption. Finance wants to know if payroll will run on time. What does the group decide in the next five minutes?" That's the format: state the fact, name the pressure, force a timed decision.

How to run the exercise without it turning into a lecture

The single biggest facilitation failure is letting one senior person narrate the "correct" answer instead of forcing the group to work it out. A good facilitator asks neutral, open prompts, "what would you do right now," rather than leading questions that telegraph the expected response. Well-designed injects reveal dependencies and timing gaps rather than testing whether people remember trivia about their own incident response plan.

Facilitation practices that consistently work:

• Keep each inject discussion timeboxed, five to ten minutes maximum, and move on even if consensus hasn't fully formed.
• Assign one evaluator per major stakeholder group to capture decisions and dissent in real time.
• Control scope aggressively; if the room starts debating unrelated technical architecture, redirect back to the decision at hand.
• For virtual sessions, use a shared document visible to all participants so action items get captured live, not reconstructed from memory afterward.
• Run the same core scenario twice with escalating injects across separate sessions if your first attempt felt rushed. Repeat exercises with sharper injects tend to surface assumptions the first pass missed entirely.

Pro Tip: Assign someone whose only job is capturing decisions, assumptions and action-item owners as they're spoken, live, in a shared doc projected on screen. If you wait until the next day to reconstruct what was decided, half of it gets lost or misremembered, and your after-action report ends up softer than the actual conversation was.

Turning the exercise into an after-action report that gets used

An after-action report that sits in a shared drive unread is worse than not running the exercise at all, because it creates a false sense that gaps were addressed. A usable AAR documents the exercise purpose, the objectives tested, who participated, what injects were delivered, what decisions the group made (and where they disagreed), the gaps identified, and specific recommended actions.

Prioritize the resulting action items with a simple impact-versus-effort framing rather than tackling everything in the order it was raised:

1. High impact, low effort: Fix immediately. Example: update the after-hours contact list for the incident commander.
2. High impact, high effort: Schedule with a firm deadline and an accountable owner. Example: negotiate an immutable backup retention clause with your storage vendor.
3. Low impact, low effort: Batch these into a quarterly cleanup pass.
4. Low impact, high effort: Document and deliberately defer, revisit at the next planning cycle.

A sample action-item entry should read like this: "Update crisis communications holding statement template to cover regulatory notification language, owner: Communications Lead, due: 30 days, retest at next quarterly TTX." CISA's ransomware response checklist specifically calls out documenting lessons learned as a step in its own recovery sequence, not an optional add-on after the technical work is done. Every action item needs a retest date. Without one, "we'll fix that" quietly becomes "we never fixed that."

Mapping your findings back to real response playbooks

The exercise itself is only half the value. The other half is making sure gaps found in the tabletop actually change your operational runbooks, not just live in a slide deck nobody opens again. Build a simple mapping table connecting each AAR gap to the specific playbook section it affects, an owner, and a deadline.

Each of these maps directly to items the StopRansomware Guide already recommends checking: detection speed, containment steps, and communication protocols. Rather than reauthoring your own version of this guidance from scratch, adapt CISA's checklist language directly into your runbook and cite where your organization's specific process deviates. Small organizations can typically fit this into a two-page runbook appendix. Larger enterprises usually need a dedicated escalation matrix per business unit, since a single generic decision chain rarely survives contact with a multi-division org chart.

If your scenario touched supplier risk, it's worth reviewing how third-party cybersecurity risks typically enter through vendor integrations you don't directly control, since that's exactly the exposure Scenario 1 above is built to surface.

How Nexus runs ransomware tabletop exercises for clients

AccountNext-Nexus builds ransomware tabletop exercises around client environments rather than handing over a generic slide deck and walking away. The scope of a typical engagement includes:

• Objective-setting workshops to identify the two to four decision points most relevant to a client's actual infrastructure and risk profile
• Custom scenario and inject development, drawing on real attack patterns observed across cloud and on-premises environments
• Live facilitation, with a dedicated evaluator capturing decisions, assumptions and owners in real time
• A written after-action report with a prioritized, impact-versus-effort action plan
• Follow-up support translating AAR findings into updated incident response runbooks

A typical engagement runs across four phases: a planning and scoping call (roughly one to two weeks), the live exercise itself (two to four hours), AAR delivery (within about a week), and an optional remediation support phase where Nexus helps implement the highest-priority fixes identified.

Clients working through this process with Nexus generally report the same recurring gaps other organizations find, unclear escalation authority, outdated vendor contacts, and untested backup assumptions, but the value comes from having those gaps documented with an owner and a deadline instead of surfacing informally in a hallway conversation after a near-miss.

What actually separates a useful tabletop from a wasted afternoon

Here's the uncomfortable pattern across most tabletop exercises that don't produce lasting change: the room agrees on everything a little too easily. Nobody wants to be the person who says "actually, I don't think we could get legal sign-off that fast," so the exercise quietly drifts into a performance of confidence rather than an honest stress test. The fix isn't a better scenario. It's a facilitator willing to interrupt consensus and ask, "would that actually happen, though, given how our approval chain works today?"

Two patterns show up consistently. First, organizations that skip the pre-work (asking participants to bring their real contact lists, their real decision authorities) end up running a tabletop about an idealized version of their organization rather than the actual one. The exercise feels productive and produces almost nothing usable, because the gaps that show up are fictional. Second, organizations that treat the AAR as the finish line rather than the starting line lose the momentum entirely. An action item with no retest date has roughly the same shelf life as a New Year's resolution.

What consistently works instead: keeping the objective count low, assigning a dedicated note taker whose only job is capturing decisions as they happen, and scheduling the retest before the current exercise even ends. That last part sounds trivial. It isn't. Booking the follow-up session while everyone's still in the room, before calendars fill back up, is the difference between an improvement plan that gets executed and one that gets filed.

If there's one habit worth stealing from mature security programs, it's running the same core scenario a second time, months later, with sharper injects, specifically to see whether last quarter's fixes actually changed behaviour under pressure. That second run tells you more than the first one ever could.

How Nexus can help you plan and run your next exercise

Running a sharp ransomware tabletop exercise takes more than a downloaded template. It takes someone who's watched enough of these sessions stall out to know exactly where the conversation needs a push. AccountNext-Nexus is the alternative to building this in-house from scratch: instead of spending weeks assembling scenarios, chasing down participants, and drafting an AAR nobody's confident is complete, you get a facilitated exercise built around your actual environment, with a written improvement plan and follow-up support baked in.

A Nexus-led engagement covers scenario design tailored to your infrastructure, live facilitation with dedicated note-taking, a prioritized after-action report, and hands-on support turning findings into updated runbooks. That last piece is what most in-house attempts skip entirely, and it's usually where the real value gets lost. Because AccountNext-Nexus also handles 24/7 threat detection, incident response and compliance under one contract, the gaps your tabletop uncovers can move straight into remediation without a second vendor search.

If you're ready to scope a session, start with a short call to walk through your objectives, participant list and timeline. Visit AccountNext-Nexus's services page to request a scoping conversation and see sample deliverables before you commit to a date.

Templates and authoritative resources worth reusing

Rebuilding these materials from scratch wastes time you could spend on scenario realism instead. Start with what's already been built and vetted:

• CISA Tabletop Exercise Packages: full CTEP sets with situation manuals, discussion questions and AAR templates, adaptable for ransomware-specific scenarios.
• CISA CTEP package documents resource list: the single index page to download the actual CTEP files rather than searching CISA's site piecemeal.
• #StopRansomware Guide: use this for the checklist steps your scenario injects and your AAR recommendations should map back to.
• Ransomware response checklist: a compact reference for the detection-through-recovery sequence your incident commander should already know cold.
• Ransomware playbook (Canadian Centre for Cyber Security): a Canadian-focused companion to the CISA materials, useful for aligning terminology and roles with domestic guidance.
• How to Run a Ransomware Tabletop Exercise [+ Scenarios] - AlertMedia: a practical walkthrough with sample scenario wording if you want a second reference point beyond the government templates.

Adapt these rather than reauthoring them line by line. The scenario language, discussion prompts and AAR structure in the CISA packages have already been through multiple rounds of federal review, and a security incident response plan template can help you convert your AAR findings directly into an updated runbook once the exercise wraps.

Frequently asked questions

How long should a ransomware tabletop exercise run? Most effective sessions run a few hours. Longer sessions tend to lose participant energy after a time, which is why keeping your objective count low matters more than trying to cover every possible scenario in one sitting.

Who should facilitate a ransomware tabletop exercise? A neutral facilitator who isn't part of the incident response chain works best, someone who can ask open questions and push back on easy consensus without personally owning the answer. Many organizations bring in an outside facilitator, from a managed security provider or consultancy, specifically to avoid internal politics shaping the discussion.

How often should we run a tabletop exercise? Annually at minimum, with a retest scheduled for any high-impact gaps found in the previous session's after-action report. Organizations dealing with regulatory pressure (healthcare, financial services) often run them twice a year.

Do we need real ransomware scenarios, or can we use generic templates? Generic templates are a fine starting point, but the most valuable exercises use scenarios matched to your actual attack surface, your cloud provider, your MSSP relationship, your specific backup architecture. A supplier-compromise scenario means little if you don't outsource anything critical; a physical-intrusion scenario matters far more if your server room has loose badge controls.

What's the difference between a tabletop exercise and a full incident response drill? A tabletop tests decisions and communication through discussion; nobody touches live systems. A functional or full-scale drill actually exercises technical recovery, like restoring from backup or isolating network segments, and requires far more coordination and downtime risk to run.

What should go into the after-action report? Purpose, objectives tested, participant list, injects delivered, key decisions made, gaps identified, and a prioritized list of recommended actions with named owners and deadlines. A report missing owners and deadlines rarely produces follow-through.

This article provides general guidance on planning cybersecurity exercises and is not a substitute for a tailored risk assessment. Confirm current regulatory notification requirements with legal counsel and consult primary sources like CISA for the latest official templates.

Sources

• CISA Tabletop Exercise Packages
• #StopRansomware Guide
• Ransomware response checklist
• Ransomware playbook (Canadian Centre for Cyber Security)
• How to Run a Ransomware Tabletop Exercise + Scenarios - AlertMedia

Recommended

• Healthcare network security best practices for Canadian IT teams
• Cyber incident response plan guide for Canadian SMBs
• How to secure customer data affordably for small businesses
• Enterprise incident response checklist: 2026 guide