Services / Resilience
Tabletop Exercises
Find out who decides to pay the ransom before the day you have to decide.
The problem
You have an incident response plan. Nobody has read it since it was written, half the people it names have changed roles, and no one knows who is allowed to take production offline or call a customer. The first time you find out is the worst possible time to find out.
The method.
Build a scenario from your own architecture
No generic scripts. The scenario uses your cloud provider, your actual SaaS estate, your real customer contracts and your real notification duties. Typical scenarios: ransomware in the production account, a compromised CI/CD token pushing to production, personal data exfiltration from a customer-facing database, or a critical supplier breach that reaches you through an integration.
Run it in injects, under time pressure
The scenario is delivered in stages (the alert, the escalation, the ransom note, the journalist's email, the regulator's clock), with decisions demanded within realistic windows. Participants get only what they would have at that moment, including ambiguity and incomplete telemetry.
Force the decisions people avoid
Who has authority to shut down production. Who talks to the customer, and when. Does the 72-hour GDPR clock start now or at confirmation. Do we notify the Israeli Privacy Protection Authority. Do we engage the insurer's panel before or after our own forensics. Do we pay. These are the decisions that stall a real incident for hours, and the exercise exists to surface them.
Observe against the plan, and note where the plan is ignored
We track what the plan says and what the room actually does. Where they diverge, the plan is usually wrong: unreachable contacts, missing authority, a communications tree that assumes an office nobody sits in, evidence-preservation steps nobody knows how to perform.
Convert findings into changes with owners
The output is not a compliment. It is a prioritised list: fix the on-call escalation path, pre-draft the customer notification, obtain the forensic retainer, put the break-glass credentials somewhere reachable when the IdP is the thing that is down. Each item gets an owner and a date, and is checked at the next exercise.
What is a cybersecurity tabletop exercise?
A tabletop exercise is a facilitated simulation of a security incident in which the technical and executive teams work through a realistic scenario in real time, making the decisions they would have to make during an actual event. It tests whether the incident response plan works in practice, and it produces an evidence record that ISO 27001, SOC 2 and cyber insurers all ask for.
How often should a company run a tabletop exercise?
At least annually, and after any significant change to the architecture, the executive team or the regulatory obligations. Companies with contractual incident-notification commitments, or those in scope for DORA or NIS2, generally run more than one per year and vary the scenario each time.
Who should participate in an incident response tabletop?
Everyone who would be in the room during a real incident: engineering and on-call, the executive who can authorise taking production offline, whoever owns customer communication, whoever owns regulatory notification, and, where relevant, external counsel and the insurer's contact. An exercise attended only by the security team tests only the part that usually works.