# Incident tabletop: rehearse decisions while the systems are still healthy Canonical: https://www.web3sec.news/blog/incident-tabletop-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Incident readiness Published: 2026-11-08 Updated: 2026-11-08 A repeatable exercise format for founders, engineering, security, support and the people authorized to stop operations. ### Diagram: Respond with evidence, ownership and feedback. Contain the consequence while preserving a usable record of what happened. ![The response loop moves from detection to evidence preservation and triage, containment, investigation, recovery, and lessons verified through follow-up controls. Evidence handling and communications have named owners throughout.](https://www.web3sec.news/diagrams/incident-response-loop.svg) [Full-size SVG](https://www.web3sec.news/diagrams/incident-response-loop.svg) · [PNG download](https://www.web3sec.news/diagrams/incident-response-loop.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Choose the decision to test Give the exercise an accountable sponsor and a facilitator who is not also responsible for defending every current process. Select a concrete objective: can the team stop a malicious deployment, recover a critical identity, pause treasury signing or restore a database? Keep the objective small enough that a discussion can produce evidence and changes. A dramatic scenario without a testable decision usually produces confident conversation rather than operational learning. Invite the people who hold the actual authority, including support, product and vendor contacts where appropriate. Use current runbooks and contact lists. CISA’s exercise-planning handbook provides a structured approach to objectives, facilitation and follow-up; NIST’s response guidance reinforces preparation and learning across risk management. Our suggested format below is an adaptable operational exercise, not a certification or compliance assessment. ## Introduce uncertainty in stages Begin with a realistic signal, such as a suspicious cloud role assignment or a wallet proposal no signer recognizes. Ask who receives it, what evidence they need and what they may suspend. Require participants to locate the real console, documented role or provider contact without making production changes. Record assumed capabilities that nobody can demonstrate or identify an owner for. Add a second inject: the normal administrator is unavailable, the chat account may be compromised or a customer posts an unverified allegation. Ask whether the team changes communication channels, how it verifies identities and who approves public statements. Keep simulated messages clearly marked and contained within the exercise so the rehearsal does not create an avoidable real-world incident. ## Measure decisions and dependencies Record the time from signal to acknowledgment, decision, authorized containment and recovery plan. Capture the information requested and whether it is actually available. Distinguish the moment someone says they would revoke a token from the moment an authorized operator demonstrates the documented revocation path in a safe environment. Expose missing roles, vendor dependencies and evidence-retention assumptions. Require a recovery decision as well as containment. What proves the attacker’s access is gone? Which artifact, identity or data backup is trusted? Who accepts residual uncertainty and authorizes reopening? Ask support to draft a short customer update that states known scope, protective action and next update time. Avoid speculative attribution or promises of recovery that the technical evidence does not support. ## Turn findings into changes and retest Close with a short factual review of what worked, what failed and what depended on an undocumented assumption. Assign each improvement an owner, due date and observable completion condition. “Improve monitoring” is not a sufficient action; “route this specific role-change event to the backup on-call and demonstrate acknowledgment” can be tested. Keep unresolved acceptance decisions visible to the business owner. Retest the most important failed step after remediation using a smaller exercise. Save updated contact lists and runbooks somewhere reachable if the primary identity service fails. Rotate scenarios across cloud, device, community and treasury risks over time. The useful outcome is fewer untested decisions and dependencies, not a perfect score achieved by giving participants the expected answers in advance. ## Controls to take away - An exercise should expose assumptions, not reward confident answers. - Recovery authorization deserves as much rehearsal as containment. - Every improvement needs an owner and a testable completion condition. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Choose one operational decision and a measurable objective. - [ ] Invite the people who can actually authorize containment. - [ ] Introduce unavailable staff and suspect communications. - [ ] Measure demonstrated actions rather than stated intentions. - [ ] Assign observable fixes and retest the failed step. ## Sources & further reading - [CISA: tabletop exercise planner handbook](https://www.cisa.gov/sites/default/files/2023-01/2_-_ctep_exercise_planner_handbook_2021_final_508.pdf) - [NIST SP 800-61 Rev. 3: incident response and risk management](https://csrc.nist.gov/pubs/sp/800/61/r3/final) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)