100 ready-to-run cyber tabletop exercises across 15 incident domains. Search them, pick one at random, or tell us who will be in the room and we'll rank the scenarios that fit those people best. Every exercise shows who to involve, how long it runs and an outline — and the scenario prompt is free to copy and read out.
Running one for real? Pro adds the facilitator's run sheet for each exercise: a minute-by-minute timeline, timed injects, step-by-step facilitation guide and the questions to put to each person. Or build your own with the Tabletop Runbook Generator.
Who's in the room?
Pick the people you have — we'll suggest exercises that fit them.
A senior account executive resigned on Friday and joins a direct competitor in two weeks. On Monday, a data loss alert shows she synced 4,000 files to a personal cloud account over the weekend, including a full CRM export, pricing models and the customer contract folder. She is on garden leave but still has a working laptop and VPN access. Her manager insists she is trustworthy and that this is 'just her portfolio'. Legal wants to act before anything reaches the competitor. What do you do, and in what order?
It is 10:40 on a Tuesday. A secret-scanning service emails your security inbox: a long-lived access key for your production deployment account was pushed to a public code repository 47 minutes ago, from a contractor's personal fork. The key has administrator rights. Your cloud audit log shows calls made with that key in the last ten minutes from an address nobody recognises, and the release pipeline uses the same key for tonight's deploy. The contractor is not answering their phone. What do you do in the next fifteen minutes?
Your platform team moved CI to keyless federated identity last quarter: pipelines exchange a signed token for a short-lived cloud deploy role. Tonight the SOC sees that role assumed 31 times in two hours. The token claims name a repository under an organisation you have never heard of. The trust policy, it turns out, checks the identity provider but not which organisation the token comes from. Using the role, someone has created two new identities, read your secrets store and changed a load balancer rule in production. Nothing has failed yet. Where do you cut, and what do you trust after?
Your team has spent six hours on an active intrusion in production: an attacker with a stolen engineer session is moving between services, and you are close to cutting them off. At 16:05 your cloud provider posts a major incident for your primary region. Half your services are unreachable, including the logging pipeline and the identity console you were using to contain the attacker. Customers are calling. Your disaster-recovery runbook says to fail over to the secondary region, which is built from the same templates and secrets the attacker may have already read. Do you fail over?
A public advisory says a popular open-source logging package was hijacked: version 4.8.2, published three days ago, runs a post-install script that reads environment variables and sends them to a remote server. Your dependency manifests allow minor updates. A quick search shows 14 of your repositories pulled 4.8.2, and your CI runners, which hold cloud deploy credentials, package registry tokens and a signing key in their environment, built every one of them, many times. Two developers also installed it on their laptops. What do you assume was taken?
A message arrives at your CEO's and general counsel's inboxes: "We have 380 GB of your source code, including your payment service and your infrastructure scripts. Sample attached. Pay 40 BTC in five days or we publish everything and send it to your competitors." The sample is real: three repositories, including commit history and a configuration file with what look like live database credentials. Your code host shows a personal access token belonging to a senior engineer cloned 212 repositories eleven days ago from an unfamiliar country. The board meets in two days.
Forty of your engineers use AI coding assistants connected to a community-built Model Context Protocol server that adds database and ticketing tools. A researcher's blog post says version 2.3 of that server added hidden instructions in its tool descriptions that tell the assistant to read local environment files and include them in a "telemetry" call. The update arrived automatically two weeks ago. Your engineers' laptops hold cloud credentials, database passwords and customer test data. Your egress logs show the telemetry domain was contacted 9,200 times. What do you assume, and what do you change?
Your new data-loss prevention pilot produces its first weekly report. In seven days, staff pasted content into a free public AI chatbot 1,840 times. The sample includes a production database connection string, a customer contract with pricing, two HR investigation notes and a spreadsheet of patient appointment details. Your acceptable-use policy says nothing about AI. The approved enterprise AI tool, bought six months ago, has 30 active users out of 1,200. A department head replies to your email: "Everyone uses it. Banning it will just push people to their phones."
A senior engineer at a 250-person fintech hands in her notice on Friday, saying she is joining a competitor. On Monday a routine review of source-control audit logs shows her account cloned 140 repositories in the ten days before she resigned, including the fraud-scoring models she never worked on. Her work laptop also synced to a personal cloud drive twice last week. She is still working her notice period, has production access, and is well liked. HR wants to handle it quietly. Legal wants evidence first. What happens today?