How to Run an Incident Response Tabletop Exercise

An incident response plan you have never tested may not work when you need it. A tabletop exercise is a low-cost way to find the gaps first.

NIST's guide to exercises, SP 800-84, describes a tabletop as a discussion. The people with roles in a plan meet, a facilitator walks them through a made-up incident, and they talk through what they would do. No systems are touched. NIST calls tabletops a cost-effective way to check that a plan's content works in a real emergency.

This guide is for a first exercise on a growing team. It skips the parts of NIST's process built for large organizations.

1. Pick one goal

Pick one question you want answered. One goal keeps a two-hour session focused. For example:

• Does everyone know who decides when to call in outside help?
• Can we reach the people we need, such as our cyber insurer, our lawyer, or a key vendor, outside business hours?
• Do we know who tells customers, and what they can say?
• Can we find the logs we would need to answer "what did they touch?"

Write the goal at the top of your notes. Everything else in the session serves it.

2. Write a short scenario

NIST's guide warns that long, detailed scenarios backfire. People spend the session picking apart the story, and the plan goes untested. Two or three sentences are enough to start.

Pick something that could happen to you this year. Some starting points for a small software company:

• A phishing email leads to a stolen login for an admin account.
• A cloud access key shows up in a public code repository.
• A laptop with customer data on it is lost at an airport.
• Files on a shared drive start getting encrypted.

If you want a ready-made package, CISA publishes Tabletop Exercise Packages with scenarios, objectives, and discussion questions. Its cybersecurity scenarios include ransomware, insider threats, and phishing.

3. Write three or four updates

The story moves forward in updates, sometimes called injects. Each one adds a fact and asks a question. Here is a sample for the stolen admin login.

Keep the questions open. "What do you do next?" teaches you more than "Would you disable the account?"

4. Invite the right people

Invite the people named in your plan. That usually means a decision maker, the engineer who knows the systems, and whoever talks to customers. Keep the group small enough that everyone speaks.

Name two roles before the day. NIST's guide calls them the facilitator and the data collector.

• The facilitator runs the session, reads the updates, and keeps the talk on the goal. Pick someone who will not also be the main person answering.
• The note-taker writes down decisions, open questions, and every "I don't know." Those notes become the report.

Send the invite with the date, the goal, and a link to the plan.

5. Run the session

Two hours is enough for a first exercise. NIST's guide says tabletops typically run two to eight hours, and small teams with one scenario can stay at the short end. A simple agenda:

1. Ten minutes: the goal, the ground rules, and who is in the room.
2. Five minutes: the scenario.
3. About an hour: the updates, one at a time, with discussion after each.
4. Twenty minutes: a debrief. What worked, what did not, and what surprised people.
5. Ten minutes: agree on the fixes and who owns each one.

Ground rules that help:

• No blame. The plan is what is under test.
• Use your real tools. If someone says "I'd check the logs," ask them to show where.
• When the room gets stuck on details of the story, the facilitator steers it back to the goal.

6. Write the after-action report

Write it within a week, while people remember. NIST's guide calls this an after-action report and builds it around criteria you set before the exercise. For a small team, one page is enough.

• The date, who attended, and the goal
• The scenario and the updates you used
• What worked
• What did not work, or what nobody knew
• Each fix, with an owner and a due date
• Changes to the plan itself

The NIST Cybersecurity Framework 2.0 has an outcome for this, ID.IM-02. It says improvements are identified from security tests and exercises. Your report is the record that you did that. NIST's incident response guide, SP 800-61 Rev. 3, organizes its advice around the same framework.

7. Fix, update the plan, and repeat

Treat the fixes like any other work. Put them in your ticket system with the owners and dates from the report. Update the plan the same week.

NIST's guide says to run tabletops periodically, and again after changes to the organization or to the plan. CISA's #StopRansomware Guide also says to regularly exercise your incident response plan, and CISA's Cybersecurity Performance Goals (goal 1.C) say incident response plans "should be reviewed and drilled, at a minimum, on an annual basis." So run one at least once a year, and again after a big change such as a new product, a new cloud provider, or a new person in a key role. Run them more often if you handle sensitive data, have had a recent incident, or a customer contract asks for it. Use a different scenario each time.

Where Grey Wing fits

In the Security Program, we help growing teams get an incident response plan and a first tabletop ready. Our own team does not run incident response. If you want help, Let’s talk.

Sources

• NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities: https://csrc.nist.gov/pubs/sp/800/84/final
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: https://csrc.nist.gov/pubs/sp/800/61/r3/final
• CISA, Tabletop Exercise Packages: https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
• CISA, #StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide
• CISA, Cross-Sector Cybersecurity Performance Goals 2.0, goal 1.C: https://www.cisa.gov/cybersecurity-performance-goals-2-0-cpg-2-0