Ransomware Readiness: The Tabletop Exercise Every Non-Technical Team Should Run

When ransomware hits, the first people to feel it are rarely in the security team. A finance analyst cannot open the payment system. A receptionist sees a ransom note on a shared screen. An HR manager gets a call from a payroll vendor asking why files look strange. Ransomware readiness depends on what these people do in the first hour, and most of them have never practiced it.

A ransomware tabletop exercise fixes that. It is a guided discussion where teams walk through a realistic attack and decide, out loud, what they would do. No systems are touched. No one is tested on technical skill. The goal is to find the gaps in decisions, communication, and authority before a real incident exposes them.

This post explains why non-technical teams belong in the room, how to run the exercise, and what to do with the results.

Why Ransomware Readiness Is Not Only an IT Problem

Most ransomware plans live in a technical document. They cover backups, isolation, forensics, and restoration. Those sections matter. But they assume someone already made the hard business decisions.

Who authorizes shutting down the order system? Who talks to customers? Who decides whether to contact law enforcement or an insurer? Who approves spending money on outside help at 2 a.m.? None of these are technical questions, and none of them belong to the security team alone.

Attackers understand this. They time their attacks for weekends, holidays, and month-end closes. They know that confusion about who decides costs hours, and hours cost money. Every delay helps them.

Non-technical teams also shape how an attack begins. Many ransomware incidents start with a phishing email, a reused password, or a fraudulent login prompt. The person who clicked was not careless. They were busy and the message looked normal. Readiness means preparing for that moment on both sides: preventing the click where possible, and responding well when prevention fails.

What a Tabletop Exercise Actually Is

A tabletop exercise is a facilitated conversation. A small group sits in a room (or on a video call) and a facilitator reads out a scenario in stages. After each stage, the group discusses what they would do and who would do it.

Think of it as a fire drill for decisions. You do not need special software. You need a scenario, a facilitator, the right people, and about two hours.

The exercise works because it forces specifics. Teams often say “we would escalate to leadership.” The facilitator then asks, “Who exactly? How do you reach them at 3 a.m.? What if they are on a flight?” Vague plans fall apart under those questions, which is the point.

A tabletop is not a penetration test or a technical simulation. Nobody needs to know what a command-and-control server is. If an executive can explain how they would run payroll without the finance system, the exercise is working.

Who Should Be in the Room

Invite the people who make decisions or carry out operational tasks during an incident. A strong ransomware tabletop usually includes:

• Executive sponsor: a CEO, COO, or managing director who can approve major decisions.
• IT or security lead: the person who understands the technical response.
• Finance: someone who handles payments, banking contacts, and cyber insurance.
• HR: the person who manages employee communication and, in some cases, internal investigations.
• Legal or compliance: whoever advises on breach notification and regulatory duties.
• Communications or customer service: the voice to customers, partners, and media.
• Operations leads: managers of the departments that would stop working first.

Keep the group between six and twelve people. Fewer than six leaves gaps. More than twelve turns discussion into a lecture.

If your organization works with a managed service provider, invite your MSP contact too. They often hold the keys to backups, remote access, and vendor relationships. Learning that your response depends on one person’s phone number is better done in a workshop than in a crisis.

A Realistic Scenario to Run

Generic scenarios produce generic answers. Use one that matches how attacks actually unfold. Here is a scenario built around a mid-sized logistics company with 280 employees, a head office, and two regional depots. Adapt the details to your own business.

Stage one: the quiet beginning (Friday, 4:40 p.m.)
A dispatcher at one depot receives an email that looks like a shipping document from a regular carrier. She opens the attachment and enters her login when prompted. Nothing seems to happen. She goes home for the weekend.

Ask the group: does anyone know this happened? Would she report it, and would she feel safe doing so? Most teams realize that nobody would know, because the employee saw no problem.

Stage two: the first symptoms (Saturday, 7:15 a.m.)
A weekend warehouse supervisor cannot open the scheduling system. Files on a shared drive show strange extensions. A text file named “READ_ME” has appeared on three desktops. The supervisor calls her manager, who does not answer. She calls the general IT helpdesk number, which goes to voicemail.

