Cyber Tabletop Exercises: Decisions Leaders Need to Practise
A named owner is not enough if that person is unavailable
When a sales system stops, technicians may know what to inspect while leaders still need to decide service interruption, alternative work, communications and emergency spending. If everything depends on one unavailable person, a complete contact list is insufficient. A tabletop exercise explores these gaps through scenarios and discussion without attacking live systems.
NIST defines tabletop exercises as facilitated discussions of roles and responses to a scenario. Use them to test shared understanding and whether the plan is workable. A successful discussion does not prove data recovery or achievement of a recovery-time target; technical tests need separate evidence.
Start with a service and decisions, not a tool
Choose one important service, such as order intake or payroll. Define a few decisions to test: who declares an incident, authorizes suspension or resumption, and approves customer messages? Identify deputies and spending or escalation limits. Avoid an untestable goal of proving complete security in one session.
Include the actual business, IT, finance, data and communications roles as relevant. Separate facilitation from note-taking so decisions, unknowns and unowned issues are captured. Bring the current plan, contact list and relevant supplier terms, removing sensitive details unnecessary for the exercise.
A three-stage scenario that exposes decision authority
Begin a hypothetical scenario with an inaccessible sales system and an unknown cause. Ask who confirms impact, which channel works if email fails, and who activates the emergency process. Then introduce waiting customers and an unavailable primary manager. Can the deputy authorize alternative work, and within what limits? “Call IT” is not a complete answer.
Finally, suppose the supplier says the system is available again but recent sales have not been reconciled. What evidence is needed before reopening, who accepts residual risk, and what can be told to customers without asserting unknown facts? This trains decisions; it does not prescribe opening or closing in every real incident.
Assess usable evidence, not confident answers
When someone says a contact list exists, check whether it is accessible without the failed system. When a supplier is expected to help, identify the contact route, contracted scope and unconfirmed conditions. Separate evidenced facts, assumptions and items requiring live tests. “We probably can” is not a passed result.
Keep the exercise from becoming a real incident: use clearly marked simulation material. Do not send messages to customers or outside authorities merely for realism without authorization. Refer notification duties for review under applicable law, contracts and facts; a scenario’s timing is not legal advice.
Finish with improvements that can be verified
NIST SP 800-84 describes debriefing and documenting findings to improve plans. For organizational use, track each gap with impact, owner, deadline and closure evidence: approved deputies, a tested alternate contact channel, or reopening criteria agreed by business and IT.
Do not close a gap just because a document changed. If access was the problem, verify role-appropriate access without unnecessary privileges. If approval authority was unclear, repeat the decision question with the deputy and record whether the agreed limits are understood. Closure should address the original cause.
Use the findings to discuss risk and investment
Leaders should see the most consequential gaps and options: revise authority, train deputies, adjust supplier arrangements or perform further recovery tests. Distinguish role and process fixes from technology purchases so equipment spending does not substitute for missing decision ownership.
For a discussion with Kerwin & Vance within its published technology and risk-related services, bring the current plan, critical services and exercise findings, and confirm the requested scope before engagement. A useful exercise produces verifiable improvements, not certification that cyber incidents or losses cannot occur.
