Ransomware is not just an IT problem. It is a board risk that can disrupt patient care, stall cash flow, and force hard decisions fast. In healthcare, a single attack can shut down EHRs, labs, radiology, scheduling, and billing. The cost can be huge: UVM Medical Center lost more than $60 million, and Scripps Health reported losses above $100 million after major attacks.

If I were briefing a healthcare board on this piece, I’d boil it down to this:

  • Treat ransomware as an enterprise crisis, not a tech outage
  • Do not assume backups, insurance, or audit results mean recovery will go well
  • Push management for tested recovery times, not plan documents
  • Look at patient safety, downtime, vendors, and cash exposure together
  • Make sure decision rights are clear before an incident happens
  • Ask for board reporting that shows recovery results, not just security activity

The article’s core point is simple: boards often ask the wrong questions. Many focus on tools, controls, and compliance. But the better questions are about care disruption, downtime length, retained financial loss, vendor concentration, and who can act under pressure.

A short way to read the article is this:

  1. The first board mistake: treating ransomware like a temporary systems outage
  2. The second mistake: putting too much faith in backups, cyber insurance, and passed audits
  3. The third mistake: missing vendor, fourth-party, and supply chain risk
  4. The fix: use board oversight to test impact, recovery, reporting, and accountability
  5. The goal: see whether the hospital can keep control of care and cash when key systems fail

Quick Comparison

What boards often rely on What I’d want verified instead
Backups exist Actual tested restore time for EHR and other top systems
Cyber insurance is in place Exclusions, sublimits, waiting periods, and out-of-pocket loss
Compliance audit passed Whether downtime workflows work in practice
Vendor questionnaires completed Mapped third-party and fourth-party dependencies
Security activity metrics Recovery, care impact, and business loss metrics

In short, this article is a guide for directors to govern ransomware risk in plain business terms: How bad could it get, how long would recovery take, what would it cost, and who is in charge when the pressure hits?

What Healthcare Boards Get Wrong About Ransomware: Assumptions vs. Reality

What Healthcare Boards Get Wrong About Ransomware: Assumptions vs. Reality

When Cyberattacks Strike: Is Your Board Ready?

What Boards Get Wrong About Ransomware

Boards often stumble on ransomware for the same reason people miss a step in the dark: they think they know what’s in front of them. In practice, three bad assumptions tend to skew judgment around risk appetite, recovery, and third-party exposure.

Treating Ransomware as an IT Outage

Seeing ransomware as just an IT issue is a governance mistake.

When ransomware hits, it can shut down EMRs, labs, radiology, scheduling, and billing. It can also force patient diversions. Two independent studies linked hospital cyberattacks directly to reduced care capacity and increased mortality rates. [1] That makes ransomware a patient safety event with operational and financial fallout, not a routine systems outage.

The board’s role is not to run the technical response. It’s to govern risk appetite, funding, and accountability. That’s why directors need to ask a harder question: What can this organization live with when core systems go down?

Overestimating Backups, Insurance, and Compliance

A lot of directors walk out of a cyber briefing feeling calm for three reasons: there are backups, the organization has cyber insurance, and the last compliance audit was passed.

That sense of comfort can be misleading.

Backups only help if recovery is fast, clean, and tested. Cyber insurance may offset some losses, but policies can include exclusions, sublimits, and waiting periods that leave the organization carrying a large share of the damage. Scripps Health reported more than $100 million in losses after its 2021 ransomware attack. [1] And compliance shows that controls exist on paper. It does not prove the organization can recover under pressure.

The board’s job is to look past the polished summary and ask whether resilience has been shown in practice, not just written down.

Underestimating Vendor, Fourth-Party, and Shared Accountability Risk

A completed vendor security questionnaire is not proof that a vendor is secure.

Healthcare organizations rely on third parties across both clinical and business operations. If one of those parties is hit by ransomware, the disruption can spill over fast. Fourth-party dependencies add another layer of risk, and that concentration may stay hidden if no one maps it clearly for the board.

This risk goes well beyond IT vendors. It can run through the full supply chain, including medical supplies, pharmacy, laundry services, and HVAC systems. When boards treat vendor risk as only a procurement issue or only an IT issue, gaps spread. Vendor risk needs to sit inside enterprise risk, with contract protections that go past checkbox reviews.

