Englishالعربية Soon
Under attack?
Tabletop exercises · Incident readiness

The worst time to read your incident response plan is during an incident.

A facilitated, discussion-based exercise that walks your people through a realistic attack scenario in a room, with no systems touched and nothing at risk, and finds the decisions nobody has actually made yet.

2 to 4 hrs
Typical duration
No systems
Discussion only, zero risk
Exec or technical
Or both, run separately
Written after
Findings and action plan
A scenario, hour by hour

Six injects, and the question each one is really asking

An abbreviated ransomware scenario. Each inject is released to the room in turn, and the discussion it forces is the deliverable, not whether anyone gets the answer right.

09:00

The first signal

A helpdesk ticket reports three finance staff locked out of a shared drive. Nothing has been declared. Who decides this is worth escalating, and how long does that take?

Detection & escalation
09:40

Declaration

Endpoint alerts confirm encryption is spreading. Someone must formally declare an incident. Who has that authority, and who do they call if that person is on a plane?

Command & authority
10:15

The containment decision

Isolating the affected segment stops the spread and stops the business. That decision costs money either way. Who owns it, security, IT, or the COO?

Business trade-off
11:00

The external call

A journalist has heard something. Separately, your regulator’s clock has started. What can be said, by whom, and who approves the wording?

Communications & regulatory
13:30

The ransom note

Data was taken as well as encrypted. There is a payment demand and a deadline. What is your position, who decides it, and has anyone spoken to your insurer or counsel?

Extortion & legal
16:00

Recovery

Backups exist. Nobody has verified a restore of this system in fourteen months. What order do you bring things back in, and who signs off that it is safe to?

Recovery & assurance
Audience

Three rooms, because they fail in different ways

Running one exercise for everyone produces a polite meeting. Running them separately, then together, produces findings.

Executive

Board, CEO, CFO, COO, general counsel and communications

Decision authority, risk appetite, regulatory disclosure, ransom position, public statements and the point at which the business stops trading normally.

Technical

SOC, IT operations, network, infrastructure and application owners

Detection, triage, containment sequencing, evidence preservation, tooling gaps and who actually has the credentials at 3am.

Combined

Both groups in one room, run after each has done its own

The handoff between them: which is where almost every real incident loses its first four hours.

Scenarios

Built from what actually threatens you

The scenario is written against your sector, your architecture and your regulator, using current adversary behaviour rather than a generic template. Nobody rehearses well for an attack they do not believe in.

Ransomware with data theft and extortion
Business email compromise and fraudulent payment
Insider exfiltration by a departing employee
Third-party or supplier compromise
Cloud tenant or identity provider takeover
Destructive attack against core banking or ERP
Public data leak discovered by a journalist
Regulator notification under a statutory deadline
Loss of a critical managed service provider
What comes out of them

Six findings we raise in almost every first exercise

None of these are technology problems, which is exactly why no tool would have surfaced them.

Nobody could name who declares an incident

Authority is assumed rather than assigned, so the first hour is spent finding a decision-maker.

The plan referenced people who had left

Contact lists age faster than plans do, and nobody owns keeping them current.

No agreed position on paying a ransom

A decision made under duress at midnight is not a decision, it is a reaction.

Legal and communications were not in the room

They get involved late, and then everything already said has to be walked back.

Restore had never been tested at scale

Backups existed. The recovery time nobody had measured turned out to be days.

The technical team never escalated upward

They believed they could contain it, and leadership learned about it from outside.

How it runs

Six steps, and the two that matter most are not on the day

A tabletop is easy to run badly: pick a generic scenario, hold a pleasant discussion, write nothing down. The design beforehand and the actions afterwards are what make it worth the room’s time.

Before
Scoping
We agree the audience, the objectives, the scenario and the constraints with a small planning group, and read your incident response plan so the exercise tests what you actually wrote down.
Before
Scenario design
Injects written against your environment, your regulator and current adversary tradecraft, sequenced so pressure builds the way it does in a real event.
On the day
Facilitation
Two to four hours in a room. Injects released in turn, discussion facilitated rather than lectured, and an observer recording decisions, delays and unanswered questions.
On the day
Hot debrief
Immediate feedback while it is fresh, covering what went well and what the room discovered about itself.
After
Report
A written report with findings, gaps in the plan, decisions that had no owner, and a corrective action list with names and dates.
After
Re-run
Most clients repeat annually with a new scenario, or twice yearly under a retainer. The second exercise is where you find out whether the actions were real.
Related

Readiness work that surrounds it

Incident response retainer

Retainer clients get two exercises a year, and the responder in the room is the one who would take the call.

Red teaming

A tabletop tests the decisions. A red team tests whether anyone would notice in the first place.

Root cause analysis

After a real incident, the same discipline applied to why it was possible.

Four hours now, or four days later.

Start with one executive session. It is the cheapest thing on this website and it consistently finds the most.