Run a ransomware tabletop exercise that tests management decisions, business continuity, communications and recovery ownership without live disruption.
A ransomware incident creates decisions that technical staff cannot make alone. Someone must determine which business activities can pause, who may communicate with customers and what evidence is required before a recovered service is trusted. Managers also need to understand that a working backup does not automatically answer questions about compromised accounts, exposed information or the order in which services should return.
A tabletop exercise lets the organisation practise these decisions without disrupting live systems. Participants discuss a fictional scenario, identify the actions they would authorise and explain how they would obtain the information needed. The exercise should reveal gaps in coordination and recovery planning, rather than test whether managers can diagnose malware.
Define a small, useful exercise boundary
Choose a recognisable business service and a limited scenario. An order-processing application, shared project folder or branch file service can provide enough complexity for a first exercise. Avoid trying to simulate every possible incident in one session. A focused discussion is more likely to produce changes the organisation can actually implement.
State the objectives in advance. These might include confirming who declares an incident, checking access to emergency contacts and agreeing how business priorities influence recovery. Define what is outside scope, such as live technical isolation, malware analysis or interaction with an attacker.
Make the exercise label visible on every handout and message. No participant should mistake a fictional update for a real incident report. Do not change production settings, contact customers or send messages to external organisations as part of the scenario unless those separate activities are explicitly planned and authorised.
Invite people who own the decisions
Include a business sponsor, an incident coordinator, a technical representative, relevant department owners and someone responsible for communications. Depending on the organisation, legal, compliance, human resources or an external support provider may also need a role. The purpose is to include the people whose authority would be required during a real interruption.
Appoint a facilitator who can keep the discussion moving without supplying every answer. A separate recorder should capture decisions, assumptions, unanswered questions and action owners. Participants need room to think; asking one person to facilitate, answer technical questions and take complete notes can weaken the exercise.
Identify substitutes. An incident may occur when the usual manager or administrator is unavailable. Ask which decisions a deputy can make and where that authority is recorded. A response plan that works only when one particular person is present has a significant operational dependency.
Prepare a believable starting picture
Describe the business context briefly. For example, a fictional distribution company is preparing the day’s dispatch paperwork when several users report that shared files will not open. The service desk receives an unusual message on one workstation, and the status of the central application is uncertain. This is an illustrative exercise, not a Maxicon customer case.
Provide only the information participants would reasonably know at that stage. Do not announce the full technical cause or guarantee that backups are clean. Uncertainty is part of the management challenge. The facilitator should distinguish confirmed facts, reported observations and assumptions throughout the discussion.
Give participants access to their real response contacts, business continuity procedures and recovery priorities, with sensitive details handled appropriately. The exercise can then reveal whether those documents are usable. A plan that exists but cannot be located during the session needs attention.
Round one: receive the report and establish coordination
Ask who receives the initial report, who decides that an incident process is required and how the decision is recorded. Identify the channel used to coordinate if normal email or collaboration tools may be affected. The alternative should be approved and accessible without creating an uncontrolled spread of sensitive information.
Discuss what staff are told immediately. They need clear reporting instructions and guidance from the authorised response team about affected devices and services. Managers should avoid improvising technical containment steps. The technical lead should explain how approved isolation decisions would be made and who has authority to carry them out.
Record the first priorities: protecting people, limiting further disruption, preserving relevant evidence and establishing reliable information. Ask who maintains the incident timeline and how conflicting reports will be reconciled. Without a common record, different departments can begin acting on incompatible assumptions.
Round two: introduce business interruption
Add a new scenario update: the affected service is unavailable and a scheduled customer commitment is approaching. Ask which activities can continue safely, which should pause and who approves temporary workarounds. A manual process should preserve essential controls rather than bypassing approvals simply because the normal application is down.
Examine the information required for continuity. Staff may need an approved order list, contact details or the latest dispatch status. Determine whether those records are available through an independent, authorised route. Do not assume that a printed procedure is useful if it refers to information accessible only through the unavailable service.
Define how temporary records will be reconciled later. A handwritten order or offline spreadsheet can create duplicate or conflicting transactions when the application returns. Assign an owner for validating and entering the backlog, and identify which activities should remain paused until that reconciliation is complete.
Round three: challenge the recovery assumptions
Tell participants that a backup appears available but has not yet been validated for this incident. Ask what evidence the technical team must provide before recovery begins and before users return. The discussion should include the suitability of the recovery point, required dependencies and confidence in the environment being restored.
Managers should explain the business consequences of missing transactions between the recovery point and the interruption. Technical staff can describe available options, but the business owner must assess whether the resulting record state is workable. A recovery target is meaningful only when people understand what the associated data loss would require them to reconstruct.
Explore recovery order. Identity, network services, databases and applications may depend on one another. Ask whether the documented priority list reflects those dependencies. The most important business application cannot necessarily be restored first if the services it requires are unavailable.
Round four: add uncertainty about information exposure
Introduce a report suggesting that sensitive information may have been accessed, while making clear that the facts remain unconfirmed. Ask who coordinates investigation, who obtains specialist advice and who decides on external communications. Participants should distinguish a confirmed finding from an allegation or incomplete technical indication.
Do not turn the tabletop into improvised legal advice. Record the need for appropriate advisers to assess notification and reporting requirements based on the actual circumstances and applicable obligations. Prepare the internal escalation route and information needed for that assessment before a real incident occurs.
Discuss customer and staff messages. A useful holding statement can acknowledge service disruption and explain the approved contact route without speculating about causes or promising a recovery time that has not been established. Identify who approves updates and how inconsistent messages from different departments will be prevented.
Round five: decide when the service can return
Recovery is a decision with technical and business conditions. Ask who confirms that the environment meets the approved security checks, who validates the application and who accepts the business record state. These responsibilities may belong to different people, and each should know what evidence is expected.
Use representative business tests. Can an authorised user complete a transaction, locate the required attachment and produce the necessary output? Are access permissions appropriate? Does the restored service connect only to approved dependencies? Keep the exercise discussion at the decision level; actual technical validation belongs in the recovery procedure and controlled testing.
Plan a staged return where appropriate. A limited user group or restricted workflow can provide evidence before broader use. Define how the team will detect new problems, communicate them and decide whether to pause the return. The end of the outage should not be declared simply because a login screen is visible.
Turn observations into assigned improvements
At the end, ask each participant what was unclear, unavailable or dependent on an assumption. Separate documentation gaps from missing capability. An outdated telephone number needs a different response from a recovery design that cannot meet the business’s minimum operating needs.
Create an action record with an owner, due date and completion evidence for each improvement. Examples include confirming deputy authority, testing an independent contact route or performing a controlled restore validation. Prioritise a manageable number of changes rather than producing an ambitious list that will not be completed.
Schedule a focused follow-up exercise after the key actions are addressed. Reuse the relevant scenario point to verify that the gap has actually closed. Attendance and a completed meeting are not evidence of readiness by themselves; the useful result is a stronger response process and demonstrated improvements.
Maxicon’s disaster recovery solutions page is a relevant starting point for discussing recovery dependencies and preparedness. When you contact Maxicon, bring the exercise objectives, service priorities and unresolved questions. Keep sensitive incident details within an appropriately agreed communication route.
Frequently asked questions
Does a tabletop exercise test whether backups work?
It tests decisions and assumptions about recovery, but it does not replace a controlled restore test. The discussion may reveal that restoration evidence is missing or outdated. Assign a separate technical validation activity with a defined scope, approval and business acceptance criteria.
Should we use real ransomware in the exercise?
No. A management tabletop uses fictional updates and discussion. It does not require malicious software or changes to live systems. Any separate technical exercise needs its own authorised plan, controlled environment and qualified personnel; it should not be improvised during the meeting.
How detailed should the scenario be?
Include enough context to make decisions realistic, then reveal information in stages. Too much detail can turn the exercise into reading a script. Focus on the uncertainties that affect ownership, continuity, communications and recovery, while keeping the number of systems manageable.
Can an external support provider participate?
Yes, where their role and agreement make participation appropriate. Clarify what they would actually do during an incident and which decisions remain with the business. Use the exercise to identify contractual or operational gaps rather than assuming the provider owns every response activity.
What is the most useful evidence after the session?
Keep the scenario, participant roles, decision record, unresolved assumptions and assigned improvements. Then collect evidence that important actions were completed and tested. The strongest outcome is a demonstrable change in readiness, such as a verified contact route or a recovery procedure validated against business tasks.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s backup and disaster recovery guide.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
