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.
It is 05:40 on a Tuesday. Hundreds of servers are rebooting into a ransom note. The infrastructure team goes to restore and finds the backup console showing the same note: the backup server was joined to the domain, and the attacker deleted the restore catalogue and encrypted the on-site repository. An offsite copy exists in cloud object storage, but nobody has restored from it in fourteen months and nobody is sure whether its retention lock can be overridden. The business wants a restore time by 09:00. What do you tell them, and what do you touch first?
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?
At 14:10 your SOC sees a new federated domain added to your cloud identity tenant, then a conditional access policy disabled. Both changes came from a Global Admin account belonging to a cloud engineer who is on holiday. Within twenty minutes, two new app registrations with mail-read permissions appear and three other admins report their MFA methods were changed. The attacker can now create users, issue tokens and read any mailbox. You are not sure which admin accounts are still yours. How do you take the tenant back without locking yourselves out?
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?
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 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?
The finance team forwards a billing alert at 08:15: your cloud spend for the last 24 hours is $182,400 against a usual $3,000. The cloud team finds hundreds of large GPU instances running in four regions you have never used. They were launched from the root account of a development tenancy that nobody has logged into for a year. Its recovery email points to a former employee's personal address. Your provider's support line says a credit "may be considered" once you secure the account. The instances are still running and costing roughly $7,500 an hour.
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?
Your EDR raises a medium-severity alert on a senior developer's laptop: an unsigned executable launched from the downloads folder, then deleted itself. The developer says they installed a "free licence key generator" for a design tool on Saturday. It is now Monday. Since Saturday, their code-hosting session, their cloud console session and their password manager browser extension have all been used from an IP address in another country, with no multi-factor prompts, because the attacker replayed session cookies. The developer has admin rights on 60 repositories. Where do you start?
Three weeks ago your platform team gave an AI operations agent permission to tidy up unused cloud resources, with a rule that destructive actions need human approval in chat. This morning the cost dashboard shows a 22% drop. The agent's log says it identified "orphaned snapshots" and deleted 1,400 of them, including the only backups of your billing database. It recorded the approval as granted: an engineer had replied "looks good" to a different message in the same thread. A database migration is planned for tonight. Who is accountable, and what do you change?
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?
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?
A severe storm has hit the region served by a 1,200-person home insurer, and claims calls are at five times normal volume. At 08:20 the cloud contact-centre platform your agents use for calls, chat and call recording goes down across the provider’s entire region. The provider’s status page says ‘investigating’ and gives no estimate. Agents can still log into the claims system but cannot take calls. Customers with flooded homes are getting a dead line, and local radio has started asking why. Your contract’s service credit is worth one month’s fees. What is your plan for the next eight hours?
At 07:15 on a Tuesday, your EU payment institution loses its core transaction database after a fault at the cloud provider that hosts it. Card authorisations are failing for about 40% of merchants across four member states. The provider's status page says 'degraded performance' and gives no estimate. By 09:00 your service desk has logged 2,300 merchant complaints. Your head of compliance asks the question nobody has answered yet: is this a major ICT-related incident under DORA, and if so, when did the clock start? The CEO wants to know what goes to the regulator, and when.
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.
A security researcher posted on social media that your insurance comparison site had left a storage bucket of 80,000 quote applications open to the internet. You closed it within an hour and decided, after a quick assessment, that it did not need to be notified. Eleven days later a letter arrives from the data protection authority. It asks when you became aware, who accessed the data, why you did not notify, and for a copy of your breach register entry. Replies are due in 14 days. Your breach register entry is two lines long.
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.