Tabletop: practice a security incident together

No systems need to break for a team to practice an incident. A tabletop is a facilitated discussion: a fictional situation changes, participants make decisions, and an observer records what the plan enables or leaves unclear.

Tabletop exercise: A facilitated discussion using a fictional scenario to practice decisions and coordination.

Keep the objective small enough to test

Choose one question: can the team coordinate when its normal login service is unavailable? Define participants, an incident lead, a facilitator, and an observer. Set a timebox and make clear that all events are fictional.

The facilitator introduces staged updates, called injects.

Let uncertainty do useful work

Begin with an unavailable service. Add a report of unusual account activity. Later reveal that one recovery dependency is unavailable too. There is no need for a cinematic attack story: ordinary dependencies can expose important gaps.

Ask participants to explain tradeoffs rather than guess the facilitator’s preferred answer. Record decision times, missing contacts, unclear authority, and assumptions. An exercise is a learning environment, not a test of who sounds most confident.

Close with changes that can be verified

Discuss what worked and what created delay. Convert observations into a small set of actions with owners, dates, and completion evidence. For example, validate an alternate communication channel or update an out-of-date dependency map.

A discussion cannot prove a backup restores within its target time. Follow it with appropriately scoped technical tests where needed. Repeat the scenario after improvements to see whether the same confusion remains.

EXPLORE THE CONCEPT

A three-step tabletop

Read each update in order. Pause to choose an owner and next action before revealing the next one.

1 · Normal login is unavailable

Establish impact and activate the agreed communication path. Identify who leads and what evidence would distinguish an outage from an incident.

2 · An unusual privilege change is reported

Treat it as additional evidence, not a complete explanation. Coordinate investigation and consider authorized containment with its service impact.

3 · Recovery needs the unavailable identity service

Surface the dependency and consult the tested emergency-access plan. Record any gap; do not pretend the dependency is solved.

A simplified learning model. It connects to no systems and uses no real data.

Your Harbour exercise packet

Harbour coordinates a booking outage while staff chat depends on the failed sign-in provider. Allow thirty to forty-five minutes for reading, a twenty-minute discussion, and review. A solo learner takes each role in turn and records decisions on paper.

All service names, people, and channels below are invented exercise labels. Simulate messages by writing “sender → recipient: message” in your log. Everything required is here; contacting anyone is not part of the exercise.

D1-D4: the supplied dependency record

R1-R4: roles and contact channels

For this case, accept the starting records as accurate. New capabilities or people you propose remain labeled assumptions until supported. You can propose a reasonable alternative without pretending it already exists or has approval.

Minute zero: choose a usable coordination route

Staff cannot access bookings and two customers report failed requests. Before reading further, write the known impact, coordinator, communication route, and evidence for that route. D1 does not establish whether Booking Data is damaged.

A supported opening names Alex as coordinator, uses Amber based on D3, and asks Cam to record impact for Bea’s priority decision. Team Chat has a known failed dependency. Amber’s starting check supports these three participants at this point; it does not establish a reachable deputy or permanent availability.

Minute six: handle an uncertain report

Cam reports an unexpected administrative change. The report contains an account label, but no approval context, and the relevant collector stopped reporting earlier. Record what evidence could distinguish an approved change from misuse. Do not infer the operator’s identity from the account label alone.

PredictMust recovery planning stop until the team determines whether the change was malicious? Write which decisions can continue, which depend on missing facts, and who owns the next step.

Investigation and recovery planning can proceed together. Alex can review dependencies and request the change record; Cam can preserve the reported impact and prepare a cautious update for Bea. Decisions that might destroy evidence or restore an unsafe state need explicit review. Neither the account label nor missing logs settle the cause.

Minute twelve: escalate a genuine missing capability

Alex reports that Recovery Guide requires the unavailable Sign-in service. The former recovery deputy has left and R4 has no replacement. Write who owns the gap and what evidence would be needed before claiming a usable recovery route.

The supported decision is to escalate to Bea over Amber and assign Alex to review an approved recovery-access alternative. No such alternative is supplied. Bea can prioritize the review, but her approval alone cannot make a technically unavailable route work. An imagined new deputy or accessible copy must remain a proposal, not a completed recovery step.

Review the decisions, then name the next test

Check four things in your log: coordinator assigned; channel choice supported; observation separated from compromise claims; recovery gap assigned an owner. Use columns for minute, evidence ID, decision, owner, and unresolved assumption. An unfilled evidence cell is a useful gap to discuss.

Two model after-action rows are: Bea assigns a qualified deputy within seven days, with documented responsibility and an independent contact check; Alex reviews Recovery Guide’s access within fourteen days, with an approved dependency change and evidence of an authorized access test. These are proposed exercise deadlines. Accept alternatives with a stated reason and owner’s agreement.

The contact check does not prove technical recovery speed. Plan a separate recovery exercise for that capability. CISA’s materials distinguish participant decisions, facilitation, and evaluation; the observer should record evidence rather than fill gaps for the team. Apply the same reasoning in the service outage case.

Turn the idea into a decision

A good exercise leaves a better plan and a short list of verified improvements.