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.
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?
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?