Cybersecurity tabletop exercises: test the decisions before the incident.

Start with a decision your incident plan must support

A cloud account looks suspicious, the client portal stops working, and a major customer wants an explanation. IT is investigating. Leadership wants to know whether service should remain available. The account manager needs something accurate to say. A cybersecurity tabletop exercise gives those people a chance to practice making connected decisions before an actual incident forces them to do it under pressure.

NIST describes a tabletop as a facilitated, discussion-based exercise about roles and responses to a scenario, without deploying equipment or other operational resources. [1] Its value comes from exposing assumptions: who can interrupt a service, what evidence informs that decision, and how the rest of the business learns what happened. A completed meeting is useful only if the organization understands what the discussion demonstrated and what still needs work.

This guide follows a fictional professional services firm that uses cloud accounts and a client document portal. It is an educational example, not an SPS customer incident. The exercise begins with uncertain evidence and a service problem; it does not assume that every alert confirms a compromise. The planning recommendations below illustrate how to build a useful session, rather than prescribe a mandatory format, duration, or exercise schedule.

Define objectives that an observer can evaluate

Replace “test our incident response” with a small set of observable objectives. For the fictional firm, participants should identify who can activate the response plan, name the person authorized to restrict portal access, and produce an internal update that separates confirmed facts from assumptions. Each objective should identify the decision or handoff being examined and the evidence an observer will look for during the discussion.

An objective might ask the team to identify an available decision maker when the usual executive cannot be reached. Another might ask responders to explain which records they would preserve and who can obtain them from the cloud provider. Agree what counts as a useful answer: an actual role, current contact route, applicable procedure, and unresolved dependency. “Someone in IT handles that” should generate a follow-up question, not a completed checkbox.

Gather the documents needed to assess those answers: the response plan, relevant playbooks, service and identity diagrams, provider agreements, escalation contacts, and communications templates. Use current material and note missing items before the session. Distinguish a discussion intended to teach an unfamiliar plan from one intended to examine established practice. Both can help, but a team reading a procedure for the first time should not be reported as having demonstrated practiced execution.

Connect executive decisions to technical information

An executive tabletop examines authority, business priorities, communications, and the consequences of available choices. A technical tabletop examines how responders would investigate, preserve evidence, contain activity, and support recovery. The audiences need different levels of detail, but their decisions depend on one another. NIST’s incident response guidance identifies roles across leadership, incident handlers, technology teams, legal advisers, communications, asset owners, and external providers. [2]

For the fictional firm, the technical group can describe the evidence supporting an account restriction and the operations it might interrupt. The executive group can decide who has authority to accept that disruption and which client services receive priority. Rehearse the exchange between them. A technical explanation should identify confidence, likely business impact, options, and the next information needed; a leadership decision should return a clear owner and direction.

Invite the people who actually hold those responsibilities, including relevant service providers when their participation is agreed. Give designated alternates meaningful roles. If a provider cannot attend, use its current contract and runbook to examine the handoff, and record any unverified assumptions about its response. Avoid letting one senior participant answer every question. The exercise should reveal how the organization coordinates when information and authority sit with different people.

Build a plausible scenario with incomplete information

Use a scenario that follows the organization’s real dependencies without copying sensitive client material into the exercise. The fictional firm receives a report of an unusual sign-in to a cloud account used by its portal support team. The account owner does not recognize the activity. Participants must decide who receives the report, what makes it urgent, and which additional information they would request. Cause, scope, and data exposure remain unconfirmed.

A later exercise update reports that some clients cannot open portal documents. The facilitator asks whether participants think the two events are connected and what would establish that connection. They should consider both security and operational explanations while deciding what to do now. A further update brings a client inquiry asking whether documents were exposed. That creates a communications decision without supplying a convenient, complete investigation result.

These updates, often called injects, should serve the objectives. Each needs a clear source, the information available to participants, and the decision it is intended to explore. Keep later facts consistent with earlier ones, and state when the exercise advances simulated time. More dramatic events do not necessarily make the session more useful. A focused scenario can reveal a missing approval path more clearly than a succession of unrelated crises.

Let the facilitator expose gaps without supplying the answers

Assign facilitation and observation responsibilities before the session. The facilitator presents the scenario, manages participation, and asks participants to explain their choices. The observer records the decisions, references to the plan, unresolved questions, and departures from the agreed process. NIST’s exercise guidance separates facilitation from data collection so observations can inform the after-action report. [1] In a small session, define how those tasks will be covered without losing the discussion.

