EXERCISE ONLY — RANSOMWARE TABLETOP FACILITATOR PACK CyberPlay editorial team | 13 September 2026 Original fictional exercise. Suggested duration: 60 minutes. Before use, add the local reporting route, response contact, fallback contact, continuity owner and communications approval route. Do not enter real confidential data in the training materials. LOCAL PREPARATION Date and facilitator: ____________________ Incident reporting route: ____________________ Fallback contact route: ____________________ Business continuity owner: ____________________ Communications approval owner: ____________________ Specialist contacts needed: ____________________ 1. SET THREE OBJECTIVES BEFORE THE SESSION Choose a manageable scope: recognise when to escalate, coordinate when the normal communication channel is unavailable, and authorise a temporary business workflow. Write what successful discussion would demonstrate for each objective. Avoid trying to test the entire recovery architecture and every regulatory obligation in one introductory meeting. NIST SP 800-61 Rev. 3 places incident response within broader cybersecurity risk management. Use the tabletop to connect ordinary team decisions with that response structure. CISA also publishes cybersecurity exercise scenarios, including ransomware. Those resources are useful for a more formal exercise programme after the team has rehearsed these basic coordination questions. 2. ASSIGN ROLES AND DECISION AUTHORITY Invite a facilitator, a note-taker, the incident contact, a business operations representative, a customer-communications owner and an appropriate manager. Include the people who own privacy, legal or sector-specific obligations where the scenario requires them. One person can represent more than one role in a small organisation, but the responsibilities should remain explicit. Role | Exercise responsibility Facilitator | Present fictional facts, manage time and keep discussion inside scope. Note-taker | Record decisions, assumptions, gaps, owners and follow-up dates. Incident coordinator | Explain escalation and coordinate the authorised response process. Business operations owner | Identify critical work and permitted continuity options. Communications owner | Define internal and external messaging approval routes. Management and specialist owners | Resolve authority questions and identify obligations requiring assessment. 3. PREPARE THE ROOM AND THE EXERCISE RULES Bring the current incident contact list, reporting instructions, continuity plan and communication approval process. Use offline copies where appropriate so the discussion can explore an unavailable normal system. Check contact details through an agreed preparation step; do not surprise real responders by placing an unannounced exercise call. Mark all materials clearly as an exercise. State the rules aloud: participants describe actions rather than execute them; no production changes, account resets or customer notifications take place; a real incident stops the exercise. Unknowns should be recorded, not filled with convenient assumptions. If someone says “IT will restore everything”, ask which approved plan and owner support that expectation. 4. FOLLOW THE SUGGESTED 60-MINUTE AGENDA The fictional organisation is a small services company with a shared document workspace, a customer support queue and scheduled work due that afternoon. Replace those details with comparable fictional business functions if needed. Avoid using a real customer’s name or actual sensitive records. The facilitator releases information gradually so the group has to make decisions with uncertainty. Time | Stage | Question to resolve 0–10 minutes | Briefing and roles | What can each person decide, and how will gaps be recorded? 10–20 minutes | Inject 1: files unavailable | How is the concern reported and escalated? 20–30 minutes | Inject 2: normal chat unreliable | How do teams coordinate through the approved fallback? 30–40 minutes | Inject 3: customers need answers | Who approves the message and a temporary workflow? 40–50 minutes | Inject 4: recovery uncertainty | Which business priorities and information guide the response? 50–60 minutes | Debrief | Which improvements need owners, deadlines and verification? 5. INJECT 1: AN EMPLOYEE CANNOT OPEN SHARED FILES Read this fictional update: “At 09:10, a team member says several shared files have unusual names and cannot be opened. Another employee reports a message demanding payment on their work screen. The normal reporting service is still available.” Ask the group to describe the first report, who receives it and how the business owner learns that work may be affected. The employee’s job is to follow the approved reporting and immediate-response instructions, providing accurate observations. The group should not improvise technical containment. CISA’s ransomware guidance includes coordinated isolation and evidence considerations; actions such as disconnecting or powering down systems have operational consequences and belong to the authorised procedure and response team. - What facts are known, and which are assumptions? - Who can declare or coordinate an incident? - What should the reporting employee do while waiting for instructions? - How is the report handled if the primary contact does not respond? 6. INJECT 2: THE USUAL CHAT CHANNEL BECOMES UNRELIABLE Read this fictional update: “At 09:25, some employees cannot use the normal chat service. A message in an existing group claims to be from support and asks everyone to use a new public chat room for recovery instructions.” Ask how participants verify that instruction and where the approved fallback channel is documented. Do not assume that a familiar group conversation makes every new instruction trustworthy. The incident coordinator should explain the established alternative and how the team will recognise authorised directions. If no fallback exists, record that gap and discuss who should define it. Avoid creating a real emergency group during the exercise without following the organisation’s normal approval and access process. 7. INJECT 3: CUSTOMER PRESSURE ENCOURAGES A WORKAROUND Read this fictional update: “At 09:40, a customer requests an urgent status update. A team member proposes moving yesterday’s customer export to a personal cloud account so work can continue. The export may contain information that is not current.” Ask who can authorise continuity, what information is safe to use and how the external message is approved. A helpful workaround The team wants to restore service quickly but has no approval for personal cloud storage. 1. Move the export now and document it later. 2. Wait silently until every system is restored. 3. Escalate the continuity need to the authorised owner and use only an approved temporary process. Facilitator answer: Escalate the business need and obtain an approved continuity decision. The need to keep working does not automatically authorise a new data destination. Debrief: Ask what minimum service can safely continue, what customer message can be approved now and what decision remains with the response team. 8. INJECT 4: RECOVERY TIMING AND DATA EXPOSURE ARE UNCERTAIN Read this fictional update: “At 10:00, the response team has not confirmed when the shared workspace will return. A claimant alleges that company information was copied. The claim has not been verified. Management asks which services should be restored first and what can be said to customers.” Ask the group to separate verified facts, claims and unknowns in its decision log. The business owner can explain dependencies and priorities; the technical team evaluates recovery options. Designated specialist owners assess notification duties and other legal or contractual requirements. Do not invent a universal reporting deadline or have ordinary employees negotiate with the claimant. The exercise should establish who owns those decisions and what information they need. 9. DEBRIEF WITH A DECISION LOG AND IMPROVEMENT ACTIONS Ask what worked, where the team relied on assumptions and which missing process made a decision difficult. Record each gap in a form that can be resolved. “Communication was unclear” is too vague. “Publish and verify the incident fallback contact route, owned by the incident coordinator, before the next exercise” provides a concrete action. Log field | What to write Observation | The specific point where a decision or handoff became difficult. Consequence | What business or response activity could be delayed or mishandled. Action | The practical change required to resolve the gap. Owner and due date | The person accountable for completing the change and the agreed date. Verification | How the team will check that the new process works. 10. VERIFY IMPROVEMENTS AND CONNECT INDIVIDUAL PRACTICE Send the decision log through the organisation’s agreed internal process and schedule a review of the actions. Keep exercise notes only as detailed as necessary for that purpose. In a later session, change one dependency—such as the unavailable contact or affected service—and see whether the revised process still works. A tabletop discussion does not by itself prove that backups restore correctly or that a technical recovery plan has been tested. CyberPlay’s ransomware scenarios can provide individual practice before or after the team discussion. Use the topic directory to select an appropriate game, then connect one decision to the real escalation process. Keep the distinction clear: a game practises choices, the tabletop rehearses coordination, and operational recovery needs its own authorised validation. BLANK ACTION RECORD Observation: ____________________ Consequence: ____________________ Action: ____________________ Owner: ____________________ Due date: ____________________ Verification method: ____________________ SOURCE REFERENCES Incident Response Recommendations and Considerations, SP 800-61 Rev. 3 — https://csrc.nist.gov/pubs/sp/800/61/r3/final Cybersecurity Scenarios — https://www.cisa.gov/resources-tools/resources/cybersecurity-scenarios #StopRansomware Guide — https://www.cisa.gov/stopransomware/ransomware-guide