Incident Response

Run the Tabletop Before the Incident: What Three Hours Reveals

Every incident response plan looks adequate until you walk a real scenario through it with the actual people. The gaps are never where the plan says they are.

Team working through an incident response exercise

A tabletop exercise is a structured conversation: a scenario, the people who would actually handle it, and someone asking "so what do you do now?" at each stage. It takes about three hours and consistently finds more than a penetration test about how your organisation would really perform.

Who needs to be in the room

The common failure is treating this as a technical exercise. Ransomware is a business crisis with a technical cause. You need IT and security, yes — but also legal, communications, finance, HR, operations, and someone who can authorise spending without a procurement cycle.

If an executive cannot attend, that itself is a finding. The scenario will require decisions only they can make.

What consistently surfaces

Nobody knows who decides

Take systems offline and halt the business, or stay up and risk spread? Pay a ransom or refuse? These are not IT decisions, and in most organisations it emerges mid-exercise that no one has been formally given the authority to make them.

The contact list is stale

Phone numbers for people who left. A cyber insurance policy nobody has read. No out-of-hours number for the managed service provider who holds the backups. And the list itself stored on the file share the scenario just encrypted.

Nobody has tested the restore

"We have backups" is reliably where confidence collapses. Backups exist; restores have never been attempted end to end; nobody knows how long a full restore takes; and it is often discovered that the backup system uses the same credentials as everything else — so the attacker reaches it too.

The communications plan does not exist

Who tells staff? What do you say to customers before you know the facts? Who speaks to regulators, and within what deadline under the Data Protection Act? Silence in the first hours is filled by rumour, and rumour is harder to correct than an early honest statement.

Running one well

  • Pick a plausible scenario. Ransomware encrypting file servers on a Friday evening beats an exotic nation-state scenario nobody believes.
  • Inject new information in stages. Reality arrives incrementally and often wrong. Reveal that data was exfiltrated an hour in.
  • Ban the phrase "we would just". Ask who, with what access, using which runbook, at what hour.
  • No blame. The value comes from people admitting what they do not know. A punitive exercise produces a performance instead.
  • Write actions with owners and dates. A tabletop that generates a list nobody owns has changed nothing.

Then do it again

Once a year at minimum, and after any significant change to your systems or your people. The second exercise is always better than the first, which is the entire point.