"Cybersecurity Tabletop Exercise: Decision Scorecard and Follow-Through Plan"

A tabletop exercise validates your incident response plan on paper, and it turns into theater when the company treats that discussion as proof. It changes how a team responds when someone records who decided what and how fast, the scenario carries your own costs and legal clocks, and every finding becomes a fix with an owner and a date that the next exercise checks.

This guide is for the security lead, IT director or vCISO who owns the incident response (IR) plan and has to run this year's exercise, often because an auditor, an insurer or the board asked for one. It gives you a session design, three forms to fill in here and a follow-up loop. If you do not yet have a plan, start with [LINK: ir-plan].

Why do tabletops turn into theater?

A tabletop is a discussion, so it cannot show that a capability works. NIST SP 800-84 says a tabletop is "discussion-based only and does not involve deploying equipment or other resources" and keeps "tests", measured with quantifiable metrics, as a separate type of event. Theater starts when the room confuses the two.

Validating the plan is still the job: NIST says a tabletop's objectives are to validate the plan's content, the roles it documents and its interdependencies. Exercises fail at that in three ways:

1. Talk is taken as proof. The plan says "restore from backup within 24 hours" and the room nods. Nobody restores anything.
2. Nobody records the decisions. People remember the mood, not who decided to isolate the network, on whose authority, or how fast.
3. Findings die in the slide deck. CISA's tip sheet says to "incorporate your lessons into the Incident Response Plan" after the exercise. Without an owner and a due date, the lesson stays in the deck.

The same tip sheet calls "No one is really in charge of that here" "a common observation, and one that might require action."

Is your company ready, or does it need a plan walkthrough first?

Run a tabletop when the plan exists and names people who can make the big calls. If it does not, do a plan walkthrough first: a working session where the owner reads the plan with the people it names and fixes gaps on the spot. This is our analysis. A tabletop on a plan with no named decision makers produces one finding, that there are none, and burns the executives' time.

Before you book calendars, the plan owner checks four things, each a few days' work:

• The plan names a person, by title, and a backup for each decision in the scorecard below.
• A management sponsor approves the exercise. NIST says it is important that managers are notified and their approval obtained when an exercise is being scheduled.
• Players know the plan. NIST says that if personnel have not been trained, the program coordinator should consider a training event first.
• You know your cost of downtime per hour for at least one system (the worksheet below).

Which cybersecurity tabletop exercise scenario should you run?

Pick the scenario that would hurt your company most and that your plan covers worst. Most companies should start with ransomware. Choose payment fraud if finance moves money on emailed or phoned instructions, and a vendor breach if one provider holds your data or runs your systems. This ranking is our analysis; no primary source we checked ranks these three.

Ransomware. It tests the widest set of decisions at once: isolating systems, calling the insurer and counsel, restoring, the ransom question and notification. CISA publishes a ransomware situation manual you can adapt. For the response itself, see [LINK: ransomware-playbook].

Payment-change fraud. Finance is asked to change a vendor's bank details or to wire money urgently. In CISA's own example scenario, a bank confirms a $50,000 transfer to a vendor's "new offshore accounts" that the accountant did not initiate. Add an inject in which the "executive" approves the payment by phone in a cloned voice. FinCEN's November 2024 alert says criminals have reportedly used generative AI to impersonate an executive and instruct victims to transfer large sums; it gives no prevalence figure. The decision under test is who may stop a payment, and on what evidence. See [LINK: bec-response].

Vendor breach. Build it on the contract. Inject 1: the vendor tells you nothing, but its customers are posting about an outage. Inject 2: you pull the contract to see what the vendor owes you, and by when. Inject 3: the vendor's notice arrives and does not say whether your data was touched. Test what the clause promises, who in your company holds the contract, and what you do when the vendor goes silent. CISA's vendor supply chain manual asks the same thing in Module 1, on Day 7 of the scenario: what cyber incident notification language your vendor contracts contain. See [LINK: vendor-security-review] for the clauses to check.

Who needs to be in the room, and who facilitates?

