How to run a cybersecurity tabletop exercise that changes readiness

Set one or two objectives

Choose objectives such as incident command, supplier coordination, ransomware containment, cloud recovery or executive communication.

Build the scenario from the organisation’s real services and dependencies. Avoid a movie plot with impossible clues.

• Named learning objectives
• Realistic service and threat path
• Facilitator and observers
• Available plans and contact lists

Use progressive injects

Start with an ambiguous signal, then add technical findings, business impact, media or customer pressure and recovery uncertainty.

Let the team request information. The facilitator should reveal what the organisation could realistically know.

• Detection and declaration
• Containment trade-off
• Legal and communication decision
• Recovery and return-to-service

Observe the operating system

Track who took command, where facts were recorded, how decisions were authorised and whether suppliers were reachable.

Do not score individual performance. Look for system conditions such as unclear roles, inaccessible documents or untested recovery claims.

• Role clarity
• Information flow
• Decision authority
• Technical and business coordination

Turn lessons into verified change

Hold a short immediate debrief and a structured review later. Assign each action an owner, priority, due date and proof.

Retest the most important gaps. Updating a document is not enough when the issue was access, tooling or architecture.

• Action register
• Executive sponsor
• Funding or backlog placement
• Follow-up validation

A practical 30-day field plan

Week one — Design. Objective, scenario, participants and evidence. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Exercise. Injects, decisions and observed handoffs. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Debrief. Strengths, gaps and contributing conditions. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Improve. Owners, funding, validation and retest. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Named learning objectives — owner, current state, last validation and any open exception
• Detection and declaration — owner, current state, last validation and any open exception
• Role clarity — owner, current state, last validation and any open exception
• Action register — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the cyber exercise outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?