How to Run a 60-Minute Ransomware Tabletop Before a Real Incident Hits

Blue and white graphic with a clipboard icon and the text: “A plan doesn’t save you. Practice does. Run a 60-minute tabletop.” Signed Wylie Blanchard.

Most organizations can point to an incident response plan.

Fewer can tell you, without hesitation, who is in charge, what gets isolated first, who approves emergency spending, and who owns the first message to staff when systems go down.

That gap matters.

In a ransomware event, the first hour is rarely about having perfect information. It is about clear ownership, fast decisions, and calm coordination across IT, operations, legal, communications, and compliance.

If you lead uptime, security, or operational risk in healthcare or an SMB, a short tabletop exercise can expose weak spots before an attacker does. The agenda below is simple enough to run tomorrow and useful enough to improve how your team responds under pressure.

The real test is not the document, it is the response

A written plan has value. But a plan that nobody has practiced often breaks down in the first few minutes of a real incident.

People hesitate.
Decision rights get fuzzy.
Too many people try to lead.
Not enough people know who can approve what.
Critical calls get delayed because nobody is sure who owns them.

That is why tabletop exercises matter. They turn policy into action. They show you whether your team can make decisions with time pressure, uncertainty, and real operational tradeoffs.

A simple ransomware scenario to run with your team

Use this prompt to start the discussion:

It is 7:00 AM. Staff cannot log in. IT confirms ransomware on three servers. What happens next?

This scenario works because it gets to the point quickly. No long setup. No complicated backstory. Just a realistic trigger that forces the team to make decisions.

A 60-minute tabletop agenda you can run tomorrow

0 to 10 minutes: Name the Incident Commander, confirm scope, set decision authority

Start with the basics.

Who is leading the response?
What do you know so far?
What decisions can be made immediately, and who can approve them?

If your team cannot identify the Incident Commander within seconds, that is a signal. You may have a written response plan, but not a usable one.

10 to 25 minutes: Decide what stays up, what gets isolated, and how to stop the spread

This is where operational tradeoffs show up fast.

Which systems are critical enough to protect at all costs?
Which systems need to be isolated now?
Who has authority to shut down access, disconnect devices, or pause workflows?

The goal here is not technical perfection. The goal is to contain the issue without making the disruption worse.

25 to 40 minutes: Call the outside partners and approve emergency spend

Many organizations lose time because they know they need outside help, but have not worked through the order of operations.

This is the moment to confirm:

  • Who contacts cyber insurance
  • Who contacts outside counsel
  • Who engages forensics
  • Who can approve emergency spending
  • Whether current contact information is easy to access

If those details live in one person’s inbox or memory, the exercise is doing its job by exposing that risk.

40 to 55 minutes: Assign one spokesperson and draft the first messages

Incidents create confusion fast, especially when employees, customers, patients, partners, or regulators may be affected.

Choose one spokesperson.
Draft the first internal message.
Set the external holding statement.
Clarify what would trigger notification requirements.

This part matters because silence creates its own problems. Teams need to know what to say, what not to say, and who owns the message.

55 to 60 minutes: Debrief and assign the top five fixes

Do not end the session when the clock runs out.

End it by capturing the top five issues the exercise exposed, assigning owners, and setting due dates.

Without that step, the tabletop becomes a calendar event instead of an operational improvement.

Keep the roles simple

You do not need a long cast of characters to make this exercise useful. Start with the core group:

  • Incident Commander: Owns the response and decision flow
  • IT Lead: Confirms technical scope and containment options
  • Legal Counsel: Advises on privilege, notification, and exposure
  • Cyber Insurance Contact: Helps activate the policy and required steps
  • Communications Lead: Owns internal and external messaging
  • Privacy or Compliance Lead: Assesses reporting thresholds and regulatory obligations
  • Operations or Clinical Lead: Brings the business or care-delivery impact into the room

In healthcare, that last role is especially important. Technical containment decisions can affect patient flow, scheduling, documentation, and other frontline operations. The response cannot live inside IT alone.

What good leaders should ask after the exercise

A short debrief can surface more value than the scenario itself. Ask questions like:

  • Could everyone identify the Incident Commander right away?
  • Were decision rights clear, or did people talk around ownership?
  • Did the team know which systems were truly mission-critical?
  • Were outside contacts, including insurance and counsel, current and accessible?
  • Did anyone discover a hidden dependency that would slow containment?
  • Were communications and notification triggers clear?
  • What five fixes would reduce confusion the fastest?

These are leadership questions as much as technical ones.

Why this matters even more in healthcare and other regulated environments

In healthcare, ransomware is not just a security issue. It can affect access to systems, staff coordination, patient communications, privacy obligations, and continuity of care.

The same is true in other regulated settings such as finance and education. When downtime intersects with sensitive data, reporting thresholds, and operational disruption, vague plans become expensive very quickly.

That is why a tabletop should test more than the technical response. It should test governance, escalation paths, communication discipline, and ownership under pressure.


The goal of a tabletop is not to prove your team is perfect.

The goal is to find confusion before a real incident does.

One focused hour each year can turn a static plan into something your team can actually run under pressure.

If you own uptime or security in healthcare or SMB environments, make this a recurring exercise, not a one-time discussion. Repetition is what builds confidence, speed, and better decisions when the stakes are real.

If this topic is part of your role, join my newsletter for one practical playbook each week on security, continuity, and IT leadership.