Common Assumption What Directors Should Verify Instead
"We have backups" Are restoration times tested? How long does a full recovery actually take?
"We have cyber insurance" What are the sublimits, exclusions, and waiting periods? What's our retained loss?
"We passed our compliance audit" Do downtime procedures work? Have they been exercised?
"Our vendors completed security questionnaires" Are critical third-party dependencies mapped? Are they reviewed as part of enterprise risk?

These assumptions need pressure-testing through direct board questions about exposure, recovery, and accountability.

Key Questions Directors Should Ask Management

Use the earlier blind spots to pressure-test management in three areas: impact, recovery, and shared accountability. Good oversight means asking sharp questions and having little patience for fuzzy answers.

Questions About Exposure, Business Impact, and Quantified Risk

Start here: What are our highest-impact scenarios, and what do they cost us?

Management should be able to spell out which systems would be hit first, including EMR, labs, radiology, discharge, pharmacy, and patient scheduling. They should also know how long each system could be down and which clinical and business functions rely on them.

Then push on business impact. What would the outage mean in practice? Look for direct answers on:

  • Patient diversions
  • Delayed procedures
  • Longer hospital stays
  • Lost revenue
  • Recovery costs

It also helps to ask whether risk modeling covers the full enterprise, not just IT. That means telehealth, innovation and research, joint ventures, and affiliated practices too. If the scope is too narrow, the board is making decisions with part of the picture missing.

If management can't put numbers on impact, move to the next issue: recovery.

Questions About Recovery, Downtime, and Decision Authority

Ransomware readiness isn't proved by having backups and plans on paper. It shows up when those backups and plans are tested under pressure.

Ask management how fast the organization can detect, contain, and recover from an incident. Then ask when those timelines were last tested. Review the latest test results for restoring priority systems, including how long a full EHR recovery takes under realistic conditions.

Manual downtime is another place where weak points show up fast. Can the organization operate safely for 72 hours or even a week? Are there documented manual workflows for pharmacy, labs, and patient scheduling? And have staff actually practiced them, or are they sitting in a binder somewhere?

Decision authority matters just as much as technical readiness. The board should know who has the authority to declare a major cyber incident, isolate systems, notify regulators, and escalate the matter to the board. If that chain of command is unclear or hasn't been tested, that's a governance gap, not just an ops problem.

Once recovery looks clear, the next step is to see whether vendor dependencies hold up when things get messy.

Questions About Vendors, Reporting, and Independent Assurance

The board's role is to test assumptions. That starts with vendors. Ask how critical vendors are identified and tiered, how findings from vendor assessments are tracked through closure, how contract terms are enforced, and where fourth-party and concentration risks are highest.

Reporting deserves the same level of scrutiny. Ask management how it keeps up with changing disclosure rules and reporting duties, and what thresholds trigger escalation to the board. The goal is simple: the board shouldn't be the last group to hear bad news.

Independent assurance matters too. Reporting from the same team that owns security can only go so far. Directors should know whether there is any outside validation of the program and, if not, why not.

"When healthcare boards naturally refer to their cybersecurity committee with the same level of priority, import and frequency as audit and compensation committees, cybersecurity will be represented under the full fiduciary power and authority of the organization." - Ed Gaudet, CEO and Founder of Censinet [1]

Those answers should appear in board reporting as outcomes, not activity.

How to Read Ransomware Reporting and Use the Right Resources

Reading the Board Dashboard: Outcome Metrics Over Activity Metrics

Those earlier questions only help if reporting answers them in language the board can actually use. A board report shouldn't just show security activity. It should show whether the organization can recover, handle vendor disruption, and stay within insurance limits.

This table shows the gap between what management often reports and what directors need to see.

Activity Metrics (Technical Counts) Outcome Metrics (What the Board Needs)
Number of patches applied Tested restoration time for EMR and critical clinical systems
Number of phishing emails blocked Maximum tolerable downtime vs. actual recovery capability
Number of vulnerabilities identified Open gaps from recent tabletop exercises
Total security spend Modeled loss vs. insurance limits
Number of firewall hits Vendor concentration risk and fourth-party concentration risk

A board dashboard also needs to cover clinical operations, business functions, vendors, and supply chain dependencies. Leave out any one of those, and directors lose sight of enterprise risk.

The sources below help directors decide whether management's reporting reflects actual resilience, not just busywork.

The Director's Reading Guide

Directors don't need to become security specialists. But they do need a short set of references they can return to when they're testing management's claims and reading board reports. These resources help boards assess recovery, vendor exposure, disclosure duties, and crisis readiness without getting pulled into low-level technical detail.

