If your tabletop ends with everyone feeling good, it may have failed. In healthcare, a cyber exercise should test patient care under pressure, not just whether people can talk through a plan. That matters because 67% of respondents in a 2025 Ponemon healthcare study said ransomware hurt patient care, and HHS data tied business associates to 212 major breaches affecting 131+ million people.

Here’s the short version: I’d judge a strong tabletop by whether it forces hard decisions, includes clinical and vendor roles, logs proof in real time, and ends with named fixes and retest dates.

What this article says you should do:

  • Build the scenario around care disruption, not a generic IT alert
  • Use evolving injects and incomplete information
  • Put the people with decision rights in the room
  • Test vendor contacts, downtime steps, and escalation paths
  • Record timestamps, decisions, delays, owners, and missing info
  • Turn each gap into a risk statement, action item, and retest

A weak exercise tests memory. A strong one tests whether your team can keep patients safe when systems go down.

Mastering Tabletop Exercises: Building Incident Response Skills Through Practice

Why Healthcare Tabletop Exercises Miss Real Gaps

Most tabletop exercises test conversation, not readiness. That sounds harsh, but it’s often true. When the scenario is tightly scripted, the wrong people are in the room, and nobody records what happened in a usable way, the exercise misses the gaps that matter.

Over-Scripted Scenarios Hide Decision Weaknesses

When people know the scenario ahead of time, they don’t respond to the problem. They respond to the script. Instead of making live calls under uncertainty, they answer expected prompts and move from cue to cue.

That’s not how real incidents start.

In an actual event, the first signs are usually messy and partial: a few workstations behaving oddly, a vendor sharing a suspicious update, medication records going offline without much warning. At that point, teams still have to decide what to do. Do they isolate a system? Divert patients? Stop part of a clinical workflow? Those are the hard calls, and they happen before anyone has the full picture.

MITRE’s medical-device cybersecurity playbook points directly at this problem. It recommends dynamic events, including unexpected changes, actions by outside parties, and situations where participant responses do not produce the expected result, to expose these gaps.[3] If the exercise never creates that kind of uncertainty, it won’t show the weak points that tend to appear during a live incident.

Those weak points show up only when the scenario creates actual pressure.

The Wrong Participants Leave Clinical and Vendor Gaps Untested

If the exercise includes only IT and security, it cannot test clinical readiness. That setup may look fine on paper, but it leaves major blind spots.

If nursing leadership isn’t there, no one checks whether downtime procedures work on the unit floor. If legal and compliance are missing, breach-notification decisions don’t get tested. If vendor contacts aren’t part of the exercise, the team is simply assuming those relationships will hold up under stress.

Third-party risk is easy to underplay, yet the numbers are hard to ignore. HHS’s HIPAA Breach Reporting Tool listed 677 major health-data breaches affecting more than 182.4 million people as of December 20, 2024. Business associates were involved in 212 breaches, about one-third of the total, and those incidents affected more than 131 million people, or about 75% of the individuals affected by major breaches overall.[2]

That changes the picture. Vendor coordination isn’t a nice extra. It’s part of the response.

Once the right people are in the room, the next question is simple: did the team record what actually happened?

No Evidence Capture Means Findings Disappear After the Exercise

If observations aren’t logged, they fade fast. Someone may note that communication felt slow or that the team struggled with downtime steps, but that kind of comment rarely leads to action on its own.

A useful observation is specific:

At 7:10 a.m., nursing leadership could not identify the current medication-administration downtime workflow; pharmacy had an outdated paper-form location; no owner was assigned to reconcile orders after restoration.

That level of detail matters. It ties the problem to a time, a function, and a gap the team can fix.

Only timestamped decisions, named owners, and missing evidence can support remediation. Without structured documentation, there is no record to fix - no basis for assigning ownership and no standard to retest against.[1]

That record is what turns an exercise into a risk-management input.

To surface these gaps, the scenario must force clinical consequences, not just discussion.

Design a Scenario Around Clinical Consequences

Scripted Tabletop Exercise vs. Realistic Cyber Exercise in Healthcare

Scripted Tabletop Exercise vs. Realistic Cyber Exercise in Healthcare

A vague tabletop built around a generic cyberattack doesn't tell you much. The exercise gets far more useful when it tests care continuity under pressure. In healthcare, the point isn't just to see how the security team reacts. It's to see whether the people and processes that protect patients can still function when core systems fail.

Start With a Scenario That Disrupts Care Delivery

Build the opening around a care-delivery failure, not a technical alert. Skip the generic “malware detected” setup. Use something closer to what staff would feel on the floor: Pharmacy verification is unavailable. Medication orders are backing up. The EHR is inaccessible in the emergency department during peak morning volume.

A simple time-based escalation works well here. At 8:30 a.m., the EHR goes down across the ED, inpatient units, and ambulatory clinics. By 9:00 a.m., the lab interface stops transmitting results, and pharmacy reports medication order delays. By 9:30 a.m., executives are deciding whether to divert ambulances and postpone elective procedures.

