Simulations that change behavior, not just check boxes
Most tabletop exercises follow a predictable pattern: a slide deck, a synthetic scenario, and a room full of people nodding along. Then everyone goes back to work and little changes. This note is about designing tabletops that expose real friction, change how leadership and responders think, and directly improve readiness for cloud-era incidents.
The goal is not to pass the exercise. The goal is to discover how you would really behave when the stakes are high and information is incomplete.
What separates effective tabletops from theater
Good tabletops do three things: they reveal unknown dependencies, they clarify who makes which decisions under stress, and they generate a prioritized list of actions that leadership actually agrees to own.
Design for discovery, not performance
The goal is not to “win” the exercise. It’s to surface where people are uncertain, where processes don’t match reality, and where tools or contracts fall short.
Everyone’s time is scarce
If you are going to put executives, legal, IT, and security in a room together, the exercise must produce outcomes that justify the interruption. That means clear before/after insight.
A short list of owned changes
A tabletop that matters ends with a small set of concrete, named actions and clear owners; rather than a vague “lessons learned” document that nobody implements.
Why many tabletops fail to move the needle
A long, cinematic scenario is presented, but there are few real decision points. Participants are spectators, not operators. Nobody is forced to choose between options. The exercise assumes perfect logging, instant forensics, and unambiguous alerts. Real incidents don’t look like that, especially in M365, Workspace, and SaaS-heavy stacks. In real incidents, not deciding is itself a decision. In many tabletops, time pressures and external impacts aren’t modeled, so “waiting to see” feels free.
Principles for tabletops that matter
Base scenarios on actual attacker behavior in your sector and tech stack: M365 BEC, OAuth abuse, vendor compromise, internal misuse, or cloud credential theft. Avoid generic “virus” stories. At key points, stop and ask: who owns this decision? What options are on the table? What information do they wish they had? Capture the uncertainty as data. Model things like vendor delays, incomplete logs, conflicting goals, or regulatory reporting clocks. These constraints are often more interesting than the “attack” itself.
Example scenarios for cloud-era incidents
“No malware, but your M365 tenant is compromised”
- Initial signal: suspicious sign-ins + mailbox rule changes.
- Progression: OAuth app consent, data exfil, and persistence in SharePoint/OneDrive.
- Decision pressure: when do you notify customers, regulators, or partners?
“Your critical SaaS vendor is breached”
- Initial signal: external notification from vendor and media coverage.
- Questions: what data did they hold, what contracts say, what compensating controls exist.
- Decision pressure: continue operations, partial shutdown, or rapid migration?
“Privileged insider misusing access”
- Initial signal: anomalous access or export patterns from a trusted account.
- Constraints: HR and legal involvement, privacy laws, internal politics.
- Decision pressure: monitoring vs immediate access removal vs termination.
How to run the session so it drives change
1. Set expectations clearly
Begin by stating that the goal is learning, not grading. Make it safe to say “I don’t know” or “we don’t have that.” Emphasize that discovering gaps is success.
2. Keep the group small but representative
Include security, IT, legal, communications, and at least one business leader with real decision authority. Avoid overloading the room with observers.
3. Capture friction in real time
Assign someone to log every point where the group is blocked: unknown contacts, missing runbooks, unclear approvals, or tool limitations.
4. Debrief with a bias toward action
End with three lists: what worked, what was harder than expected, and what needs to change. Then pick a small number of high-impact items to actually execute this quarter.
What you should walk away with
Refined roles & responsibilities
Clearer understanding of who makes which decisions, what authority they have, and how to reach them quickly when something breaks.
Updated playbooks
IR procedures that reflect cloud and SaaS reality, not just on-prem ransomware or endpoint malware assumptions.
Detection & logging gaps
A list of signals, audit logs, or integrations you wish you had during the exercise and which can directly feed your detection engineering roadmap.
Leadership-level talking points
Plain-language insights you can share with the board or executive committee about where resilience is strong, and where investment is needed.