Resource Primary Board Use
NACD 2026 Director's Handbook on Cyber-Risk Oversight Establishing foundational governance and fiduciary oversight
NACD Ransomware Guidance Board decision-making during and after a ransomware event
CISA StopRansomware Guide Understanding the current threat landscape and cross-sector best practices
CISA Healthcare & Public Health Guidance Aligning organizational resilience with national health infrastructure standards
CISA Healthcare Ransomware Response Guidance Healthcare-specific operational response expectations
HHS Health Industry Cybersecurity Practices (HICP) Evaluating technical and administrative controls specific to healthcare
ASPR TRACIE Resources Clinical and operational recovery
Five Principles for Board Oversight of Cyber Risk Aligning security priorities with business goals

Treat these as recurring board references, not one-time reading.

Where Censinet Fits in Board Oversight

Boards also need a way to turn those questions and metrics into something they can track over time. Censinet RiskOps™ gives healthcare organizations a centralized layer for managing enterprise and third-party risk, including vendor assessments, remediation workflows, benchmarking against healthcare peers, and visibility into fourth-party concentration risk.

That kind of visibility makes board reporting more useful. It shows whether findings are moving toward remediation and where risk is clustering.

Censinet AI™ supports that work by speeding up evidence review, routing findings to the right teams, and generating risk summaries. Human review stays in control, so automation helps move the process along without moving accountability.

Conclusion: Board Actions That Strengthen Ransomware Resilience

Ransomware is a governance issue, not an IT issue. The losses at UVM Medical Center and Scripps show what weak board oversight can cost.[1]

Immediate Governance Actions for the Board

Boards should ask for evidence, not promises. Management should show, in plain terms, how ransomware would hit clinical operations, business functions, vendors, and recovery.

That means asking for tested restoration times for the EMR and other critical clinical systems. It also means requiring a mapped inventory of critical vendors and supply chain dependencies. And cyber insurance should be treated as just one piece of the risk plan, not the whole plan.

These are the baseline governance checks. After that, the board needs to see whether those checks lead to actual resilience.

What Good Oversight Looks Like Going Forward

Good ransomware governance is repeatable and measurable. Boards should expect tested recovery times and clear reporting on third-party dependencies.

Directors should set up a standing cybersecurity committee with the same weight as audit or compensation committees. That gives the topic dedicated agenda time and clear fiduciary accountability.[1] Use the dashboard and questions in this guide to track those outcomes quarter by quarter.

FAQs

How should boards measure ransomware readiness?

Boards should judge ransomware readiness by what hits the business and clinical side, not by dense IT language. The point isn't to hear about tools. It's to know how fast the organization can detect an attack, contain it, and recover - and whether those goals hold up in a realistic crisis.

Management should report those timelines in plain English and test them under pressure. A target on paper is one thing. A live drill that simulates downtime, care delays, and staff confusion tells a much clearer story.

A board-level dashboard should connect cyber readiness to outcomes leaders care about, including:

  • downtime costs
  • patient care disruptions
  • financial exposure
  • recovery readiness
  • the share of critical vendors assessed
  • performance against peers
  • regular tabletop exercises

That kind of dashboard gives the board a practical view of risk. It shows where the organization stands, where it may be exposed, and how prepared leadership is when systems go down.

What should directors ask about cyber insurance?

Directors should treat cyber insurance as part of enterprise risk management, not just a fallback plan.

That means asking a few hard, practical questions. Do cyber and D&O policies line up with the organization’s financial risk, liability exposure, and risk appetite? Do they account for the full cost of a ransomware event, including downtime, recovery work, and legal fees?

It also helps to look outward. How do coverage limits stack up against peers? Where are the gaps that insurance won’t fix, whether in coverage or internal response capability? And is insurance woven into incident response planning, including early engagement with breach counsel?

Why do vendor and fourth-party risks matter so much?

Vendor and fourth-party risks matter because healthcare work doesn’t stop at the organization’s walls. Hospitals, clinics, and health systems depend on outside companies for core services like electronic health records, imaging, and payment processing.

When a vendor gets hit, the fallout can spread fast. Downtime can push staff into manual, error-prone workflows, delay urgent procedures, and even lead to ambulance diversions. Fourth parties - the subcontractors and cloud providers behind vendors - make that risk bigger by adding hidden dependencies.

Related Blog Posts