That kind of progression keeps the session anchored to the main issue: can the organization deliver care safely while systems are down? The March 2024 Change Healthcare attack showed how fast a vendor outage can turn into both a clinical and financial crisis: 74% of nearly 1,000 hospitals reported direct patient-care impact, and 94% reported financial disruption.[5]

Define Objectives, Injects, Dependencies, and Success Criteria Before the Exercise

Set pass conditions before the exercise begins. If you don't, you end up with opinions instead of proof.

Keep the exercise focused on four to six observable objectives. These should be actions participants must take, not things they say they would do. For example:

  • Activate downtime procedures within 15 minutes of an EHR outage
  • Identify the executive decision owner
  • Contact a critical vendor through a verified channel
  • Communicate a safe medication workflow to affected units

Each objective needs a pass condition tied to a documented action.[1]

Release injects about every 10–15 minutes. Each one should add new information that changes the situation: an incomplete backup, a vendor that can only provide a ticket number, a media inquiry, or a law enforcement request.[4] Give each person only the information their role would have at that moment. Don't fill in missing contacts. Don't make up workarounds. If a procedure is missing or a contact list is out of date, the exercise should expose that gap, not hide it.

Scripted Discussion vs. Realistic Exercise: A Side-by-Side Comparison

The difference becomes obvious when you put the two formats next to each other:

Dimension Scripted discussion Realistic exercise
Scenario predictability Participants know the likely storyline Participants receive evolving, incomplete information
Information availability Facts and contacts are supplied or assumed Participants must locate current procedures, contacts, and authorities
Participant behavior Roles describe intended responsibilities Participants perform or demonstrate required decisions
Decision pressure Discussion proceeds at a comfortable pace Injects impose deadlines tied to patient safety and operational impact
Vendor involvement Coordination is discussed hypothetically Participants use actual escalation paths and test vendor responsiveness
Clinical impact Cyber effects remain abstract Outages connect directly to medication, imaging, or patient flow
Outputs General observations and opinions Documented decisions, scored gaps, named owners, and retest criteria

When the scenario starts forcing real decisions, the next thing to test is whether the right roles, contacts, and evidence are actually in the room.

Get the Right Roles and Evidence Into the Room

Once the scenario feels real, the next check is simple: are the right people actually in the room? A good inject by itself won’t tell you much if the people who would make the call in a live event aren’t there. And even with the right people present, the exercise still falls short if nobody records what happened.

Select Participants Based on Decisions and Dependencies, Not the Org Chart

Start with a decision-and-dependency map, not a list of names. For each major inject, pin down four things: who approves the action, who carries it out, who advises, and who feels the impact. In a ransomware event hitting an EHR, that can mean incident command, IT/security, clinical operations, nursing leadership, privacy/legal/compliance, communications, supply chain, business continuity, executive leadership, and the vendor owner. If a third party is part of the scenario, bring in a vendor liaison too.

The point of the exercise is to test who actually holds decision rights. Before the session starts, identify who can isolate systems, activate downtime, divert patients, cancel procedures, notify regulators or law enforcement, and accept short-term clinical risk. If people aren’t sure, or if two teams answer differently, log that as a finding. Don’t smooth over every gray area ahead of time.

Vendor liaisons matter when the scenario relies on an EHR, a managed-service provider, or another third party. Leave them out, and vendor coordination can look fine on paper even though it hasn’t been tested at all. ASPR TRACIE recommends involving key stakeholders and subordinate employees who have responsibilities during cyber incidents, with explicitly assigned roles such as crisis manager, evaluator, emergency coordinator, operational personnel, and observer.[1]

Once those decision-makers are in place, the exercise rises or falls on the record you keep.

Use a Standardized Observation Log to Capture Evidence During the Exercise

Keep facilitator, participant, and evaluator as separate roles. The facilitator keeps the discussion moving and delivers injects. Participants make the decisions. Evaluators write down what actually happened. CISA recommends assigning evaluators or data collectors to observe and document specific objectives instead of depending only on what participants remember later.[6][9]

Your observation log should track decisions, delays, and missing authority in real time. Each major decision, delay, escalation, or information gap should have its own entry, including:

  • The timestamp
  • The inject that triggered the response
  • What was decided and by whom
  • Which policy or plan was referenced
  • What information was missing
  • Where the response stopped

The record needs to be specific enough to use later. For example, it helps to note that no one could identify the vendor escalation number, the contract owner, or the approval needed to release vendor forensic support. That gives the team something concrete to fix. A vague note like “vendor coordination was weak” doesn’t.

Label each observation as demonstrated, not demonstrated, contradicted by the plan, or unknown. That one step keeps confident conversation from being confused with actual capability and gives the after-action report solid material to work from.

That’s how a discussion turns into a remediation list people can act on.

Turn Findings Into Prioritized Risk Reduction

