Most organisations we assess have an incident response plan. It sits in a document management system, it was written for an ISO certification or a customer questionnaire, and it names people who may or may not still work there. When we ask when it was last run, the answer is usually a version history, not a date.
Then an incident happens, and the first hour looks nothing like the document.
The plan says: convene the incident response team, assess severity, follow the communication matrix. The first hour actually contains questions like these. Who has the authority to take the finance system offline during month-end? The plan's contact for the hosting provider left last year, so who has the account details now? Legal wants everything preserved and operations wants everything restored, and both are talking to the same engineer. Is the attacker reading this email thread?
None of these are exotic. They come up in almost every real incident, and none of them are answerable from a document under pressure. They are answerable by people who have faced them before, even in rehearsal.
A tabletop exercise is a structured walkthrough of a realistic scenario with the people who would actually respond: IT, leadership, legal, communications, and whoever owns the customer relationships. Not a presentation. A scenario that unfolds in stages, with injects that force decisions.
The scenarios worth running are the uncomfortable ones. Ransomware detected on a Friday night with backups of unknown integrity. A business email compromise discovered after the payment went out. A vendor breach where your data is affected but your systems are not. Each one exercises a different seam in the organisation, and the seams are where responses fail.
Two rules make the exercise honest. First, decisions have to be made in the room, by the person who would really make them, out loud. "We would consult legal" is not a decision. Second, someone writes down every question the team could not answer, because that list is the actual output. It converts directly into fixes: an updated contact list, a pre-agreed authority to isolate systems, a break-glass communication channel that does not run through the possibly-compromised tenant.
Evidence preservation is the discipline that separates a managed incident from an expensive one. The instinct in the first hour is to switch things off and rebuild. Done wrong, that destroys the forensic record your insurer, your regulator and possibly a court will later ask for. Rehearsal is where people learn that isolation and preservation come before eradication, so the lesson does not arrive during the real thing.
The out-of-band channel is the other one. If your tenant is compromised, your incident coordination cannot run on it. Deciding in advance where the response team meets when email and Teams are off the table takes ten minutes in a tabletop and is close to impossible to improvise at 11pm.
Once a year is the floor, twice is better, and after any significant change to systems or people the plan needs another run. The exercise takes half a day. Set against the cost of a mishandled incident, which routinely runs into weeks of disruption before the direct costs are counted, it is the cheapest security control most organisations are not using.
An incident response plan that has never been rehearsed is a document. The rehearsal is what makes it a capability.
Ben Jones leads penetration testing, red team and incident response at Coder Trove. Our cyber security practice runs readiness exercises, incident response and CISO-led governance.