Running a one-hour incident tabletop
Most incident plans are written once, approved, and never tested. They are usually correct and almost always unusable, because the gap between a document and a decision under pressure is not something a document can close.
The decisions that go wrong in a real incident are rarely technical, so the room needs more than the IT team.
Start the scenario ambiguous and let it get worse, because a scenario that hands you the diagnosis skips the part people are worst at.
The exercise is worthless without the write-up: every gap, an owner, a date.
Who needs to be in the room
A tabletop exercise closes it cheaply. You put the people who would actually decide in a room, describe a situation, and ask them what they do. No systems are touched. No technology is required. It takes an hour, and it reliably finds problems that no amount of re-reading the plan would have surfaced.
The instinct is to run this with the IT team. That produces a technically interesting hour and misses the point, because the decisions that go wrong in a real incident are rarely technical.
Invite the person who can authorise spending money at midnight. The person who talks to customers. The person who talks to staff. Whoever owns the legal and regulatory obligations. And the technical lead. Five or six people is right; more than eight and it becomes a presentation.
If somebody cannot attend, that is itself a finding. Note who was missing and whether the exercise could still proceed without them.
Building a scenario that works
A good scenario has three properties: it is plausible for your organisation, it starts with ambiguity rather than certainty, and it gets worse.
Start ambiguous. Not "you have been hit by ransomware" but "at 07:40 a branch reports that files on the shared drive will not open, and the file names look wrong". The first ten minutes of a real incident are about establishing what is happening, and a scenario that hands you the diagnosis skips the part people are worst at.
Then introduce complications on a timer. Fifteen minutes in, a second location reports the same thing. Thirty minutes in, a customer emails asking why an invoice from your domain looks strange. Forty-five minutes in, someone finds a ransom note and a deadline.
Pick a scenario that matches your actual exposure. For a retailer, tills failing on a Saturday. For a healthcare organisation, shared workstations locking during clinic hours. For a logistics business, the warehouse system failing mid-shift. Generic scenarios produce generic answers.
Running the hour
Keep it simple. One facilitator reads the situation and the injects. Everyone else responds as themselves, in their real role. The facilitator's only job is to keep asking two questions: who decides that? and how do you actually do that right now?
The second question is where the value is. "We would isolate the affected segment" is an intention. "Who has the credentials, is that person reachable, and does it work from home?" is the test.
Somebody takes notes, focused on gaps rather than narrative. Do not stop to solve problems during the hour. Note them and move on, or you will spend the whole session on the first one.
The questions that consistently find gaps
Across most organisations, the same handful of questions expose the same weaknesses:
- Who is in charge? Not the org chart. Who makes the call during this incident, and who does it if they are unreachable?
- How do you communicate? If the assumption is that email and chat may be compromised or unavailable, what is the alternative, and does everyone have it saved somewhere that does not depend on the network?
- Do you have the phone numbers? Insurer, legal counsel, your IT partner, the regulator. On paper, not only in a system that may be encrypted.
- What do you tell staff? Within the first hour, people will be posting about it internally and possibly externally. Silence is a decision with consequences.
- When does the clock start? Notification obligations run from discovery. Who determines that discovery has happened, and is it written down?
- Can you actually restore? Not "do we have backups". When was the last restore test, what was restored, and how long did it take?
What to do afterwards
The exercise is worthless without this part. Within a week, write up:
- Every gap found, in one line each
- An owner for each gap
- A target date
Nothing more elaborate. A short list with names and dates gets acted on; a twelve-page report does not.
Then update the plan to match what you learned, and note the date of the exercise on it. The next time a customer or an auditor asks how you test your incident response, you have a specific answer.
Cadence
Once a year is the realistic minimum, and it is enough for most organisations. Twice is better if your environment or your team changes significantly. Vary the scenario each time, and occasionally run one where the obvious decision-maker is deliberately unavailable, because that is the version that tests whether the fallback is real.
The measure of a good tabletop is not that it went smoothly. It is that it produced a list. If your first one produces a long list, that is not a failure of the exercise. It is the reason to have run it.
Questions we get about this
The ones that come up most often once this is on the table.
How much preparation does the facilitator need?
An hour to write the scenario and the injects, no more. The value sits in the questions asked during the session, not in the polish of the material. One page is enough.
Should we bring in someone external to run it?
For a first exercise an internal facilitator is fine and keeps the barrier low. External facilitation earns its cost when you want leadership tested honestly, or when the internal facilitator would be one of the people under scrutiny.
What if it goes badly and people feel exposed?
Say at the start that the exercise tests the process and not the people, and mean it. A tabletop where nobody admits they do not know something has told you nothing. The long list is the deliverable.
How is this different from a disaster recovery test?
A DR test proves the technology can be restored. A tabletop tests whether people can decide under pressure with incomplete information. Both matter, and passing one tells you nothing about the other.
Where this sits with us
The services this subject falls under.
Who decides in the first hour at your organisation?
We facilitate one session with your own scenario and the people who would really be in the room. One hour, followed by a short written gap list with owners against each line.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.