Tabletop the Supply Chain. Five Scenarios Every Health System Should Run.

I’d start with one critical vendor dependency - and test who keeps care moving when it fails. In a March 2024 AHA survey of nearly 1,000 hospitals, 74% reported direct patient-care impacts from the Change Healthcare attack.^[5]

I’d use five tabletop scenarios to test different points of failure:

• Vendor ransomware prevention: Keep orders and results moving during a hosted-service outage.
• Compromised remote access: Cut vendor access without putting patients at risk.
• Malicious software update: Stop deployment and choose safe isolation, rollback, or restricted use.
• Third-party patient data breach: Limit data access, confirm the facts, and assign notice duties.
• Supply or device vendor disruption: Verify stock, approve substitutes, and keep devices safe.

The goal isn’t just to discuss an attack. I’d use a 2- to 4-hour exercise to name decision owners, test downtime plans, and define what must be checked before services return. That includes shared suppliers and outages lasting 30 days or longer.

My rule: <u>Every gap gets an owner, a deadline, and a retest.</u> Start with the failures most likely to interrupt care, then check high-risk fixes within 60–90 days.

Mastering Tabletop Exercises: Building Incident Response Skills Through Practice

sbb-itb-535baee

Plan a Tabletop That Tests Decisions

Run a 2- to 4-hour, facilitator-led tabletop with a short kickoff, 3 to 5 timed injects, and a final decision review. Do not deploy malware, disable production systems, or interrupt patient care. Use CISA’s Healthcare and Public Health Sector Tabletop Exercise Package for customizable scenarios and discussion prompts.^[7][11] Use its structure to test actual dependencies - not just walk through a generic incident response script.

Build the exercise packet from current vendor and subcontractor inventories, dependency maps, data flows, remote connections, privileged accounts, downtime procedures, recovery priorities, healthcare supply chain security challenges, after-hours contacts, and contractual and regulatory notice duties. These details should help the team trace which third-party failures affect care first. Missing owners, unknown dependencies, and stale contacts are exercise findings, not cleanup items.^[12][13][15]

Bring in IT, cybersecurity, clinical informatics, clinical operations, supply chain, biomedical engineering, privacy, legal, communications, executive leadership, and the vendor’s business owner and incident lead. Name backups and escalation paths before the exercise. Also define who can isolate access, activate clinical downtime procedures, approve emergency purchasing, authorize notifications, and approve restoration.

Set measurable objectives before writing injects. The team should identify the decision owner within 10 minutes, locate usable downtime procedures, and explain how orders and records will be reconciled after recovery. For every containment choice, require the team to state the patient-care impact, workaround, staffing needs, and operating limits - including where care continues, pauses, or shifts to workarounds.

Test prolonged disruption, too: the American Hospital Association recommends planning for loss of critical third-party capabilities for 30 days or longer.^[14]

Keep a visible decision log that records the time, owner, evidence for each objective, rationale, care impact, communications, and criteria for reconsidering the decision. Record delayed decisions and unsupported assumptions. Then use an After-Action Report/Improvement Plan to separate strengths, gaps, root causes, corrective actions, owners, deadlines, resources, and validation methods. Give each decision gap an owner, a deadline, and a validation step.^[8][9][10]

Use this format as you work through the five scenarios below.

1. Ransomware at a Critical Service Provider

Start with a vendor failure that could interrupt diagnosis and treatment: ransomware takes the hosted laboratory information system offline. Interfaces fail, the provider cannot estimate recovery, requests disconnection, and reports an unverified claim of patient-data theft.

Include the core response team and the provider’s incident lead in the exercise.

Patient-care continuity

Test who declares laboratory downtime and how urgent results reach clinicians when interfaces are down. Have teams locate paper orders, verify patient identity, authenticate orders, and determine how to access historical results.

Document when manual delays require escalation because they threaten patient safety. Include dependencies on printers, couriers, and secure messaging.

Vendor coordination and decision authority

Ask the provider which services are affected, whether containment is in place, the status of backups, the restoration order, and when the next update will arrive - even if there’s no recovery estimate.

Check contractual notice deadlines and forensic cooperation requirements. Record escalation contacts and identify who can authorize integration disconnections, approve emergency purchases, and manage vendor updates.

Containment and evidence preservation

Decide whether to isolate individual interfaces, disable all connections, or block provider remote access. Identify how each choice would affect patient care.

Preserve authentication logs, interface queues, and configuration snapshots as long as doing so does not delay containment. Privacy and legal teams should assess the theft allegation against data inventories and forensic evidence - not assumptions. Record notification triggers and the facts still missing.

Recovery and readiness evidence