A tabletop has value only when each observation turns into a documented, risk-rated action with a clear owner and a retest date. The observation log should drive the hotwash, the scoring, and the corrective-action plan. Those notes then feed the hotwash and the AAR/IP.

Run a Hotwash, Score Gaps, Assign Owners, and Retest

Begin with an immediate hotwash. Focus on the moments that slowed the response: which decisions were delayed and for how long, who had the authority to make each call, what information was missing or not trusted, and which vendor or dependency could not be reached. If people disagree, log that too. A disagreement is a finding.

Next, move into a formal After-Action Report/Improvement Plan (AAR/IP). FEMA's Homeland Security Exercise and Evaluation Program (HSEEP) uses this format to separate confirmed strengths from areas for improvement and tie each finding to an exercise objective or capability.[8] Score each gap on a 1-5 scale across five factors:

This keeps the discussion centered on patient safety, compliance, and recovery impact, not who spoke well in the room. Any finding that could affect emergency care, medication administration, patient identification, diagnostic services, or life-supporting workflows should be escalated, even if the total score lands in the middle.

Each corrective action needs one owner. That person sets the scope, resources, due date, and closure evidence. FEMA recommends SMART corrective actions - specific, measurable, achievable, relevant, and time-bound - to address exercise shortfalls.[7][10] Retest timelines should match the risk level:

  • 30-90 days for patient-care or recovery gaps
  • 90-180 days for managing threats to patient care from high-risk vendor or downtime gaps
  • the next exercise or audit cycle for lower-risk documentation or awareness gaps

Retest the process, not the paperwork. If the issue was delayed escalation, run a timed escalation drill. If the issue was a failed vendor contact, place an out-of-band call after hours and log the response time. If the issue involved EHR downtime, have clinicians find and use the right downtime process. A policy update by itself does not show the gap is closed. That's how you keep the exercise from ending as just a conversation.

From Observation to Risk Statement to Corrective Action: A Comparison Table

Use this format to turn discussion into tracked remediation.

Unstructured observation Formal risk statement Corrective action and retest
"The vendor contact was unreachable." During an EHR outage, the hospital could not reach the vendor through its listed contact path, delaying recovery decisions and increasing the risk of prolonged clinical downtime. Vendor Management and the EHR owner will maintain two independently tested 24/7 escalation paths, including one that does not rely on the affected email or identity system. Retest with a timed after-hours contact drill by the target date.
"Nobody knew who could authorize paper workflows." Without a designated authority to activate downtime procedures, clinical staff may delay or skip medication documentation, creating patient-safety and compliance exposure. Clinical Operations will designate and train a primary and backup downtime authority per facility, update the downtime playbook, and validate the workflow in a drill within 90 days.
"We weren't sure when to notify regulators." Uncertainty about breach-notification triggers and timelines could cause the organization to miss HIPAA reporting deadlines, increasing regulatory and reputational risk. Privacy and Legal will update the notification decision tree, assign a notification owner, and test the procedure with a timed tabletop inject at the next exercise.

Conclusion: What a Successful Tabletop Should Produce

A successful tabletop should end with a prioritized improvement plan: who will fix each breakdown, by when, how completion will be proven, and when the fix will be retested.

The output should be a ranked list of clinical, operational, compliance, and vendor fixes. That means documented decisions and delays, confirmed strengths and gaps, a map of clinical and vendor dependencies, tested downtime procedures, confirmed escalation paths, risk-rated findings with assigned owners, evidence needed for closure, and a retest schedule.

That is what separates a tabletop that builds real readiness from one that only checks a compliance box.

FAQs

How often should we run a healthcare tabletop exercise?

Healthcare organizations should run enterprise-wide tabletop exercises at least twice a year.

Some rules call for annual testing. But a twice-a-year rhythm usually works better. It gives teams enough chances to practice realistic events, like ransomware, EHR outages, or vendor breaches, without wearing people out.

It also makes sense to schedule extra exercises after major changes, such as cloud migrations, mergers, vendor shifts, or security incidents. That kind of cross-functional practice helps sharpen communication, check how decisions get made, and surface operational gaps before they disrupt patient care.

Who should own tabletop remediation after the exercise ends?

Each identified gap should have a clear owner and a firm deadline in the After-Action Report. That owner should be the team best placed to fix the issue, whether that’s IT, security, clinical operations, compliance, legal, or a third-party vendor.

It also helps to track findings in one shared risk register or corrective action plan. That gives leaders a single place to see who owns what, how work is moving, and whether each gap has been retested and fixed.

What evidence proves a tabletop improved readiness?

A tabletop improves readiness only when you can point to measurable, evidence-backed change afterward.

The After-Action Report should turn gaps into corrective actions with clear owners, due dates, and success measures. And when teams close high-risk findings, they need to show proof, not just a status update.

It also helps to keep exercise evidence, such as:

  • response timelines
  • coordination records
  • technical artifacts

Then retest those fixes in a later drill to confirm that delays or failure points went down.

Related Blog Posts