What you will take away
A cybersecurity tabletop is a discussion exercise: your team works through an invented incident without changing live systems. In one hour, this exercise tests who can make decisions, what evidence they need and how they keep customers informed. Finish with named improvements, not a claim that the business is now secure.
1. Prepare the room and a narrow objective
Consider a fictional Cairo booking business: the owner works in Nasr City, a receptionist handles customer appointments elsewhere, and an external developer maintains the website remotely. Nobody has the full picture when bookings become unreliable. Distance matters here because the exercise must test a handoff that still works when people cannot gather around one screen.
Invite the owner, an operations representative, the person responsible for the website and a recorder. Add a facilitator who releases the scenario updates below. In a small team one person may hold two roles, but the recorder should capture what was actually decided. A provider who is absent can be represented by an exercise participant; do not assume the real provider has accepted a response deadline.
Write this objective: “Within the exercise, identify a decision owner, approve a safe temporary booking process and state what evidence is required before normal service resumes.” Bring your existing contact list and website incident response plan. If either is missing, record that gap before starting.
2. Make the exercise safe to run
- Label every printed scenario and mock message “EXERCISE — fictional information.” Use invented customers and reference numbers.
- Discuss actions; do not disable accounts, scan systems, restore backups, send customer notices or process payments during this meeting.
- Use a separate discussion channel that does not depend on the affected website. Put no passwords, session tokens or customer records in it.
- Agree that any real incident pauses the exercise and goes to the real responsible person through the established process.
The facilitator should distinguish “we would call the developer” from evidence that a reachable contact and backup contact exist. A promise to investigate is a decision to record, not a finding that the system is safe.
3. Release these updates over 60 minutes
| Minutes | Scenario update | Decision or evidence to record |
|---|---|---|
| 0–5 | Explain the objective, roles and exercise-only boundaries. | Name the incident decision owner and the person taking notes. |
| 5–15 | The receptionist sees failed booking confirmations. Two customers report duplicate appointment messages. The cause is unknown. | Separate confirmed observations from guesses. Name who checks scope and who approves a temporary workflow. |
| 15–25 | The owner is unavailable for the next ten minutes. A staff member suggests collecting customer details in a personal messaging group. | Name the deputy. Choose an approved temporary process with minimum data, limited access and a reconciliation owner. |
| 25–35 | The developer reports a recent website change. A third-party service has not yet confirmed whether it has a problem. | Record the next evidence request. Assign one provider contact. Decide what would justify a change or rollback without performing it. |
| 35–45 | A customer asks whether their data was stolen. A screenshot circulating internally claims everything is fixed. | Draft a factual holding message. State who approves it and what remains unknown. A screenshot alone is not recovery evidence. |
| 45–60 | The facilitator says the technical team proposes resuming bookings. No proof has been supplied yet. | Define acceptance checks, reconciliation responsibilities and the next review time. Then score the exercise and assign improvements. |
Read each update only when its time arrives. Do not reveal the cause: there is deliberately no hidden “correct attacker” to discover. The goal is to practise decisions under uncertainty. If the discussion stalls, ask “Who owns the next action, and what would they need to decide?”
4. Record a decision, not a transcript
Use one row per decision with these fields: exercise time, observation, decision, owner, evidence needed and next review. For example:
Minute 18: The main owner cannot be reached. The named deputy approves a fictional temporary appointment queue using the business’s approved restricted workspace. The receptionist owns the queue. Only a booking reference and a callback detail needed for that booking are requested. The developer must report the affected workflow by minute 28. The deputy will review the decision then.
This record exposes several separate questions: whether a deputy exists, whether a permitted workspace is available, and who reconciles temporary appointments. “Keep working as normal” answers none of them. Avoid promising a recovery time until the people responsible can support it.
For a business using Gammal Tech, separate the website owner’s responsibilities from the documented hosted functions. The website code, staff procedures and external services still need identified owners. Use the existing shared-responsibility guide to prepare that map before the exercise.
5. Score observable behaviour
| Check | 0 points | 1 point |
|---|---|---|
| Decision authority | Nobody can name an available decision maker. | A decision maker and deputy are named. |
| Evidence handling | Assumptions are written as confirmed facts. | Known facts and open questions are separated. |
| Continuity | An unapproved data-sharing workaround is accepted. | A limited, approved temporary process has an owner. |
| Communication | Someone promises facts or deadlines not established. | A responsible person approves a factual update. |
| Recovery | A reassuring message is treated as sufficient. | The team names checks and who accepts the result. |
A score out of five measures this rehearsal only. It is not a security certification or a prediction of incident outcomes. Keep a note explaining each point: “a deputy was named but the contact was outdated” is more useful than an unexplained total.
6. Turn gaps into work that can be checked
Before leaving, select the three most consequential gaps. Give each an owner, an agreed due date and evidence of completion. Examples are a verified deputy contact, a restricted temporary-booking template and a documented service-restoration checklist with an approver. Do not put all three under “IT” if operations owns one of them.
Schedule a short repeat after the fixes. Change one condition—for example, the developer is unavailable or a temporary booking appears twice—and check the improved handoff. Keep the earlier decision record so you can compare behaviour. Staff who need practice recognising suspicious messages can use the separate Cairo employee cybersecurity workshop; that is a different exercise from management’s incident decisions.
Questions before running the exercise
Does a tabletop replace a technical recovery test?
No. It rehearses decisions and coordination. An authorized technical team must separately plan and verify backup restoration, containment and other live-system actions.
What if we do not know whether an event is an attack?
Keep that uncertainty visible. Name the next evidence request and decision owner. A service problem can require a controlled response before its cause is known.
Can this be run online?
Yes. Share the fictional scenario, appoint a recorder and choose a discussion channel everyone can access. Test the separate contact route rather than assuming that a Cairo office meeting is always possible.
Further reading
Examples and worksheets in this guide were prepared by Gammal Tech. Links and references reviewed on 20 October 2026.