A vendor’s service-restored notice is not clearance to reconnect. Before staged reconnection, require evidence of containment, validated backups, restored identity controls, monitoring, and successful tests of orders, results, timestamps, and permissions.

Verify patient identity, enter downtime records only once, and resolve duplicate orders and delayed results. Obtain clinician review of high-risk entries. Record the backlog, manual corrections, and unresolved records as readiness evidence.

2. Compromised Vendor Remote Access

Use this scenario to test who can cut vendor access fast enough to protect care.

At 2:15 a.m., a vendor technician logs in outside the approved maintenance window, escalates privileges, and probes the EHR interface engine. Introduce evidence in stages:

An unexpected login alert, a privileged-group change, lateral movement, or a vendor ticket that does not match the activity.

Bring in security, IAM, infrastructure, biomedical and clinical engineering, clinical leadership, the vendor owner, the vendor IR lead, legal/privacy, and communications. Include emergency management if care may be affected.

Patient-care continuity

Ask whether ending the session would interrupt active device maintenance. Clinical and engineering leaders must set safe operating limits before anyone revokes access, isolates a segment, or enters downtime.

If vendor support is still needed, require a named, MFA-protected emergency account with an approved scope, an observed or recorded session, and automatic expiration.

Vendor coordination and decision authority

Use an out-of-band contact to verify the technician, work order, maintenance window, and approved systems. Require the vendor to explain any mismatches and identify affected accounts.

Define who can suspend access and who can approve emergency access. The compromised technician cannot control either decision.

Containment and evidence preservation

Test session termination, credential disablement, and token invalidation separately. Disabling an account may not end an existing session.

Preserve identity-provider, gateway, endpoint, and device logs, including timestamps, source IPs, commands, and session recordings. Assign evidence collectors and lock logs against changes by remote-management tools. Legal/privacy should separate confirmed patient-data access from gaps in logging.

Recovery and readiness evidence

Restore access only after reviewing session actions, checking for persistence, and confirming that the vendor workstation or jump box and account are clean.

Document each account’s owner, MFA status, time-limited privileges, session records, and offboarding steps. Measure time to cut access and the clinical impact, then retest with an expired technician account.

Carry these access-control findings into the next scenario: a malicious software update.

3. Malicious Software Update

A compromised vendor account can turn a routine update into a system-wide incident. Simulate a trusted software or firmware update deployed overnight across multiple facilities. Hours later, the vendor warns that the version may contain malicious code or that its update infrastructure was compromised.

Inject abnormal outbound traffic, failed authentication attempts, interface delays, crashes, or device alarms.

Include security, application owners, infrastructure and network engineering, clinical operations, change management, procurement, legal/privacy, communications, and the vendor. Bring in biomedical engineering if devices are involved. A valid signature does not prove an update is safe.^[19][24][25] The exercise should require the team to decide whether to isolate affected systems, roll back, or continue in limited mode.

Patient-care continuity

Require clinical owners to choose isolation, validated rollback, or restricted operation for each affected service.

Inject a cancer treatment schedule tied to the application.

Every clinical exception needs an approver, compensating controls, a reassessment deadline, a stop condition, and tested manual workflows.^[17][18]

Vendor coordination and decision authority

Identify who can freeze deployment across all facilities, including automatic installs and cached installers. Require the vendor to send affected versions, hashes, indicators of compromise, and remediation instructions through a verified channel.

Change management and infrastructure must reconcile installation records with facility inventories. Procurement checks notification obligations, while legal/privacy and communications assess reporting and messaging needs.^[21][23] Once affected versions are known, start containment before cleanup.

Containment and evidence preservation

Treat isolation and rollback as separate decisions. Restrict unnecessary network traffic without breaking essential clinical interfaces.

Before cleanup, preserve the installer, hashes, signing certificate, deployment logs, endpoint telemetry, and vendor correspondence. Roll back only after confirming that the prior version is supported, works with current data, and is clinically safe.^[18][19]

Recovery and readiness evidence

Test remediation in an isolated environment, then require clinical function checks and independent verification of installed versions, package integrity, removal of persistence, and post-recovery traffic.

Record the time needed to freeze deployment and identify affected assets. Validate the share of systems independently checked. Assign owners and deadlines to address gaps in version inventories, deployment gates, rollback plans, segmentation, and integrity checks.^[16][20][22]

4. Third-Party Patient Data Breach

Simulate a business associate (BA) reporting weeks of account misuse, a partial patient list, and files that may have been exfiltrated - with access still unconfirmed. The scenario tests how to keep care moving while teams sort out breach facts, notice duties, and data-access limits.

Give the vendor’s forensic and privacy teams conflicting timelines. Include privacy, legal, compliance, security, health information management (HIM), patient relations, communications, executive leadership, and vendor management, along with the vendor’s privacy, legal, forensic, and communications leads. Name one decision owner to resolve conflicting commitments.

