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: