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 day five after ransomware hit a 1,400-person insurance broker. Identity has been rebuilt and the attacker appears to be out. The infrastructure team can restore about twelve systems a day. Twenty-three business owners have each told the CEO their system is the most critical: claims, policy administration, finance, the broker portal, email archives. Two large clients threaten to move their accounts if the portal is not back by Monday. Yesterday a restored file server was found to contain the attacker's remote access tool and had to be taken down again. Who decides what comes back next, and on what basis?
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?
At 22:47 a payables clerk receives 31 MFA push requests in eight minutes. On the 32nd, half asleep, she taps Approve. By the time she reports it next morning, the account has signed in from a hosting provider, registered a new MFA device and created an inbox rule that moves any email containing 'invoice' or 'payment' to an obscure folder. Two supplier payment runs are scheduled for 11:00 today. Your SOC saw the overnight push alert and closed it as user error. What do you do before 11:00?
The head of sales operations clicked a link to a shared proposal on Monday and signed in as usual, MFA and all. This morning your identity logs show her session in use from a hosting provider while she is also active from the office, with no new sign-in and no MFA prompt. Overnight the session read 900 emails, downloaded the pricing folder, exported contacts from the CRM through single sign-on and consented to a new mail app. The help desk reset her password an hour ago. The activity has not stopped. Why not, and what do you revoke?
On Tuesday afternoon, a caller claiming to be a regional sales director phones the IT help desk from a number that is not on file. He sounds stressed, says he has a new phone and is about to present to a major customer, and knows his employee ID and his manager's name. The agent resets his MFA and sends a temporary password. Ninety minutes later the real director, sitting in your office, gets a sign-in alert. Since then the account has opened the CRM and the shared drive for an acquisition project. What now, and how did this get through?
Your incident response firm believes the attacker who compromised your identity provider can still get back in, but cannot yet prove how. Their recommendation: take single sign-on offline for all 3,000 staff for up to 24 hours from 18:00 tonight while they rebuild trust. That means no email, no CRM, no payroll system, no ticketing and no remote access. Sales has a quarter-end close in two days. Customers know nothing yet. The CEO wants a decision from the room by 17:00. What do you decide, and what are you accepting by deciding it?
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?
It is Sunday morning at a regional bank with 600,000 retail customers. Fraud operations reports 1,400 instant payments in 18 hours from customer accounts to newly added payees, most just under the daily limit, about $3.1 million in total. Every payment passed one-time-passcode checks. Social media is filling with customers whose balances are zero, and the call-centre queue is 90 minutes. The digital banking team suspects SIM swaps or a phishing kit; nobody has confirmed either. Turning off instant payments to new payees stops the fraud, and it also stops legitimate rent and wage payments. Do you pull the switch?
Friday, 18:20. A correspondent bank calls your payments operations desk about three outbound cross-border transfers sent in the last two hours: $4.2 million, $6.8 million and $9.5 million, to beneficiaries in three countries you rarely deal with. The messages were authenticated through your own payment messaging gateway using two valid operator accounts, one belonging to someone on leave. The daily reconciliation that would have caught them runs at 22:00, and today's printed confirmation report shows nothing unusual. Some of the funds may already have been credited. Who calls whom first, and what do you switch off?
Customer support at your 300-store grocery and pharmacy chain has logged 900 complaints in two days: loyalty points gone, redeemed for gift cards online and at self-checkout. Login traffic to the loyalty app is twelve times normal, mostly from residential proxy addresses, with a success rate of about 2%. That is roughly 18,000 accounts accessed. Points are not money in your accounts, but customers treat them as money, and the accounts also hold home addresses and pharmacy pickup history. Marketing launches a double-points promotion on Monday. What do you do 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.