Agree the ground rules: the session is an exercise, actions are discussed rather than executed, and any actual operational problem pauses exercise play. Mark scenario materials clearly and agree who may see the notes or recordings. Participants can consult the documents allowed by the exercise plan. When someone proposes calling an outside party, simulate or discuss that contact unless participation has been arranged; an exercise message should not create a real incident or customer alarm.

When a participant says the team would disable an account, ask who has authority, which dependencies could be affected, and what would be communicated. When the answer depends on unavailable evidence, capture the gap rather than inventing a capability to keep the scenario moving. Allow uncertainty without allowing it to end the discussion. The next question is what decision can reasonably be made with the information available and who will obtain the missing facts.

Record the decision and the reason it might change

A decision record makes the exercise useful after everyone leaves. Capture the question, facts available at that point, important unknowns, options considered, decision owner, selected action, and rationale. Add the person responsible for follow-up and the next review trigger. Record whether the answer came from the existing plan, a participant’s memory, or an assumption that requires confirmation. Those differences affect what the organization can reasonably claim it demonstrated.

In the fictional scenario, participants might propose temporarily restricting the suspected account while assessing its dependencies and seeking more evidence. The record should identify who would authorize that action, who would perform it, what client work could be affected, and who would report back. It should also capture whether the group actually knows that the restriction would terminate existing access. That last question may require later technical validation rather than another confident statement in the room.

Avoid retrospective certainty. A later inject may contradict an earlier assumption; retain the original reasoning and show what changed. Review decisions against the information participants had when they made them. Also distinguish exercise pacing from operational performance. A group reaching a decision quickly in a facilitated discussion has not established that the real team will detect an event, retrieve evidence, or implement containment within the same elapsed time.

Practice communications while facts are still developing

Give communications work a concrete output. Ask participants to outline an internal update or a client holding statement based only on the scenario facts they have received. Identify who drafts it, who verifies technical statements, who approves release, and who handles follow-up questions. An accurate update can acknowledge a service disruption and ongoing investigation without claiming a cause, confirming data exposure, or promising a recovery time that has not been established.

Bring counsel into the planning discussion where legal or contractual duties may apply. NIST identifies legal advisers as contributors to response planning and to decisions involving laws, regulations, and contracts. [2] Counsel should determine the obligations relevant to the organization and scenario, including what facts trigger further analysis. The exercise should identify the responsible adviser and escalation path; a generic scenario should not supply a universal notification deadline or decide the organization’s legal duties.

Also rehearse how people communicate if the usual channel is unavailable or untrusted. The fictional firm should explain how leadership and responders would exchange updates if they cannot rely on the affected cloud account. Record where current contact information lives and who maintains it. Keep exercise drafts separate from external communications, and review what the client-facing team needs to know so it does not fill gaps with unsupported reassurance.

Turn the after-action report into owned, verifiable work

Close the session with a short debrief while observations are fresh. Ask what worked, where decisions stalled, and which assumptions need checking. CISA’s facilitator and evaluator handbook describes an after-action report that captures strengths and improvement areas, paired with an improvement plan assigning corrective actions, implementation timelines, and responsible parties. [3] Organize findings around the original objectives so leadership can see what was examined and what remains untested.

Write findings as specific gaps with consequences. “Improve communications” gives an owner little to implement. “The portal incident lead could not identify an approved alternate communications route” supports a concrete action: document the route, verify contacts, brief the affected roles, and repeat that module. Give each action an accountable owner, target date, dependencies, and completion evidence. Separate a needed management decision from a document change or a technical question.

Verify the correction in a way that matches the finding. A revised authority matrix can be checked through another decision walkthrough. An assumed account-revocation capability needs a separately authorized technical check. Report whether the fix is proposed, implemented, verified in discussion, or technically tested, with its scope and limitations. Carry overdue or rejected actions into the organization’s normal risk review so the exercise leads to a visible decision about the remaining exposure.

Choose the next validation step and the right engagement

A tabletop can reveal that nobody knows who receives an alert. It cannot establish that the alert will fire, that evidence is retained, or that a backup can be restored. Use the findings to choose the next appropriate exercise or test. Detection and response validation can examine selected techniques and tooling under an agreed scope; a recovery test addresses different questions. Define authorization, environment, operational limits, and evidence requirements separately for any work that executes actions.

SPS’s Incident Readiness services cover response planning and tailored executive and technical tabletop exercises. The work includes scenario development, facilitation, an after-action improvement plan, and revisions to the relevant plans or playbooks. A follow-up walkthrough or re-run can examine corrected decisions and procedures. These are readiness engagements, not an incident-handling retainer. For an initial discussion, bring the service you want to protect, the decisions you want to examine, your current plan, and the people who will own the resulting improvements.