Put one person each from security, IT operations, legal, finance and communications in the room, plus an executive who can authorize shutting systems down. CISA's planner handbook says players must have the authority to speak for their function. A deputy who must "check with the boss" hides who would actually decide.

Add two roles that are not players:

• Facilitator. Runs the scenario and releases injects. NIST says the facilitator and the data collector should be thoroughly familiar with the plan being exercised.
• Note-taker. Records decisions and times on the scorecard below. CISA assigns note-takers "to observe and document exercise activities". This person must not also play.

CISA's tips suggest using an absent key person in the scenario. Make the executive unreachable for the first 30 minutes and see who acts.

NIST recommends separate senior-level and operational exercises at first; if IT staff would crowd out the executives, split the sessions and combine them later. Either way, 23 NYCRR 500.16(d) requires NYDFS covered entities to test with "all staff and management critical to the response".

In our view an outside facilitator is worth it when the plan owner's own decisions are being judged, when executives will not take direction from the security team, or when someone has to say uncomfortable things. CISA also takes exercise requests at cisa.exercises@cisa.dhs.gov.

How do you use CISA's tabletop packages as a starting kit?

Start from a CISA Tabletop Exercise Package (CTEP) and edit it. CISA describes each package as customizable, with template objectives, scenarios and discussion questions, and its situation manuals say modules, dates and questions "may be modified as desired".

The packages leave the company-specific parts blank. The ransomware manual's ransom demand is a placeholder, "<insert ransom amount (e.g., $53,000.00)>", and cost and notification appear only as open questions, such as "How long and costly would the process be to completely rebuild these systems?"

Four changes make a CTEP yours:

1. Replace placeholder names with your real systems, vendors and job titles.
2. Replace cost questions with your numbers from the worksheet below.
3. Turn each notification question into a clock inject with a time.
4. Add the scorecard below, which builds on the packages' note-taking questions.

How do you write injects that carry money and a legal clock?

An inject is a new piece of information the facilitator hands the group. Write each one so it forces a decision and states a consequence in dollars or hours. Compute the dollars before the exercise from your own numbers: revenue per hour of the affected system, recovery labor and contractual penalties. This is our method, built on your figures rather than vendor surveys; the worksheet's output goes straight into the injects.

Our practice for timing, which is not CISA's or NIST's: 90 to 180 minutes, roughly four to eight injects, and a short scenario. NIST puts a typical tabletop at two to eight hours and senior-level sessions at two to four, so a 90-minute session is a short drill. CTEP's default agenda runs four hours and tells players to take their time "without time pressure".

We depart from that deliberately, because a real incident has a clock. What keeps it fair is that minutes measure the process, not the person. CTEP frames the exercise as "open, no-fault", and its decisions as "not precedent-setting". Say so at the start.

Order injects by consequence:

• Money: "Finance reports the outage now costs $X per hour."
• Law: "Counsel says a notification clock may have started. Who decides, and when?" See [LINK: breach-notification-multistate] for how the notification clock works.
• Authority: "The only person who can approve this is on a flight." Who steps in under the plan?
• Missing information: "The log source you need was never enabled." What do you do without it?

How do you score the decisions?

The note-taker fills in a scorecard, one row per decision point, as the exercise runs. CISA's facilitator handbook already tells evaluators to capture who made the decision (by name or position), why (the trigger), how (the process), and who owns the solution and by when. We keep those fields and add three:

• Authority under the plan asks whether the person who decided is the person the plan names. 23 NYCRR 500.16(a)(1)(iii) requires the plan to define "levels of decision-making authority", so for NYDFS covered entities the answer is a compliance question.
• Minutes to decision runs from the inject that created the decision to the group's recorded answer.
• Missing information lists what the decider said they lacked. It points to logging, asset inventory or contract gaps.

NIST says criteria should be developed before the exercise so data collectors know what to capture.

A defensive AI agent can take the clerical part: transcribing the session with timestamps, matching decisions to injects, and drafting the after-action report from the log. Give it the plan text and the inject list, and nothing else. A human reads every row before it goes into the report, because the agent will miss a decision made in the hallway.

