Most tabletop exercises fail in the same place: not during containment, but in the first 20 minutes when the room realizes the runbook assumes cleaner telemetry, clearer ownership, and faster legal review than reality allows. A strong incident response tabletop exercise example should expose those gaps early, with enough technical depth to stress decision-making rather than turn the session into compliance theater.
For experienced defenders, the value is not in rehearsing obvious steps like “check EDR” or “notify leadership.” It is in forcing the organization to reconcile conflicting priorities under realistic conditions: preserve evidence or restore service, isolate a business-critical host or maintain availability, disclose quickly or validate scope first. A useful tabletop tests coordination across SOC, IR, IT, legal, communications, identity, cloud, and executive stakeholders without pretending every alert arrives fully enriched.
What a good tabletop is actually testing
An incident response tabletop exercise is often framed as a procedural review, but that undersells it. At a mature program level, the exercise is testing four things at once: whether detection translates into action, whether authority boundaries hold up under pressure, whether telemetry is sufficient to support scoping, and whether the organization can make defensible decisions with incomplete information.
Track Threat Intelligence like this every Monday.
Every Monday, the 5 threats SOC teams can't afford to miss — with analyst commentary.
That means the scenario has to be plausible enough for technical teams to engage seriously. If the story is too abstract, analysts default to generic answers. If it is too scripted, leadership performs rather than decides. The right design gives participants enough evidence to move forward, but not enough certainty to avoid trade-offs.
Incident response tabletop exercise example: ransomware via identity compromise
Consider a mid-size enterprise with hybrid identity, Microsoft 365, a cloud-hosted ERP platform, and a mix of corporate Windows endpoints and a small set of Linux servers supporting internal applications. The scenario begins at 8:15 a.m. on a Tuesday when the SOC receives several medium-fidelity alerts: impossible travel on a privileged account, suspicious OAuth consent activity, and a spike in failed SMB connections from a workstation used by a finance manager.
At this stage, the security team does not know whether the events are related. The first decision point is not “is this ransomware?” but “what threshold justifies elevating to an incident?” That matters because many teams have escalation criteria that look precise on paper but rely on an analyst confidence level that is hard to establish with partial telemetry.
Ten minutes into the exercise, an inject arrives: the help desk reports multiple users cannot open shared finance files, and several filenames now include an unfamiliar extension. The EDR console shows one endpoint spawning vssadmin delete shadows, while identity logs indicate recent token use from a VPN exit node not previously associated with the employee account. Now the room has a working hypothesis: initial access may have involved credential theft or session hijacking, followed by lateral movement and early-stage encryption.
This is where the exercise becomes operationally useful. The facilitator should ask the incident commander to declare severity, assign workstreams, and state immediate priorities. Most teams will say some version of contain, scope, and preserve evidence. The exercise should then force specifics. Which accounts are disabled first? Is the affected workstation isolated even if it belongs to payroll during processing hours? Who has authority to revoke active sessions across cloud identity? Is network containment delegated to infrastructure or approved through change control?
How the scenario should unfold
A good tabletop needs timed injects that alter assumptions. In this example, the next inject reveals the privileged account belongs to an IT administrator whose credentials were recently used to approve a third-party remote support session. A second inject shows outbound traffic from a domain controller to an IP not previously seen in the environment, but NetFlow retention only goes back 48 hours. A third inject comes from legal: the encrypted share may contain employee tax records and vendor banking data.
At this point, participants should be made to choose between parallel actions that compete for staff and time. The SOC wants broad account lockouts. IT operations warns that aggressive disablement could break service accounts tied to ERP integrations. Legal wants a clearer answer on data access before any external statement. Executive leadership wants to know whether the event is “contained” before approving a business disruption.
Those tensions are the point. Real incidents are not linear. If the tabletop only validates the happy path, it will miss the organizational friction that slows response.
The roles that matter most
For this scenario, the most valuable participants are the incident commander, SOC lead, identity or IAM owner, infrastructure lead, legal counsel, communications lead, and a business owner from finance or operations. If your environment is cloud-heavy, include the cloud platform team. If you rely on MDR, outside counsel, DFIR retainer support, or cyber insurance breach coaches, model their involvement explicitly even if they are not in the room.
The facilitator should not let teams hide behind “we would call the vendor.” The exercise should test when that call happens, what evidence is available at that moment, and whether internal teams can continue meaningful containment while external support mobilizes.
What “good” looks like in participant responses
A mature team response in this incident response tabletop exercise example would start with a clear command structure and bounded objectives for the first hour. The incident commander would establish severity, confirm communication channels, and define a decision log. The SOC would begin scoping affected identities, hosts, and shares while preserving volatile artifacts where possible. IAM would revoke sessions, rotate high-risk credentials, and review privileged role activation. Infrastructure would isolate confirmed affected systems and assess whether segmentation can limit spread without unnecessary outage.
Just as important, legal and communications would not wait passively for technical certainty that may never arrive. They would define disclosure triggers, regulatory timelines, and internal executive messaging based on scenarios rather than a single factual endpoint. That is a common failure point in live events: non-technical stakeholders are engaged too late, then asked to act instantly.
Common gaps this exercise tends to expose
In practice, ransomware scenarios rooted in identity compromise reveal weaknesses beyond endpoint controls. One is overreliance on EDR while identity logging, SaaS audit data, and remote admin trails remain fragmented. Another is ambiguity around account disablement authority, especially for privileged users or executives. Teams also discover that “critical asset” lists are outdated, shared drive ownership is unclear, and restoration assumptions ignore the time needed to validate backups are not contaminated.
There is also a recurring intelligence gap. Many organizations track ransomware brands and IOCs but do not map intrusion behaviors to likely decision points. If the scenario includes evidence of living-off-the-land execution, MFA fatigue, or illicit OAuth grants, the team should be able to connect those details to known adversary tradecraft and adapt containment accordingly. That is where a threat-intelligence-informed tabletop is materially better than a generic one.
Metrics worth capturing
Do not reduce exercise outcomes to attendance and completion. Capture whether the team could define incident severity quickly, identify authoritative owners for containment actions, state evidence requirements for breach assessment, and articulate business impact in terms leadership can act on. Measure time to decision, not just time to answer.
It is also useful to record where assumptions broke. Did participants expect logs that were unavailable? Did they rely on an obsolete call tree? Did they assume legal review would take 30 minutes when it realistically takes several hours? Those are high-value findings because they map directly to engineering, process, and governance fixes.
How to make the exercise harder without making it unrealistic
If your team handles basic ransomware tabletops easily, add ambiguity rather than theatrics. For example, inject signs of possible exfiltration that cannot yet be confirmed, or introduce a second business-impacting event like a BEC attempt from the compromised tenant. Another effective complication is partial vendor dependency: the ERP provider confirms service instability but cannot yet say whether the issue is tenant-specific or broader platform abuse.
What you should avoid is stacking so many failures that the scenario becomes fiction. The point is to test response under credible pressure, not to produce a catastrophic movie plot.
Turning the example into a repeatable exercise
The best outcome is not a polished slide deck. It is a backlog of concrete improvements tied to owners and deadlines. If the exercise showed poor visibility into OAuth grants, create a logging and detection work item. If participants could not agree on when to isolate domain-connected assets, update the playbook and approval path. If finance could not explain which encrypted shares were business-critical, fix asset and data ownership.
This is where a media and research platform like Cyber Threat Intelligence can be useful to practitioners: not as a substitute for internal rehearsal, but as a way to keep scenario design aligned with current intrusion patterns rather than last year’s assumptions.
A tabletop is only valuable if it changes how the next incident unfolds. If your exercise ends with everyone agreeing the scenario was realistic but no one updates authority models, telemetry coverage, or communication thresholds, then the organization practiced discussion, not response. The strongest exercise leaves at least a few people slightly uncomfortable - because it showed them exactly where the real incident will get expensive.
Source: https://cyberthreatintelligence.net/incident-response-tabletop-exercise-example
