Cybersecurity Tabletop Exercise Scenarios: A Quarterly Incident Readiness Workbook
A useful cybersecurity tabletop exercise tests decisions, communication, and recovery under pressure without putting production systems at risk. This workbook gives security and business teams a repeatable format for running quarterly exercises, with scenario cards, role assignments, timed injects, decision points, an observer scorecard, and an after-action tracker.
Overview
A tabletop exercise is a guided discussion in which participants respond to a simulated security incident. It is not a technical penetration test, a compliance performance, or a contest to identify the person who made a mistake. The objective is to discover whether people, processes, technology, and authority lines work together when information is incomplete.
Keep the exercise focused. A session lasting 60 to 120 minutes can examine one primary incident and several complications. Use realistic assumptions about the organization’s systems, suppliers, staffing, communication channels, and decision-making authority. Do not use live credentials, real customer data, or an unannounced exercise that could be mistaken for an actual emergency.
Before the session, appoint four core roles:
- Facilitator: Presents the scenario, controls the pace, and asks what participants would do next.
- Participants: Represent security, IT, infrastructure, legal, privacy, communications, executive leadership, customer support, and business operations as appropriate.
- Observers: Record decisions, unanswered questions, time delays, and dependencies without steering the discussion.
- Exercise owner: Confirms the scope, protects the schedule, and assigns follow-up actions after the session.
Set ground rules at the start: assume good intent, distinguish known facts from assumptions, avoid blame, and record unresolved issues instead of debating them indefinitely. If a real incident emerges during the exercise, stop and route it through the organization’s incident response process.
What to track
Track whether the team can make and explain decisions, not merely whether it knows security terminology. The following scenario cards can be rotated across quarterly exercises.
Scenario 1: Ransomware incident
Starting condition: Several users cannot access shared files, an endpoint detection alert shows suspicious encryption activity, and one server is offline. Injects: A backup job reports an error; an executive asks whether systems should be shut down; an employee receives a ransom demand; a critical business unit says it cannot operate manually. Decision points: Which systems are isolated? Who authorizes containment? How is evidence preserved? When are continuity procedures activated? What information is safe to share internally?
Scenario 2: Business email compromise
Starting condition: A finance employee receives a payment-change request that appears to come from a senior leader. A transfer may already be pending. Injects: The mailbox shows a suspicious forwarding rule; the alleged executive is unreachable; a supplier confirms that its contact details were changed. Decision points: Who pauses or verifies the payment? How are sessions and credentials contained? Which accounts require review? Who communicates with the bank, supplier, and affected employee?
Scenario 3: Cloud-service disruption
Starting condition: A major hosted application is unavailable, and the provider’s status page offers limited detail. Injects: Administrators cannot access the normal console; a backup authentication path fails; customer support reports a rise in complaints. Decision points: What is the approved fallback process? Which service-level, continuity, and communication commitments apply? How does the team avoid unsafe workarounds while restoring essential operations?
Scenario 4: Vendor breach
Starting condition: A technology supplier reports unauthorized access to an environment that may contain company or customer information. Injects: The supplier’s first notice is incomplete; procurement cannot locate the latest contract; business owners want to keep the service running. Decision points: Who validates the notification? What data and systems are in scope? Which access tokens or integrations should be reviewed? Who coordinates legal, privacy, customer, and regulator communications?
Scenario 5: Lost or stolen device
Starting condition: An employee reports that a laptop or mobile device containing business information is missing. Injects: The device has not connected recently; its encryption status is unclear; the employee delayed reporting the loss. Decision points: Can the device be locked or wiped? What accounts and tokens require revocation? What evidence is needed to assess exposure? What support should the employee receive?
Scenario 6: Data exfiltration
Starting condition: Monitoring identifies unusual outbound transfers from an internal system. The destination is unfamiliar, but the data classification is not immediately clear. Injects: A privileged account appears in the logs; a customer asks whether information was exposed; the suspected user is scheduled to leave the company. Decision points: How is access contained without destroying evidence? What records are preserved? Who determines whether personal or regulated data is involved? When does the team begin notification planning?
For every scenario, record the same variables: time to identify the incident, time to assign an incident lead, systems and data in scope, containment authority, backup or continuity status, communication owner, evidence owner, external dependencies, and decisions that required executive approval.
Cadence and checkpoints
Run a tabletop at least quarterly, changing the scenario or participant mix so that the exercise does not become a memorized script. A practical quarterly cycle is:
- Week 1 — Prepare: Choose the scenario, define the learning objectives, confirm participants, review the incident response plan, and identify relevant contracts, escalation paths, and continuity procedures.
- Week 2 — Validate: Check contact details, system ownership, backup assumptions, privileged-access procedures, communication channels, and any reporting or notification requirements that may apply to the organization.
- Week 3 — Exercise: Begin with a short initial fact pattern, then introduce an inject every 10 to 20 minutes. Ask participants to state the next action, owner, deadline, and evidence needed.
- Week 4 — Improve: Publish the after-action record, prioritize gaps, assign owners and due dates, and update the relevant plan or runbook.
Use checkpoints during the session rather than waiting for the final discussion. At the 15-minute mark, ask whether an incident lead and communications lead have been named. At the midpoint, ask what is known, unknown, and being assumed. Near the end, ask what would prevent recovery in the next 24 hours and which decision cannot be made without additional information.
Keep a simple action log with these columns: finding, risk, corrective action, owner, target date, status, validation method, and date closed. A finding is not closed merely because a meeting occurred; closure should include evidence such as a tested contact tree, a revised procedure, a restored backup, or a completed access review.
How to interpret changes
Compare each exercise with the previous one. Improvement may appear as faster role assignment, clearer escalation, fewer unresolved dependencies, or more precise communication—not only faster technical containment.
Classify observations into four categories:
- Capability: The organization lacks a control, tool, trained role, or recovery option.
- Clarity: A process exists but ownership, authority, or decision criteria are unclear.
- Coordination: Teams work separately, duplicate effort, or rely on an unavailable person or system.
- Evidence: The team cannot quickly prove what happened, what data was involved, or which action was taken.
Prioritize findings by potential business impact, likelihood of recurrence, time sensitivity, and effort to reduce the risk. A small contact-list error may deserve immediate attention if it could delay containment. A complex architecture change may require a longer plan, but it should still have an interim workaround and accountable owner.
Observers can score each capability from 0 to 3: 0 means absent or unknown, 1 means informal and person-dependent, 2 means documented but inconsistently tested, and 3 means documented, assigned, and demonstrated during the exercise. Use the score to identify trends, not to rank individuals. Repeated scores of 0 or 1 indicate a readiness gap; a score of 2 should prompt testing; a score of 3 should still be reviewed when systems or personnel change.
For communication planning, the Cyber Incident Communications Matrix can help teams map customer, employee, and regulator notification responsibilities. For vendor scenarios, use the Third-Party Cyber Incident Response template to structure escalation questions.
When to revisit
Review this workbook and your exercise design quarterly, and sooner after a significant change. Revisit the scenarios when the organization adopts a new cloud service, changes authentication or backup architecture, acquires another business, adds a critical supplier, changes incident leadership, or experiences a real security event. Also review the exercise when internal reporting procedures, contractual obligations, or applicable privacy requirements change. The details of those obligations should be confirmed for the organization’s locations and data rather than assumed from an old exercise.
Before each session, refresh the scenario’s systems, suppliers, contact paths, likely attack techniques, and recovery assumptions. Remove details that no longer match the environment. After the session, update the action tracker and set a date to test the most important fixes.
To run the next exercise, choose one scenario above, name the facilitator and incident lead, define three learning objectives, prepare three to five injects, and invite the teams that would actually make the decisions. End with no more than five priority actions, each with an owner and validation date. That discipline turns a discussion into an incident readiness program that can be measured and improved over time.
