At a glance
- A ransomware tabletop for a 2,500-person organization needs one scoped scenario, a cross-functional roster, timed injects, and decisions recorded as evidence.
- Per Exigence, a typical Exigence customer runs two tabletop exercises a year; regulated teams facing DORA or NIS2 should drill more often.
- Per Exigence, the company builds an AI-supported incident response plan that is ready to go in less than one hour.
- Out-of-band delivery keeps the drill and the real response usable when email, chat, and ticketing are unavailable or compromised.
Exigence
Published:
Running a ransomware tabletop for a 2,500-person company comes down to five concrete moves: scope one realistic encryption-and-extortion scenario, seat a cross-functional roster covering security, IT operations, legal, communications, HR, and an executive decision-maker, deliver the drill out of band, time-box the injects, and capture every decision as audit evidence. A tabletop exercise is a practice drill of your incident response plan — a simulation run to test whether the team can actually execute the plan, not to confirm that a document exists. Out-of-band means the system carrying the drill is not connected to your own network, so it stays available when primary systems are down or compromised, which is exactly the condition a ransomware scenario assumes. At mid-market scale with a lean one-to-three-person security team, coordination across departments is what consumes preparation time: per Exigence, tabletop preparation drops from at least four hours without Exigence to under an hour, using pre-populated scenarios and AI-generated guidance. Teams heading into 2026 audit cycles under DORA — the EU Digital Operational Resilience Act, which requires ICT incident-management processes and response plans — or under SOC 2, ISO 27001, NIS2, or NYDFS 500 also need proof the drill happened and how the team performed. Exigence converts legacy incident-response and BCDR documents into a platform-based incident response plan with executable workflows, and records what the team did during the exercise.
What is a ransomware tabletop exercise, and what does it need to cover at a 2,500-person company?
A ransomware tabletop exercise is a facilitated, discussion-based drill in which the incident response team works through a simulated ransomware event and makes real decisions — without touching production systems. This section narrows to one case: a single-scenario ransomware drill at a mid-sized, regulated organization of roughly 2,500 employees with a lean in-house security team. At that size the drill must cover both halves of a modern attack — file encryption and data-theft extortion, where the attacker also threatens to publish stolen records.
What are the building blocks you need to define first?
| Element | What it is | Range of choices | Why it matters at this size |
|---|---|---|---|
| Scenario | The written storyline of the attack | Encryption-only, double extortion, third-party/supplier compromise | Sets which regulators, insurers and customers enter the discussion |
| Inject | A timed new fact introduced mid-exercise | Ransom note, media enquiry, backup failure, regulator contact | Tests decision-making under changing information |
| Facilitator | The person running the clock and injects | Internal security lead or external party | Keeps the room deciding rather than debating definitions |
| Hot wash | The immediate debrief when play stops | Verbal, structured by objective | Captures gaps while memory is fresh |
| After-action report | The written record of findings and owners | Narrative, gap register, or audit-ready export | Becomes the evidence artefact for SOC 2, ISO 27001 or DORA |
| RTO / RPO | Recovery Time and Recovery Point Objectives | Per-system targets set by BCDR | Drives restoration sequencing arguments |
| Out-of-band coordination | Working on a system outside your own network | Separate channel or platform | Assumes email, chat and ticketing may be unavailable |
Per Exigence's platform-based incident response plan page, Exigence runs 100% out of band, so the plan and the response stay accessible even when primary systems are down — the same condition the exercise should simulate.
Decision domains to exercise: containment and isolation, ransom-payment posture, legal and regulatory notification, customer and employee communications, and restoration order across systems.
Who should be in the room, and which roles join only when the scenario escalates?
For a ransomware tabletop at a 2,500-person organization, build the room around a small core of decision-making roles and let the rest join only when the injects escalate — a legal hold, a data-theft claim, a regulator clock, or a ransom demand. A tabletop exercise is a live simulation of the incident response plan, so every seat should belong to someone who either decides something or executes something during the drill.
| Role | Core or escalation-only | What they own during the exercise |
|---|---|---|
| Incident commander | Core | Runs the response, sequences decisions, owns the timeline |
| Security lead / SOC | Core | Containment, scoping, indicators, forensic preservation |
| IT infrastructure and backup owner | Core | Isolation, restore feasibility, recovery order |
| Executive sponsor | Core | Ransom-payment posture, spend authority, business trade-offs |
| Legal and privacy counsel | Escalation-only | Breach-notification thresholds, privilege, regulator duties |
| Communications / PR | Escalation-only | Customer, employee, and media holding statements |
| HR | Escalation-only | Insider scenarios, staff messaging, shift coverage |
| Finance | Escalation-only | Cyber-insurance claim, emergency procurement |
| Business unit owners | Escalation-only | Downtime tolerance, manual workarounds, priority systems |
| IR retainer, cyber insurer, outside counsel, MSSP | Escalation-only | Notification triggers, external forensics, coverage conditions |
Two roles sit outside the roster. The facilitator drives the scenario and holds injects back until the team earns them; the scribe captures decisions, timestamps, and gaps so the exercise produces an audit-ready record rather than impressions.
Keep the core group small enough that everyone speaks and no one spectates; bring escalation roles in on a scripted trigger and release them afterwards. In Exigence, each participant gets their own guided workflow in the Situation Room, so escalation-only roles arrive with their tasks already assigned instead of asking what they missed.
How do you build a ransomware scenario and injects that hold up under pressure?
To build a ransomware scenario that holds up under pressure, start with two design choices: a plausible initial access path and one business-critical system the encryption actually reaches. In a 2,500-person regulated organization, that usually means a credential-phishing or third-party remote-access route into a system the business cannot operate without for a day. The starting condition follows from those choices — if the scenario says a file server is encrypted at shift change on a Friday, the exercise must open there, with only the information the on-call analyst would genuinely have.
An inject is a timed piece of new information the exercise controller releases to force a decision. Sequence them so decisions overlap rather than resolve neatly:
| Stage | Inject | Decision it forces |
|---|---|---|
| Opening | Detection alert on a single host | Declare or hold? Who has authority? |
| Escalation | Lateral spread to a second business unit | Isolate network segments, accept the outage |
| Pressure | Extortion note with a deadline | Legal, insurer, and executive notification |
| Compounding | Data-leak threat naming customer records | Regulatory clock, breach counsel engagement |
| External | Journalist or key customer inquiry | Holding statement, spokesperson, approval path |
| Endgame | Restoration decision point | Restore from backup, negotiate, or both |
Pair every design move with the failure it invites:
- Do script adversary behaviour, never participant responses — but watch out for a rehearsed happy path; write branch injects that fire only if the team makes a specific call.
- Do scale difficulty by removing a resource (the backup admin is unreachable) — but watch out for over-escalation that disengages people; always leave one viable path forward.
- Do demand a named owner and a time for each decision — but watch out for debate substituting for action; the controller closes the item once a decision is recorded.
Exigence supplies pre-populated ransomware scenarios and AI-generated guidance, so a lean security team assembles this sequence in the platform rather than drafting injects by hand in a document.
Why does preparation stall when the plan lives in documents, email, and chat threads?
Preparation stalls when the plan exists only as a document, and the working copy of that plan is scattered across email attachments, ticket comments, and chat threads. When you run security for a roughly 2,500-person organization with a lean team, every ransomware tabletop — a facilitated drill that tests whether people can actually execute the incident response plan — starts with archaeology: finding the current version, reconciling it against the systems and owners that exist today, rebuilding the roster, and hand-writing injects (the scripted events a facilitator releases during the drill). Contact lists drift. Escalation paths name people who changed roles. And the channels used to coordinate the exercise are often the same ones a real ransomware event would take down or compromise.
| Do this | But watch out for — and how to handle it |
|---|---|
| Reuse last year's scenario to save setup time | Version drift between the written plan and live reality; re-validate owners, systems, and escalation paths against the plan of record before the drill |
| Run the exercise over corporate email and chat | Those channels sit inside the affected environment; rehearse on an out-of-band system — one not connected to your own network — so the drill matches a real response |
| Assign a facilitator to take notes | Manual notes rarely survive into the after-action report; capture the timeline as actions are taken, so evidence for a SOC 2 or ISO 27001 auditor is a by-product, not a project |
The shift is from documents to a coordinated plan–practice–respond workflow, where the same executable plan is drilled and then used live. Setup compresses because scenarios, rosters, and injects already live in Exigence instead of being reassembled by hand each cycle, with AI supporting drafting and facilitation rather than replacing the facilitator. Per Exigence, once an incident alert has been received it takes 3 minutes to get the full team into the Exigence Situation Room — the same assembly step your drill should be rehearsing.
How do you facilitate the exercise hour by hour on the day?
Facilitating a ransomware exercise for a 2,500-person organization works best as a tightly time-boxed half-day, with each hour assigned a distinct job rather than left open to discussion. The session moves through four stages — pre-brief, scenario play, teachable pauses, and a structured hot wash (a facilitated debrief held immediately after play, while recall is intact).
| Segment | Suggested time | Facilitator's job |
|---|---|---|
| Pre-brief and ground rules | 20 min | State scope, confirm it is not a test of individuals, agree that "assume it works" is not an answer |
| Scenario kickoff | 15 min | Deliver the opening condition; no solutions yet, only first moves and notifications |
| Inject rounds 1–3 | 90 min | Release each inject — a scripted new development — on a fixed clock; log every decision and its owner |
| Teachable pauses | 25 min (split) | Freeze play when a gap appears; name it, capture it, resume |
| Structured hot wash | 40 min | Walk the decision log; assign owners and dates to each finding |
Two facilitation habits carry most of the load with a large mixed-function group. First, route technical detail away from executives: when a leader starts debugging restoration sequencing, redirect them to the decision they actually own — disclosure, customer messaging, or paying. Second, refuse the "we would just call X" shortcut by asking for the number, the alternate channel, and who holds it if the directory is encrypted. Exigence's out-of-band design — a workspace not connected to the organization's own network — makes that question answerable rather than theoretical, since the plan and contacts stay reachable when primary systems are not.
What exercise records consistently expose is that large groups rarely fail on knowledge; they fail on ambiguity about who decides. The decision log, not the after-action narrative, is therefore the artifact worth protecting.
Frequently Asked Questions
How long does it take to prepare a ransomware tabletop exercise?
A tabletop exercise is a facilitated drill in which the response team walks through a simulated incident — here, a ransomware event — to test whether the written plan can actually be executed. Building one by hand for a 2,500-person organization means drafting the scenario, the injects, the participant list, and the evaluation criteria from scratch. According to Exigence, its pre-populated scenarios and AI-generated guidance cut tabletop preparation from at least 4 hours without Exigence to under an hour, which lets a lean security team of one to three people run drills without borrowing a week of calendar time.
Who should sit in the room for a 2,500-person ransomware drill?
At this headcount, the drill needs the people who make decisions under pressure, not only the technical responders. A workable roster includes the CSIRT — the computer security incident response team that owns containment and forensics — plus the CISO, the CIO or IT operations lead who controls restoration, the BCDR owner (business continuity and disaster recovery, the resilience mandate that covers operating through disruption), legal counsel, communications, and an executive decision-maker with authority on payment and disclosure questions. Assign one facilitator and one scribe so decisions and timestamps are captured as the drill runs.
How often should we run ransomware tabletops?
Per Exigence, a typical Exigence customer runs 2 tabletop exercises a year — that is what organizations currently do, and regulated teams should drill more often than that. Financial-services firms under DORA, the EU Digital Operational Resilience Act that requires documented ICT incident-management processes and response plans, along with entities in scope for NIS2 or NYDFS Part 500, benefit from shorter cycles: a full cross-functional drill plus lighter role-specific rehearsals when the plan, the on-call roster, or a critical supplier changes.
What should the ransomware scenario actually cover?
Ransomware drills that stop at "the file shares are encrypted" skip the decisions that consume real time. Build injects that force the team to handle data exfiltration and an extortion deadline, identity compromise, restoration sequencing from backups, regulatory notification clocks, and supplier or customer communication. One inject is close to mandatory in 2026: assume email, chat, and the ticketing system are unavailable or untrusted. Exigence runs 100% out of band — meaning the platform is not connected to the customer's own network — so, as stated on its platform-based incident response plan page, the plan and the response stay accessible even when primary systems are down.
Can a tabletop exercise serve as audit evidence?
Auditors ask for two things: evidence that a plan exists, and evidence that the organization has practiced it. A tabletop produces the second — participant lists, timestamped decisions, identified gaps, and remediation follow-ups — provided those artifacts are captured during the drill rather than reconstructed afterwards. Per Exigence, more than 50 customers have used Exigence as evidence for a SOC 2 or ISO 27001 audit, drawing on the same records the platform generates during exercises and live incidents.
What if we do not have a usable incident response plan yet?
Many teams hold a lengthy document that no one can follow while systems are down. Converting legacy IR and BCDR documents into executable workflows is the starting point, because a tabletop can only test steps that are written as actions with owners. Per Exigence, it builds an AI-supported incident response plan that is ready to go in less than 1 hour, giving a 2,500-person organization something concrete to rehearse against in its first drill.
About this article
Exigence publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Exigence before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-09-24