Ask the group: who gets the next call? Is there an out-of-hours contact, and does the supervisor know it? Does she have permission to shut the depot’s systems down, or would she wait for approval?

Stage three: the demand (Saturday, 11:00 a.m.)
The IT lead confirms ransomware. Several servers are encrypted, and the attackers claim they have copied customer contracts and driver records. The ransom note demands payment in cryptocurrency within 72 hours and threatens to publish the data.

Ask the group: who is in charge of the response? Who calls the cyber insurer, and what does the policy require before any other action? Who tells the executive team? Does anyone know where the incident response plan is stored, and is it on a server that is now encrypted?

Stage four: the business impact (Saturday, 3:00 p.m.)
Trucks cannot be dispatched. Customers are calling to ask where deliveries are. A journalist emails asking about rumors of a breach. Payroll runs on Monday.

Ask the group: what do you tell customers? Who approves a statement? How do you pay drivers if the payroll system stays down? Which manual processes exist, and when did anyone last test them?

Stage five: the hard decisions (Sunday)
The team learns backups exist but the most recent clean copy is nine days old. Restoring will take several days and lose some data. The attackers offer a “proof of decryption” and a discount for fast payment.

Ask the group: who decides whether to engage the attackers at all? What does legal advise about regulatory notification? What does the executive team need to see before choosing a path? What would you want to know that you do not know yet?

This scenario is not exotic. Variations of it play out every week. The value comes from the conversation each stage produces, not from the story itself.

How to Run the Session

A good tabletop follows a simple rhythm. Plan for roughly two hours.

Set the tone first. Tell the group this is not a test. Nobody is being graded. The only failure is leaving gaps hidden. People speak more honestly when they know the facilitator wants problems found.

Use a neutral facilitator. Someone from the security team can do this, but an outside party often works better. They ask uncomfortable questions without worrying about office politics. They also notice assumptions that insiders no longer see.

Release the scenario in stages. Read one stage at a time. Pause after each for discussion. Do not reveal what comes next, because real incidents do not come with a script.

Ask “who” and “how” repeatedly. Replace “we would notify leadership” with “who calls whom, by what method, and what do they say?” Push for names and phone numbers where possible.

Assign a note taker. Capture every gap, assumption, and disagreement in real time. These notes become your action list.

Add complications. Mid-session, tell the group the CEO is unreachable, or that the primary IT contact is on leave. Real incidents rarely arrive at a convenient time.

Keep the discussion on decisions. Technical rabbit holes eat time. If the conversation drifts into how encryption works, bring it back to what the business needs to do next.

Questions Every Team Should Be Able to Answer

By the end of the session, the group should be able to answer these without hesitation. If they cannot, you have found your priorities.

• Who declares an incident, and who leads the response?
• How do we contact each other if email and chat are down?
• Where is the response plan stored, and is there an offline copy?
• Who contacts our cyber insurer, and what does the policy require first?
• Who talks to law enforcement, regulators, customers, and the press?
• Which systems matter most to the business, and in what order do we restore them?
• How do we run critical processes manually for several days?
• Who has authority to approve emergency spending?
• What is our position on ransom payment, and who makes that call?
• How do employees report suspicious activity, and do they feel safe doing it?

Most organizations find that fewer than half have clear answers on the first run. That is normal. It is also why the exercise is worth doing.

Common Gaps These Exercises Uncover

After facilitating or reviewing enough tabletop sessions, patterns appear. The same weaknesses show up across industries and company sizes.

Nobody owns the decision. Everyone assumes someone else has authority. The first hours disappear in discussion about who should decide.

The plan sits on the affected system. The incident response document lives on a file server or cloud drive that the attack has locked. Teams discover they have no offline copy.

Contact lists are out of date. Phone numbers belong to people who left months ago. Insurance policy numbers are missing. The MSP escalation path is unclear.

Communication has no fallback. If email and the corporate chat platform both go down, teams have no agreed channel. Some switch to personal messaging apps, which creates its own confidentiality risks.

Manual processes do not exist. Finance cannot run payroll without its software. Operations cannot take orders without the booking system. Nobody has written down how to work on paper.

