Ransomware Tabletop Exercises That Surface Real Decision Gaps

A ransomware tabletop should reveal where a decision or dependency would fail under pressure. Choose a narrow objective before writing the scenario: can the business authorize containment of a revenue-producing service, and can responders explain the recovery options?

NIST's incident response recommendations connect preparation and improvement with ongoing risk management. The exercise below is a suggested discussion format. It does not demonstrate that technical recovery works unless the team separately performs and records the relevant tests.

Prepare the participants and boundaries

Invite the incident lead, IT operations, an affected service owner, an executive decision-maker, and the appropriate legal or communications contacts. Assign a facilitator and note-taker. Tell participants that the scenario is hypothetical and that no production changes should be made during the discussion.

Bring the current contact list, a service dependency map, recovery test results, and examples of the logs responders can access. Use sanitized records. The exercise should test the team's real process without exposing credentials or customer data.

Use four decision points

This hypothetical sequence can be adapted to a company with a customer-ordering service:

Inject	Question to resolve	Evidence to request
Endpoint alerts suggest credential theft	Who leads the investigation and what is the initial scope?	Available endpoint and identity events, escalation record
A suspected administrator also manages backups	Which access must be restricted and who approves it?	Role assignments, session controls, independent recovery access
Containment would stop new orders	Who accepts the outage and what alternatives exist?	Service impact, manual processing option, containment authority
A restore copy is available but its integrity is uncertain	What must be checked before reconnection?	Restore history, compromise window, application-owner validation

Introduce each inject after participants have recorded a decision. Do not reward confident guesses. If someone says a backup is safe, ask where the protection and last restore evidence can be found.

Record uncertainty without turning it into failure theater

The facilitator should distinguish an unavailable capability from missing documentation or an absent participant. Those require different fixes. "We cannot revoke this token" is a technical gap; "only one person knows how" is an operational dependency.

Ask what would change the decision and when the team would revisit it. If logs cannot establish the compromise period, capture how that uncertainty affects the proposed restore point. If legal advice is needed, identify the actual escalation path rather than improvising notification rules in the room.

Keep discussion respectful. Staff should be able to name a limitation without pressure to invent a capability the business has not funded or tested.

Make the follow-up verifiable

Each finding needs an owner, due date, and acceptance check. For example, an uncertain isolation path should lead to an authorized technical test in a safe environment, a documented approval role, and an assessment of affected business services.

A missing backup credential should lead to a protected alternate access procedure and a recovery test, not a password pasted into the runbook. A weak executive update should lead to a revised brief and a short replay of the decision.

At the follow-up meeting, review evidence of completed changes and repeat the unresolved decision points. Preserve the exercise scope and limitations with the findings. That record supports a more honest readiness assessment than a certificate showing that the team attended a tabletop.