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 security researcher emails your support address on a Friday afternoon. They have found a cloud storage bucket, publicly listable, that holds nightly CSV exports from your customer platform: names, email addresses, phone numbers and partial payment details for roughly 210,000 customers in the EU, UK and US. They attach a screenshot of the file list and say they will publish a write-up in seven days. Your cloud team confirms the bucket is yours and was made public eighteen months ago for a one-off analytics project. Access logging on it was never switched on.
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?
At 02:15 a help-desk agent reset MFA for a cloud administrator after a convincing phone call. By 03:00 the attacker had registered a new device, created an access key in your production cloud account and disabled two logging trails. By 05:30, 3 TB had left a storage bucket holding customer documents. Your SOC sees an impossible-travel alert at 07:50. The identity, cloud and data teams each hold part of the picture, and each believes someone else is containing it.