Employees fear reporting. Staff who clicked something suspicious stay quiet because they expect blame. This delay is one of the most expensive gaps, and it is cultural rather than technical.

Legal duties are unclear. Teams do not know which regulators or customers must be notified, or how quickly. Contracts with clients sometimes include notification clauses nobody has read in years.

Notice how few of these are technical. They are about people, authority, and preparation. That is why non-technical teams must be part of the work.

What Security Teams Can Do After the Exercise

The session produces value only if it leads to action. Here is a practical sequence to follow in the weeks afterward.

1. Write up the findings within a week. Keep it short. List each gap, the risk it creates, and a suggested owner.
2. Assign owners and deadlines. A gap without a name next to it will still be there next year.
3. Update the incident response plan. Add the decisions the group made. Fix contact details. Clarify who leads and who approves.
4. Store an offline copy. Print the plan and keep it in a secure location. Store a copy on a device that does not connect to your main network.
5. Build a short role card for each team. One page per department explaining what to do in the first hour. Plain language, no jargon.
6. Test your backups. Confirm they exist, are isolated from the main network, and can actually be restored. Time the restoration.
7. Document manual workarounds. Ask each department to write down how they would operate for three days without their main system.
8. Review your insurance and legal contacts. Confirm what the policy requires and who to call. Store the numbers somewhere accessible.
9. Schedule the next exercise. Run one at least once a year, and again after major changes like a merger, a new platform, or a leadership change.
10. Vary the scenario next time. Try a business email compromise, a supplier breach, or a data theft with no encryption at all.

Small organizations can scale this down. A four-person leadership team and a one-hour discussion still surfaces useful gaps. Something is better than nothing.

The Human Side of Prevention

A tabletop prepares you for response. Prevention still matters, and it also depends on people.

Many ransomware campaigns start with credentials. An employee enters a password on a convincing fake login page. Or a password reused across services appears in a breach, and an attacker tries it against your systems. Either way, the attacker gets in using something legitimate.

Technical controls help. Multi-factor authentication, email filtering, endpoint protection, and network segmentation all reduce risk. But no control catches everything, and every control has a person somewhere near it.

That means awareness training needs to be realistic, repeated, and respectful. A single annual slideshow does not change behavior. Employees remember what they practice. They also remember how they were treated when they made a mistake. Teams that punish reporting teach people to hide problems.

The tabletop exercise reinforces this. When executives hear that an employee would hesitate to report a suspicious click, they understand the cultural fix that follows. Leadership tone shapes whether people speak up in the first critical minutes.

Where Cruxroot Fits

Tabletop exercises show you where your people and processes need support. Cruxroot helps you close some of those gaps with tools your teams can use day to day.

Phishing simulations let employees practice spotting realistic lures in a safe setting. The scenarios reflect the kinds of messages that start real incidents, such as fake shipping notices, invoice requests, and login prompts. Results show where extra coaching would help, without turning the program into a blame exercise.

Dark web monitoring watches for your organization’s credentials appearing in leaked data. If an employee’s password turns up in a breach, you can act before an attacker tries it. This addresses one of the most common ways attackers get their first foothold.

Gamified training keeps learning short, engaging, and repeatable. Employees build habits through practice rather than a once-a-year lecture. Over time, that builds the reporting culture that tabletop exercises so often reveal as missing.

None of these tools replaces a good response plan or a well-run exercise. They work together. The tabletop finds the gaps. Training and monitoring reduce the odds of those gaps being tested by a real attacker.

Cruxroot is available through our MSP and reseller partners, who can help you fit these tools into your existing security program and support your tabletop planning.

Conclusion

Ransomware readiness is not just a technical project. It is a set of decisions, relationships, and habits that every department shares. The first hours of an incident are often won or lost by people who have never opened a security console.

A tabletop exercise gives those people a chance to practice. It exposes weak points in a safe setting and builds confidence before pressure arrives. Start small if you need to. Pick a scenario, invite the right people, and spend two hours talking through the worst day. Then fix what you find, and run it again next year.

Check our latest the blog regarding Reporting Rate vs. Click Rate: Which Metric Predicts Real Risk?