Patient-care continuity

Decide whether the affected service can continue with reduced data access or needs a secure backup workflow. Test where reduced access is safe and where a backup is required.

Clinical operations should identify the minimum data needed for care. Leadership should approve temporary access limits and exceptions. Keep necessary care running with documented safeguards, review deadlines, and explicit exceptions.

Vendor coordination and decision authority

Check incident dates against evidence - not just the vendor’s summary. Review the business associate agreement and assign owners for evidence delivery, breach decisions, patient notices, regulatory reporting, and communications.

The BA must report a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery. Contracts may require faster reporting.^[27] Legal and compliance should also identify applicable state duties.

The health system generally remains responsible for notifying affected individuals, HHS, and, when applicable, the media - even if the BA handles delivery by agreement or delegation.^[29][30]

Containment and evidence preservation

Require account containment and preserve access logs, file-transfer records, database queries, and vendor communications. Privacy and legal should document the four breach-assessment factors: the nature and extent of the PHI involved, the unauthorized recipient, whether the PHI was actually acquired or viewed, and the extent of mitigation.^[26][28]

An impermissible disclosure is presumed to be a breach unless an exception applies or evidence shows a low probability of compromise. Missing download evidence does not prove that no data was accessed.^[26][28]

Recovery and readiness evidence

Measure time to usable evidence, reconciliation rate, and notice approval time. Require HIM to reconcile affected records using approved source systems and deduplication rules, account for missing fields, and name a validation owner.

Test patient notices and call-center scripts against confirmed facts and known gaps. Before normal service resumes, obtain root-cause findings and verified access controls.

Assign deadlines for agreement updates, data-flow documentation, reporting duties, and patient-support escalation. Use these findings to distinguish data-breach response from the next scenario, where a vendor disruption affects physical supplies or devices.

5. Cyberattack Disrupting a Medical Supply or Device Vendor

After testing data exposure, turn to the physical supply chain that keeps care running.

Simulate an offline ordering portal, shipments that can’t be verified, suspended device support, and a sole-source item with 7–14 days of stock remaining. Add conflicting distributor updates and a device alarm. The vendor reports that some connected devices may need isolation but can’t yet confirm whether the attack affected product integrity or the service platform.

Include supply chain, materials management, pharmacy, clinicians, clinical engineering, emergency management, finance, security, legal, and leadership. Bring in the affected supplier, distributor, and group purchasing organization (GPO), too. Treat this as a cyber incident, not a routine shortage. Start with a simple question: what keeps working, and what stops?

Patient-care continuity

Count usable inventory and set a shortage threshold that triggers conservation, substitution, or procedure delays. Clinical leaders - not purchasing alone - must approve allocation priorities and safe substitutes.

Test regional mutual aid using limited stock from a neighboring hospital. Plan conservation and substitution around a 30-day disruption.^[14]

Vendor coordination and decision authority

Name who can approve alternate suppliers, emergency purchases, expedited freight, and price exceptions. Verify shipment claims through known supplier, distributor, or GPO contacts.

Have materials management and pharmacy check lot numbers, expiration dates, packaging, and authorized distributor status. Quarantine deliveries that can’t be verified. Identify who can release them after clinical, pharmacy, quality, or regulatory review.

Containment and evidence preservation

Separate a shortage from an unsafe product, update, or connection. Clinical leaders must confirm that isolation preserves essential alarms and treatment functions. Security and engineering should then test whether devices can remain in service offline or need replacement.

Preserve device identifiers, service histories, shipment records, and network logs. Don’t install unverified firmware or reconnect devices based on the vendor’s request alone. Require approval from security, engineering, clinical leadership, and legal.

Recovery and readiness evidence

Set separate milestones for tested ordering, verified shipment tracking, restored servicing, and approved connectivity. Require service checks and validated remediation before removing temporary controls.^[31]

Record approved alternatives, regional contacts, and loaner-device plans. Assign each gap an owner, deadline, and test - for example, isolating a device safely without interrupting care.

Check for Gaps Across the 5 Scenarios

After the tabletop, use this matrix to compare findings across all five scenarios. Map shared dependencies - not vendor names. This brings the five exercises into one dependency check. HHS recommends identifying, prioritizing, and assessing critical suppliers throughout the relationship lifecycle.^[32]

Look beyond each direct vendor. Mark shared cloud hosts, identity providers, network carriers, software libraries, data processors, and logistics providers. Separate contracts don’t mean separate failure risks. Flag fourth parties that appear in more than one row, then test their loss alongside the primary vendor’s outage.^[32]

