What the owner gets
The first time you establish who makes a decision should not be after an incorrect message has reached a customer. Yet a conversation about “what we would do” can end with a vague promise to sort things out. This guide helps you prepare a concrete tabletop exercise: the team discusses a fictional situation, and the manager receives a verifiable list of gaps in the existing working procedure.
It is intended for a small hotel, restaurant, studio or other service business where people draft customer messages using AI. It is not attack training, an investigation into a real disclosure or a technical security test. If an incident is happening now, use the approved response process with the appropriate specialists rather than running a learning activity.
The Australian government’s Exercise in a Box describes tabletop exercises as discussions of hypothetical incidents without affecting real systems. The 45-minute schedule, cards and log fields below are Nadali’s editorial format, not that resource’s mandatory programme or a legal requirement.
1. Choose one exercise objective
Do not try to assess all of cybersecurity in one sitting. For the first session, define the outcome like this: “We will establish whether the team can name an owner, separate known facts from unknowns and route a question about an external message for approval.”
Write down three questions that need an answer by the end:
- Who receives the initial report, and who covers their absence?
- What information does that person need before deciding the next step?
- Who approves external wording, and where do they obtain verified facts?
Bring the current internal procedure and record its version. If no relevant procedure exists, call the meeting a planning discussion rather than a readiness assessment. Our guide to stopping and recovering an AI workflow covers operational steps. Here, the task is to examine how people find and explain their own decisions, not to repeat that procedure.
2. Separate roles and learning materials
Appoint a facilitator to present the cards and someone to record observations. Participants represent actual working roles: receptionist, shift manager, information owner and message approver. An owner may cover several roles, but the log should show which role they are speaking for.
NIST SP 800-84, published in September 2006, distinguishes facilitating discussion from recording observations, and includes a debrief and after-action report. This is methodological background, not evidence that our proposed exercise is effective.
Mark every page “TRAINING EXERCISE — FICTIONAL DATA”. Use roles and reference numbers instead of real names, addresses, customer histories or access logs. Include no working links. Agree that participants describe actions verbally: nothing is sent, revoked or deleted. If a genuine alert arises, the facilitator stops the exercise so the team can use its real response process.
3. Use AI for preparation, not to direct people
A fictional business description and the three learning objectives are enough to draft cards. Do not connect email, file stores or administrative tools. An existing approved text service may help; a specialist platform is unnecessary. Prepare the cards manually if no permitted tool is available.
Example prompt:
Create three short discussion cards about a fictional customer-message mistake in a small service business. Mark everything as a training exercise. Use only roles and fictional reference numbers. Card 1 supplies an initial signal, card 2 adds uncertainty, and card 3 requests an external explanation. Do not invent regulatory deadlines, service features or evidence that a message was read. Add two open questions to each card. Do not supply model answers or perform any action.
A person reviews the cards before the meeting. Remove clues that effectively reveal the “correct answer” and implausible details. Do not let the model change the story live: participants could end up responding to different conditions. NIST’s Generative AI Profile describes confidently incorrect output and privacy risks. A polished scenario still needs checking, and real data is unnecessary for this task.
4. Work through the cards in 45 minutes
This is an illustrative scenario, not a description of a real business or incident. Allow five minutes for boundaries and roles, eight for each of three cards, ten for the debrief and six to agree next steps.
Card 1. An employee reports spotting a passage relating to ENQUIRY-01 in a draft message for ENQUIRY-02. They do not know whether that version was sent. Ask whom they notify and which facts are already known. Do not add a delivery confirmation of your own.
Card 2. The person responsible for checking is absent today. The fictional description supplies only a draft reference and creation time, with no delivery information. Ask who takes the decision in their absence and what evidence must be obtained through the approved process. “We would check the log” needs a follow-up: who, which record, and where is their authorised access documented?
Card 3. The manager requests an external explanation. Delivery remains unconfirmed. Ask who approves the wording and which claims cannot yet be included. Participants can prepare a training-only internal brief: known facts, unknown circumstances and questions for the responsible person. Do not create a universal ready-to-send customer notice; its content and necessity depend on established facts and appropriate decisions.
5. Record observations, not judgements about people
Use these fields for each entry: card number; stated decision; role; cited procedure section; unknown; clarification required. Keep “said during the exercise”, “specified in the procedure” and “verified after the exercise” separate. They are different states.
For example: “Card 2: the team named a deputy but could not locate that role in the current procedure.” Do not turn this into “the deputy is incompetent” or “access is missing”. The purpose is to identify a gap between an agreement and a documented process, not to rank employees.
If AI organises approved notes, require it to preserve reference numbers and open questions. Compare every summary with the original. The model must not add decisions, owners, completed checks or statements attributed to participants.
6. Finish with an improvement queue, not just minutes
In the debrief, ask what supported a decision, where the team became stuck and what the document needs to clarify. Give each agreed change an owner, due date, expected evidence and a date for revisiting it. Do not mark it resolved until the responsible person has checked the result.
An example action is: “Add the approved deputy to the procedure; owner: manager; evidence: approved new version; repeat card 2.” This is more useful than “improve staff awareness”. For the next exercise, change one condition and revisit the specific gap that was addressed.
Takeaway: a tabletop exercise produces observations and accountable next steps. A successful discussion does not establish that message recall works, that no data was disclosed or that the business meets every requirement. Technical checks and real incidents need a separate approved process.
Author: Nadali. Prepared using AI. Sources checked on 28 October 2026; the editorial team has not run this exercise with a real team.
The cover is an editorial AI illustration, not a photograph of an actual process or test result.
