Use this to design one discussion-based exercise and to record its findings afterwards. You get four documents in a new folder, ./bcp-tabletop-design/: the exercise plan with objectives, scenario, timing and ground rules (exercise-plan.md); the script of events the facilitator reveals one by one during the session (injects.md); a note-taking sheet for observers (observer-sheet.md); and, after the session, the findings and owned actions (findings.md). This skill drafts for a human to review and sign; this skill never marks a control effective. A tabletop tests decisions and the plan on paper; it does not prove a technical recovery works, which needs a restore or failover test.
Inputs to gather
Read the incident response plan, the continuity and disaster recovery plans, the contact tree, the business impact analysis, the risk register, past incident reviews and the findings of the last exercise. Ask the reader, in one message: who must take part (and whether the executive who can authorise spending will attend; if not, record that as a finding and check the plan's delegated authority), how long the session can be, what worried leadership most in the last year, and whether a key supplier or the insurer should join.
Step 1: choose two or three objectives
Write objectives as questions the exercise answers: can the team decide within the first hour whether to take the core service offline; does the contact tree reach the right people out of hours; does anyone know how to start the regulatory clock; can the company run billing by hand for three days. More than three objectives turns the session into a tour of the plan.
Step 2: build a scenario from the company's own risks
Take the scenario from the top of the risk register or the business impact analysis, never from a news headline that does not fit the company: ransomware reaching backups, the main cloud or software supplier down for two days, a mailbox takeover used for invoice fraud, a customer data export posted publicly. Make the starting point mundane and plausible, as real incidents are: an alert at an awkward hour, a customer email, a supplier status page.
Step 3: write injects that force decisions
Write six to ten injects in the facilitator's script (injects.md), each with a time in the scenario, the information given, who receives it, and the decision it forces. Escalate across the session. Include:
- one inject that makes things worse (backups also encrypted, the supplier extends its estimate);
- one that removes a person (the incident lead is unreachable);
- one external pressure (a journalist, a large customer, an authority asking questions);
- one that starts a regulatory or contractual clock, so the team must state the deadline and who owns it. List the candidate clocks in the plan beforehand: personal data breach notification (72 hours under GDPR where the company is controller), NIS 2 early warning and notification (24 and 72 hours, Art. 23) for entities in scope, DORA major incident reporting for financial entities, and customer contract notice terms. "We do not know which clock applies" is itself a finding;
- one that tests a fact rather than an opinion: where is the offline copy of the recovery credentials, who can approve paying for outside forensics at night.
An inject that only adds information without forcing a choice wastes time.
Step 4: brief facilitator and observers
The facilitator runs the clock and the injects and does not take part in decisions. Name one or two observers and give them the observer sheet (observer-sheet.md): per inject, the decision made, who made it, how long it took, which document or tool they used, and gaps. Set ground rules for the opening: no blame, answer with what you would actually do, use the real plan and contact tree, and a stop rule if a real incident starts. Plan 90 to 120 minutes plus a 20-minute hot debrief.
Step 5: record findings and actions
After the session, fill the findings document (findings.md) from the observer sheets: what worked, and each gap classified as plan, role, tool, supplier or knowledge. Start by checking the actions from the last exercise: closed, or still open with a new date. Turn new gaps into owned, dated actions with the document each one updates, and list risk-relevant gaps as proposed entries for the risk register and the next management review, for their owners to add. Record attendance by role, the scenario, objectives met or not, and the date of the next exercise with a different scenario. Keep the record under the company's document rules so the evidence survives the person who ran the session. Run a framework lookup for what each framework in scope expects as testing frequency and test evidence; DORA (Art. 11 and Art. 24 onwards) and NIS 2 (Art. 21) both reach continuity testing for entities in their scope.
What good looks like
- Every inject forces a decision, and the findings show which decisions took too long or had no owner.
- A strong practitioner includes the fact-checking inject; it is where plans quietly fail, such as recovery credentials stored only on the encrypted network.
- The common mistake is a walkthrough where participants read the plan aloud and agree it is good. That produces attendance evidence and no learning.
- The tell that it went wrong: no finding, or findings that are all "update the contact list", no executive in the room, and the same scenario as last time.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-bcp-tabletop-design
Rules
- MUST base the scenario on the company's own risk register or impact analysis, citing the entry.
- MUST give every finding an owner role, a due date and the document it updates.
- MUST write outputs only inside
./bcp-tabletop-design/ and ask before overwriting.
- NEVER send invitations, simulated phishing or injects to participants on the reader's behalf.
- NEVER touch live systems, alerting or suppliers during the exercise; it is discussion only.
- NEVER record individual performance by name in the findings; use roles.