For each row, assign an internal relationship owner, an authorized clinical decision-maker, and a verified external escalation contact. Record affected departments, maximum tolerable downtime, recovery-time and recovery-point objectives, and the tested workaround. Identify controls and recovery evidence shared across rows. Document the approver, test result, date, time, time zone, and remaining limits. A vendor’s restoration claim isn’t enough.^[32][33]

Keep outage, compromise, integrity loss, data exposure, and supply disruption separate. Note whether a vendor compromise reached your systems. Check that the matrix covers confidentiality, integrity, availability, patient safety, regulatory response, inventory, and communications. Put every blank, disputed answer, or reliance on the vendor alone in the corrective-action register.^[6][7]

Assign Owners and Actions to Exercise Findings

Turn the matrix into an action register. Hold a hotwash immediately after the tabletop to record what worked, what failed, and where handoffs stalled. Add these findings to the after-action review and improvement plan within three to four weeks.^[35][36]

Group findings by dependency, role, control, decision, and recovery. Assign one owner to each scenario gap and shared dependency gap. For every action, document the internal owner, vendor owner where relevant, corrective action, priority, start date, due date, dependencies, resources, status, and verification method. Also record the finding, affected service, patient-care risk, and root cause.

Set priorities based on clinical consequence, operational reach, exploitability, dependency concentration, and recovery time. Give urgent gaps an executive owner and interim controls.

Update the records and controls that the tabletop showed were weak: vendor risk ratings, dependency maps, business-impact analyses, escalation contacts, notification clauses, downtime procedures, supplier arrangements, privileged-access rules, evidence-collection procedures, and reconnection criteria.

Where contracts need changes, add incident-notification deadlines, forensic cooperation, log preservation, access to affected systems, exercise participation, and approval for subcontractors and updates. HHS identifies vendor/supplier cybersecurity requirements and third-party incident reporting as important healthcare cybersecurity activities.^[33]

Use Censinet RiskOps™ to route findings into the risk register and track remediation to closure.^[34]

Close findings only after verification. Match each retest to the gap:

• Repeat the tabletop to check responsibilities or escalation, run a timed downtime drill for continuity, or use a technical test for access controls.
• Review logs or configurations for security controls, review contracts for notice clauses, or test communications through a live or simulated vendor notification.

Rerun affected scenarios after high-priority fixes and before the next major vendor, system, or workflow change. Keep unresolved high-risk findings open with an interim control, executive owner, and revised due date. Carry unresolved items into the next exercise cycle.

Conclusion: Measure Readiness by What Changes

Across the five tabletop scenarios, measure progress by how fast and safely teams activate downtime, revoke vendor access, and restore services within recovery objectives. Check that those gains hold across exercises.

Readiness means documented decisions, clear owners, and testable records that prove care continuity, vendor coordination, safe containment, and verified recovery. Turn the findings into corrective actions.

Start with one critical vendor dependency. Give each corrective action one owner, and set its retest date before the exercise ends. Retest high-risk gaps within 60–90 days.

FAQs

How do we choose which vendor to test first?

Start with Tier 1 critical vendors - those that support electronic health record integrations, patient scheduling systems, or connected medical devices ^[1].

Focus first on vendors that pose the greatest risk to patient safety and operational continuity. Assess the volume and sensitivity of protected health information they handle, their clinical impact, network connectivity, and concentration risk ^[1]. Map these dependencies to direct resources where they’re needed most and tailor exercises to your most critical partners ^[1][2].

What if our vendor won’t participate?

Treat a vendor’s refusal to participate as a critical finding. Record gaps in escalation paths and response coordination. Work with procurement and legal to resolve missing contacts or unclear approvals ^[1].

Require contracts and Business Associate Agreements (BAAs) to include incident notification, response coordination, and participation in testing ^[2][3]. Prioritize vendors based on risk and clinical impact. Define when downtime procedures - such as paper documentation or local failover systems - must take over if vendor support is unavailable ^[4][3].

How do we set realistic downtime limits?

Build recovery time objectives into incident response and supply chain planning. Use tabletop exercises to test downtime limits under realistic constraints - for example, activating downtime procedures within 15 minutes of an EHR outage.

Don’t invent workarounds to make the exercise pass. Identify missing procedures and outdated contact lists, then check workflows through timed drills. Set specific, measurable, time-bound corrective actions to address identified patient-care or vendor-related risks within 90 to 180 days.

Related Blog Posts

• Healthcare Supply Chain Vendor Risk: Disruption Prevention and Contingency Planning
• Incident Response Playbook for Healthcare Supply Chains
• Why Technology Cascades Are Becoming a Patient Safety Issue
• The Next Healthcare Crisis May Start in the Supply Chain