Skip to main content
Patient Protect circular logo mark in purple and white used for site navigationPatient Protect

Breach analysis · Patient Protect

Vendor risk and backup architecture: why your public website is a HIPAA liability

Ransomware on web-facing infrastructure is a HIPAA breach until proven otherwise — here's how to close the vendor risk and backup gaps that make recovery a coin flip.

Patient Protect ResearchMay 4, 2026First reported in HIPAA Pulse →

The control gap

Web-facing infrastructure — patient portals, scheduling tools, hosted intake forms — sits outside most practices' internal security perimeter but squarely inside HIPAA's Security Rule jurisdiction. When an attacker gains sufficient control to modify publicly served content, the question shifts immediately from "was this a nuisance?" to "was ePHI accessible, and does this constitute a reportable breach?" HHS guidance is unambiguous: the presence of ransomware on systems containing ePHI is presumed to be a breach unless a four-factor risk assessment demonstrates otherwise. A recent incident involving a public ransom note displayed openly on an externally hosted website — before the domain went dark under a "construction" notice — illustrates exactly how quickly a low-sophistication, opportunistic attack becomes a compliance crisis with regulatory and notification implications. First reported in HIPAA Pulse →

The HIPAA Security Rule provision in play

Two provisions converge here. §164.308(a)(7) — the Contingency Plan standard — requires covered entities to establish and test data backup plans, disaster recovery procedures, and an emergency mode operation plan. §164.308(a)(1) — Risk Analysis — requires a documented four-factor assessment any time ransomware touches systems that may contain ePHI, regardless of whether the organization believes data was exfiltrated. Additionally, §164.314(a) requires a Business Associate Agreement with any vendor hosting, managing, or transmitting ePHI — including web hosting providers and CMS vendors. A vague "construction" message in place of an incident response protocol does not satisfy any of these obligations.

How Patient Protect addresses this

  • BAA Management / Vendor Risk Scanner flags hosting vendors, web management contractors, and patient portal providers that require executed BAAs — and tracks their status so gaps surface before an incident, not during one.
  • Information Systems Inventory documents all externally hosted properties alongside internal systems, ensuring web infrastructure is treated as part of the practice's security scope, not a hosting vendor's problem.
  • Security Risk Assessment (SRA) generates the documented four-factor analysis HIPAA requires after any suspected ransomware event — producing the evidence needed to determine whether the incident is reportable and creating the compliance record that survives regulatory review.
  • Autonomous Compliance Engine continuously recalculates the practice's risk posture as the vendor landscape and asset inventory change, surfacing new exposures without waiting for the next annual review cycle.
  • Policy Generation produces documented incident response and data backup policies that align with §164.308(a)(7) — so when something goes wrong, the team has a tested protocol rather than an improvised communications workaround.

Practical next steps

  • Audit every external web property this week. List all hosted sites, portals, and web forms that touch patient data, and confirm a signed BAA is in place with each vendor.
  • Verify your backup architecture is isolated. Backups stored on the same network segment as production systems are routinely encrypted alongside primary data in ransomware events. Confirm at least one copy is logically or physically segmented and has been tested for restoration.
  • Document your incident response trigger. Unusual site behavior — unexpected content, unexplained downtime — should activate a defined protocol immediately, not a communications hold.
  • Run a formal four-factor risk assessment after any suspected compromise. Under HIPAA, this is not optional; it is the mechanism that determines whether notification is required.
  • Review CMS and hosting platform patch status. Opportunistic attacks frequently exploit known, unpatched vulnerabilities. Schedule a quarterly review of all web-facing software versions.

Try Patient Protect

This commercial companion is published by Patient Protect and may be co-written with editorial AI assistance, drawing on the source HIPAA Pulse article. First reported in HIPAA Pulse → https://hipaapulse.com/to-recover-your-files-kindly-send-0-1-btc-to-ransom-note-03fb0f34