Run a two-hour incident response tabletop this week

A tabletop exercise needs a room, a scenario, two hours and someone who will write down what goes wrong. You do not need a vendor, a budget or a finished incident response plan. The point is to find out, while nothing is burning, who actually decides to pull a server off the network and where the phone numbers are kept.

Pick one scenario and the right people

Choose a single scenario. Ransomware on a file server and account takeover of a finance mailbox are the two most useful for a small team, because both force decisions about isolation, communication and recovery. Do not try to cover both in one session.

You do not have to write the scenario from scratch. The NCSC's Exercise in a Box is free, includes tabletop exercises covering topics such as ransomware and phishing, and provides material to set up, plan, deliver and identify post-exercise actions. CISA's Tabletop Exercise Packages offer template objectives, discussion questions, a feedback form and an After Action Report, including ransomware and local government scenarios. Use them as scaffolding and adapt the details to your own systems.

Invite the people who would really be on the call:

• whoever administers the directory and backups
• the person who can approve downtime (a manager, not just IT)
• someone who handles external communication, even if that is the office manager
• one facilitator who does not play and does not answer questions

The facilitator matters. If the same person runs the scenario and defends their own setup, the exercise becomes a demo.

The two-hour agenda

Set one rule at the start: answers must be what you would really do with the access and tools you have today, not what the policy says. If someone says "we would check the logs", the facilitator asks which logs, where, and who has access at 07:40 on a Monday.

Injects for the ransomware version

Feed the scenario in steps rather than all at once. A workable sequence:

1. A user reports that documents on a shared drive have changed extension and a text file with a ransom note sits in each folder.
2. Two more users report the same. The file server is slow.
3. The backup console shows the last job finished, but the backup server is joined to the domain.
4. The attacker's note threatens to publish data in 72 hours.
5. Email is down because the mail connector runs on an affected host.

Each step has a question. Who can isolate the host, and do they need approval? Are backups reachable with the same admin credentials the attacker may hold? Where is the contact list if the directory and email are unavailable? Who decides whether to involve police or a regulator, and who contacts your insurer?

Injects for the account-takeover version

Start with a finance user reporting repeated MFA prompts they did not trigger. Then add a sign-in from an unfamiliar country, followed by a discovery of an inbox rule forwarding mail to an external address, and finally an invoice with changed bank details sent to a customer. Ask how you revoke sessions and tokens, not only reset the password. Ask how far back your sign-in logs go, and who checks the mailbox for rules and delegated access. If you want a quick check of whether staff credentials already appear in public breaches, our breached password checker is a reasonable pre-exercise step.

Capture gaps while they are fresh

The scribe keeps a plain log. Do not tidy it during the session. A line looks like this:

Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high

Every gap needs an owner and a date, or it is a wish. Rank them by what would have stopped you working, not by how embarrassing they were. Typical findings are mundane: nobody knew the registrar login, the on-call number was out of date, the person with authority to shut down production was on leave and had no deputy.

Ask the participants for written feedback before they leave. CISA's package includes a feedback form template and an After Action Report, which saves you designing either.

Turn the log into a runbook

Within a week, convert the log into a short runbook. One to two pages per scenario is enough. A runbook nobody reads during an incident is worse than none.

Include:

• The first hour: numbered actions, each with a named role rather than a person's name.
• Decision rights: who may isolate systems, who may approve paying for external help, who speaks to customers.
• Contacts: printed or stored offline, covering staff, suppliers, your ISP, insurer and external responders.
• Evidence handling: what not to wipe or reboot before someone has taken images and logs.
• Recovery order: which systems come back first and what proves they are clean.

For wider structure, NIST's Computer Security Incident Handling Guide, SP 800-61 Rev. 2, is widely referenced, but NIST withdrew it on 3 April 2025 and superseded it with Rev. 3, so use the current revision as your reference. If you want an outside view of the runbook or help running the session, see our incident response and consulting services.

Then schedule the repeat. Run the other scenario in three to six months, and re-test the fixes from the first gap log.

Where to start

1. Book two hours this week and block the calendars of the four or five people who would be on the call.
2. Download a ransomware or phishing scenario from Exercise in a Box or a CISA package and edit it to match your real systems.
3. Name a facilitator who will not play, and a scribe who will keep the gap log.
4. Run the session with the real tools open: backup console, directory, sign-in logs, contact list.
5. Assign an owner and a date to every gap before the room empties.
6. Write the one-page runbook within seven days and put a copy somewhere that works when your network does not.