Incident Response Tabletop Exercise for an Online Casino: Scenarios, Roles, and What to Record

Q: What is an incident response tabletop exercise?

A tabletop exercise is a facilitated, discussion-based rehearsal of an incident. Participants talk through a realistic scenario step by step, decide what they would do, and say who they would call. No systems are touched. Its purpose is to find gaps in the plan, the roles and the decision rights before a real incident does.

Q: Who should attend a tabletop exercise at an online casino?

The people who would make decisions in a real incident: security, the engineering or platform lead, the payments or cashier owner, compliance or the licence holder's responsible person, legal, customer support, and communications. Anyone who can authorise taking the cashier or game servers offline must be present, because that decision is usually where the plan stalls.

Q: How often should we run a tabletop exercise?

There is no single correct interval. A common approach is to run one on a regular schedule and again after a significant change, such as a new payment provider, a platform migration, or a change in the on-call team. Check whether your licence conditions or regulator guidance set a minimum for your market.

Q: What is the difference between a tabletop exercise and a penetration test?

A penetration test attacks systems to find technical weaknesses. A tabletop exercise tests people and process: who decides, who is called, and what is written down. They answer different questions, and a scenario for a tabletop is often built from a finding in a pentest.

Q: Can an incident response retainer provider run the exercise?

Often yes, and it is a common way to use proactive hours in a retainer. An outside facilitator also tends to be more willing to challenge the plan than a colleague is. Confirm in the retainer whether exercises draw from the same hour pool.

The short answer

An incident response tabletop exercise for an online casino is a facilitated, discussion-only rehearsal of one realistic incident, run with the people who would actually have to make the decisions. It is worth doing when it surfaces gaps you can fix: who can take the cashier offline, who talks to the licensing authority, where the evidence is kept. Pick one scenario that touches player funds, run it for a fixed time, and write down every point where someone said "I'm not sure who decides that".

Who this is for

This is for the Head of Security, CISO, or compliance lead at an online casino or sportsbook who has an incident response plan on paper and has never walked the operations team through it. It also fits teams that have just signed an incident response retainer and want a first proactive use of it. If you have no written plan yet, write a one-page version first. A tabletop exercise needs something to test.

What a tabletop exercise is, and what it is not

A tabletop exercise is a conversation with a script. A facilitator reads out a scenario in stages, the participants say what they would do at each stage, and a note-taker records decisions, delays, and disagreements. Nobody logs into a production system.

It is not a penetration test, and it is not a technical drill. It does not prove your detections fire or your backups restore. It tests the human layer around them: whether the right person is reachable, whether the decision rights are written down, and whether the plan survives contact with a realistic, messy situation. Public guidance such as NIST SP 800-84, which covers test, training, and exercise programmes for IT plans, and CISA's tabletop exercise packages treat discussion-based exercises as a distinct, lower-cost stage of an exercise programme, ahead of functional and full-scale exercises.

Choose a scenario that touches money

A casino's worst incidents are the ones where players or regulators notice. A scenario should therefore end up at the cashier, the wallet ledger, or player data, not stay inside the corporate network. Four that fit the sector:

Scenario	The decision it forces	Related depth
Ransomware on the platform and back-office	Whether to take the casino offline, and who is allowed to decide	Ransomware response: the first hours
Mass account takeover after a credential dump	When to force resets and freeze withdrawals	Account takeover detection checklist
Cashier or payment-provider compromise	When to suspend deposits and withdrawals, and who tells the payment provider	Cashier security testing
Helpdesk social-engineering of a privileged account	Who can revoke access at 3 a.m.	Identity hardening after the MGM help-desk breach

Run one scenario per session. A single scenario done properly produces more fixes than four done superficially. A DDoS during a major sporting event is a valid fifth, but its response is mostly a provider conversation; test it against the DDoS readiness audit instead.

Who must be in the room

Invite by decision right, not by seniority:

Security lead: owns containment and the incident record.
Platform or engineering lead: knows what can be isolated and what breaks if it is.
Payments or cashier owner: can suspend deposits and withdrawals and knows the provider contacts.
Compliance or the licence holder's responsible person: knows which authority must be told, and how.
Legal and data protection: owns notification judgement, including the GDPR 72-hour window once personal data is involved.
Customer support and communications: owns what players are told while the cashier is down.
An outside facilitator: ideally someone who is not on the team being tested.

If the person who can authorise taking the platform offline cannot attend, reschedule. The most valuable question in the whole exercise is "who decides?", and an empty chair makes it unanswerable.

A 90-minute running order

Frame (10 min). State the rules: no blame, no real systems, decisions are recorded as stated.
Stage 1: first signal (20 min). Read the first alert or report. Ask who sees it, who is called, and who declares an incident.
Stage 2: it gets worse (25 min). Introduce a complication such as a second affected system, a player complaint on social media, or an unreachable on-call. Ask what is contained and what is not.
Stage 3: outside parties (25 min). Introduce the regulator, the payment provider, the press. Ask who speaks, what is said, and what evidence backs it.
Debrief (10 min). Each participant names the one gap they saw. The note-taker reads the list back.

Adjust the clock to your team. The structure matters more than the minutes: signal, escalation, outside parties, debrief.

What to record

The exercise only pays off if it produces a list. Capture these for every stage:

Record	Why
Decision made, and by whom	Shows whether decision rights are clear
Time the room took to decide	Reveals bottlenecks, not accuracy
"Not sure who" moments	These become plan edits
Contacts that could not be found	Out-of-date phone trees are the usual finding
Evidence the room said it would preserve, and where	Checks the plan against what a forensic timeline needs
Assumptions about tooling that nobody had verified	These become technical follow-ups

After the session, turn each gap into an owner and a date, and update the plan. A tabletop with no changed document afterwards was a meeting.

Limitations

A tabletop exercise tests intent, not capability. People often describe a response that the systems cannot actually support, which is why findings about tooling should feed a technical check afterwards, for example a penetration test of the path the scenario assumed, or a restore test of the backups it relied on. It is also a one-day snapshot; staff change and the plan ages. This article sets no required frequency, does not interpret any licensing authority's rules, and cites no statistics or AnySec-original numbers.

What to do next

Pick the scenario that ends at your cashier, book the decision-makers for a half day, and decide who facilitates. If you want an outside facilitator or want to use proactive retainer hours for the first exercise, see the Incident Response service page or request a fixed quote.

Frequently asked questions

What is an incident response tabletop exercise? A facilitated, discussion-based rehearsal of a realistic incident. Participants say what they would do at each stage; no systems are touched. It finds gaps in the plan, roles, and decision rights.

Who should attend a tabletop exercise at an online casino? Security, engineering, the payments owner, compliance, legal, support, and communications. Anyone who can authorise taking the cashier or platform offline must be there.

How often should we run a tabletop exercise? There is no single interval. Run one on a schedule and after significant changes such as a new payment provider or migration. Check whether your licence conditions set a minimum.

What is the difference between a tabletop exercise and a penetration test? A pentest attacks systems to find technical weaknesses. A tabletop tests people and process. A tabletop scenario is often built from a pentest finding.

Can an incident response retainer provider run the exercise? Often yes, as proactive work under the retainer. An outside facilitator is usually more willing to challenge the plan. Confirm whether exercises draw from the same hour pool.

Sources and review

Exercise structure draws on NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, and CISA's Tabletop Exercise Packages; check both for current wording. GDPR timing is as described in the linked retainer article. No AnySec-original numbers, case results, or SLA figures are used. Author: AnySec Engineering. Published 2026-10-16; last reviewed 2026-10-16.