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 messages your support inbox with a link. On a criminal forum, someone is selling what they call your full customer database: 1.2 million rows with names, emails, password hashes and the last four digits of cards, for $8,000. The 20-row sample contains real customers, and one is a member of your own staff. Nothing in your logs points to a breach. An engineer remembers a copy of production restored onto a test server for a migration two years ago. The researcher plans to publish a blog post on Friday. Where do you start?
An HR coordinator meant to email a salary review spreadsheet to the payroll provider. Autocomplete picked a similar name at a recruitment agency instead. The file holds names, salaries, home addresses and sickness absence notes for 340 employees. An hour later the recipient replied: 'I think this was meant for someone else.' The coordinator is panicking and has asked a friend in IT to 'just recall it'. It is now 16:30 on a Thursday. What happens next, and who needs to know?
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.
On Tuesday morning a post on a hacking forum claims to offer the ‘full database of a national pet-insurance company, 4 million customers’ and shares a 200-row sample. Within two hours it is on social media, a tech news site asks for comment, and your share price falls 6% at the open. Your security team checks the sample: the rows are real customers, but the fields match an old marketing list a former partner held, not your systems. Your logs show no intrusion so far. Customers are calling to cancel. How sure do you need to be before you say ‘we were not breached’?
A federal research sponsor's security office calls your university: data from a funded propulsion project has appeared on a foreign technical forum, including test results that were only ever stored on a lab's shared drive and one researcher's cloud storage account. Central IT has never managed that lab's servers. A postdoc's account shows logins from two countries within the same hour, repeatedly, over six months. The principal investigator says the lab follows every rule. Some of the data may be export-controlled, and the contract has a 72-hour cyber-incident reporting clause. When did that clock start?
Your company is six weeks from signing an agreement to buy a 300-person payments start-up. During security due diligence your team finds credentials for the target's production cloud account for sale on a criminal marketplace, dated four months ago. The founders say they had 'a minor incident' that was handled and that no notifications were needed. Their logs only go back 30 days. The deal team wants a recommendation this week: walk away, reprice, add protections in the agreement, or demand an independent investigation first.
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.