Tabletop Exercise: Test Client Decisions in 60 Minutes

Set the Scope Before You Invite People

Treat the session as a rehearsal of decisions, not a live technical recovery test.

It's like reading through a play before a performance: you can discover that a speaker has no lines without proving the scenery will move. For this exercise, the evidence is what people can explain and locate in their current plan.

Choose the business service and the decision you want to examine. A possible objective is: 'Establish who can approve interrupting the affected work and how the client will operate while it is unavailable.' Keep the proposed hour narrow enough to examine that objective properly; it isn't a full validation of every response procedure.

Share the objective with the client sponsor before the meeting. Ask them to identify the people with the relevant authority. If that authority can't be represented, record the limitation and arrange the missing decision separately instead of having the MSP guess on the client's behalf.

Bring the People Who Own the Decisions

Assign the exercise responsibilities explicitly. The account manager or vCIO can organize the session, but that title doesn't automatically make them the technical response lead or the client's business decision-maker.

A person may hold more than one responsibility if the session remains workable. Avoid making the facilitator answer every question as well as ask it. Give participants the current response plan and the relevant contact arrangements before the exercise so you're examining their use, rather than rewarding whoever remembers the most names.

CISA's tabletop package documents include materials for facilitators and participants, along with an after-action report. You can adapt those resources to the chosen objective. Keep the client's actual responsibilities in the exercise rather than copying a larger organization's roles into an MSP engagement.

Use a Scenario That Leaves Room for Decisions

For this hypothetical, a client employee reports that shared business files have become unreadable and a message demands payment. The cause and extent haven't been confirmed. Present that as an exercise prompt, not as a diagnosis or an instruction to change the client's systems.

Open the session by stating that all actions are being discussed. No participant should alter a live system because the scenario says it is affected. If a real incident is reported, stop the exercise and use the agreed response arrangements.

Run the conversation in this order, using only as much scenario detail as the objective needs:

1. Present the initial report. Ask who receives it, what is known, and who decides whether to activate the client's response plan. Record the named role and the plan reference used.
2. Introduce a business conflict: an affected team needs the files to complete essential work. Ask who can authorize interruption and who chooses an alternative way to continue. Don't let a technical recommendation stand in for that authorization.
3. Make the usual client contact unavailable within the hypothetical. Ask who has delegated authority and how the MSP reaches them through an agreed alternative channel.
4. Ask the group to explain what must be established before normal work resumes. Record the business acceptance decision separately from the technical checks that would support it.
5. Review the recorded gaps with the sponsor and choose the most useful follow-up actions. Keep unresolved questions visible rather than extending the story until everyone says the response succeeded.

Let the plan be consulted. You're testing whether its instructions support a decision, not whether someone can recite them. If a participant says they would contact an external adviser, ask which agreed process supplies that contact and who can make the request.

Record the Answer Instead of Smoothing It Over

Use a shared exercise note with a separate entry for each decision discussed. Record the person or role giving the answer and the document they relied on. Mark an assumption as an assumption until someone checks it.

For example, suppose the client says only its absent managing director can approve the interruption. The failure is missing delegated authority; the MSP representative encounters it when requesting approval. Writing 'escalate to management' in the notes would conceal the same gap the exercise just exposed.

If participants disagree about who approves a message to customers, record the competing answers and who will resolve them. Don't have the recorder choose whichever sounds most plausible. A tidy note is a poor substitute for an agreed responsibility.

Whether to bring a specialist into the follow-up depends on the decision involved and the client's existing arrangements. For legal or insurance questions, identify the appropriate adviser and the route for consulting them. Don't invent notification deadlines or claim that the exercise establishes compliance.

Write the Three Fixes as Work Someone Can Finish

Use the requested three-fix limit to prioritize the follow-up, not to force the findings to fit a number. Keep all observed gaps in the exercise record. If fewer than three need action, don't manufacture another one to complete the report.

Each selected fix needs a named owner and a completion date agreed with that owner. Describe the evidence that will establish completion. 'Improve communication' gives the next reviewer nothing to check.

Possible fixes, only if the discussion exposes these gaps, are:

• Confirm delegated client authority, then update the response plan with the accepted role and contact route.
• Agree an alternative communication arrangement, then check that the named participants can access its instructions.
• Document the business resumption decision, including who accepts the evidence supplied by technical recovery.

An empty decision field is a useful result. Calling it resolved because everyone attended is less useful. Keep the action open until its agreed completion evidence exists, and record any remaining limitation alongside it.

Explain What the Hour Did and Did Not Establish

The closing note should say which objective was discussed and what the group decided. Include the unresolved dependencies and the owners of the selected fixes. Check that the sponsor agrees with the record before treating a disputed answer as the client's position.

A tabletop doesn't prove that a backup restores or that a particular recovery time can be met. Arrange the technical verification as separate work with its own scope. The model's baseline security remains required; a successful conversation doesn't replace delivery of it.

Choose the service and objective with the client sponsor, then book the people who can make the relevant decisions. Prepare the prompt and a decision record before the meeting. The useful result is a clearer plan with checked follow-up, not a roomful of people who were persuaded to sound ready.