How do you run the session and follow up?

Each step below has an owner and a check. CISA's planner handbook says to start planning three or more months ahead; NIST says at least three months for a complex exercise and at least one month for a less complex one. We treat a 90 to 180 minute tabletop on one scenario as the less complex kind, so the schedule below starts eight weeks out.

1. Eight weeks before: the plan owner gets sponsor approval and picks the scenario. Verify: the sponsor's approval is in writing.
2. Six weeks before: the facilitator completes the exercise plan form above, including the cost-per-hour numbers. Verify: finance has confirmed the figures.
3. Two weeks before: the facilitator sends players the plan and the ground rules. Verify: each player replied.
4. Exercise day: the facilitator releases injects and the note-taker fills in the scorecard. Verify: every decision row has a time.
5. Within 24 hours: the facilitator and note-taker hold a short hot wash and list every gap. Verify: the list is saved with the scorecard.
6. Within three to four weeks: the plan owner issues the after-action report and improvement plan, the window CISA's planner handbook sets for the draft. Verify: every finding has an owner and a date.
7. At the next exercise: re-test the fixes. Verify: the previous register is on the table before the session starts.

How do you turn findings into drills and an action register?

Every assumption the tabletop exposed becomes a technical test. NIST's term for such an event is a test, an evaluation that uses quantifiable metrics to validate that a system works in its operating environment.

Record each conversion in a register with owner, due date and re-test date. CISA's planner handbook says participants should develop concrete deadlines and identify specific owners for corrective actions. FEMA's HSEEP doctrine adds that corrective actions should be tracked until completion and that previously fixed items should be validated; CTEP's facilitator handbook strongly recommends the HSEEP AAR/IP template for the after-action report.

Review the register in a standing monthly meeting until it is empty. The plan owner chairs it, and an item closes only when the drill's result is attached.

How often should you run one?

Run at least one exercise a year, and another after a major change. PCI DSS v4.0 Requirement 12.10.2 says "At least once every 12 months, the security incident response plan is" tested. NYDFS 500.16(d) says covered entities must test "periodically, but at a minimum annually". NIST adds that organizations should exercise "following organizational changes, updates to an IT plan, or the issuance of new TT&E guidance". CISA's Cross-Sector Cybersecurity Performance Goals 2.0 recommend the same annual minimum, on a voluntary basis. Treating a major vendor change as such an organizational change is our reading.

What evidence should you keep?

Keep the exercise plan, the scorecard, the after-action report and the register with its closure evidence. They show an auditor what you tested, who attended and what you fixed. Each rule asks for something specific:

• PCI DSS 12.10.2 (text from v4.0; confirm the wording in the current version before you rely on it): the plan must be tested, "including all elements listed in Requirement 12.10.1", and the assessor will "interview personnel and review documentation". A tabletop appears only in the guidance column, as one form the test can take, not as the requirement.
• 23 NYCRR 500.16(d) (NYDFS covered entities): test the IR and business continuity and disaster recovery plans at least annually "with all staff and management critical to the response", and separately test the "ability to restore its critical data and information systems from backups". A tabletop does not cover the second item; the restore drill in your register does. Limited-exemption entities are excused from 500.16.
• HIPAA: the current Security Rule asks covered entities to address periodic testing of contingency plans; an annual incident response plan test appears only in HHS's January 2025 proposed rule, which has not been finalized; its stage on the federal regulatory agenda is Long-Term Actions.

We did not check what cyber insurers require as proof of an exercise. Questionnaires vary by carrier, so read yours.

How do you know it worked?

Compare this exercise's records with the last one. The plan owner can check five things from them:

• Fewer decision rows show "Not in the plan" under authority.
• Median minutes to decision fell for the decisions that were slow last time.
• Every register item from the last exercise is closed with evidence, or carries a new date and a reason.
• At least one drill produced a measured result, such as a restore time, that replaced a claim in the plan.
• The plan has a new version number and a changelog entry for each finding that changed it.

If none of these moved, record that in the after-action report as a finding.