Hospital websites are unusually complex compared to most healthcare practices. They typically include a public marketing site, a find-a-doctor directory, condition and service pages, scheduling tools, donation pages, careers pages, employee portals, patient portals (often integrated with EHR systems like Epic's MyChart or Cerner), mobile apps, and increasingly AI-powered chat tools.

Each of those surfaces has its own technical stack, its own vendors, and its own potential leak vectors. The hospitals that ended up in eight-figure settlements all had something in common: their privacy team didn't know what was running on every surface.

This guide covers the five web-related exposure areas hospitals face most often. The order matters — these are listed by frequency of finding in our scans, with the highest-frequency issues first.

1. Tracking pixels on patient-facing surfaces

This is the largest single category by both number of cases and total dollars paid. The pattern: marketing teams installed Meta Pixel, Google Analytics, TikTok Pixel, LinkedIn Insight Tag, and similar advertising trackers on the hospital website. Some installed them on the patient portal too, either intentionally or because of shared Tag Manager configurations.

Where we typically find them:

  • Public website, including condition pages, service-line pages, and find-a-doctor flows. The Pixel's presence here was the basis of the MarinHealth $3M settlement.
  • Patient portal login pages. The login page is technically public, but scripts loaded there often persist after login. The Markup found Pixel inside post-login portal screens at 7 of the top 100 U.S. hospitals.
  • Mobile apps. Advocate Aurora's $12.25M settlement specifically covered the LiveWell mobile app, not just the website.
  • Scheduling pages. Even on otherwise-clean sites, the dedicated scheduling subdomain often runs different (and looser) tracking than the main site.
  • Donation pages. Often built by an outside fundraising vendor with their own tracker stack.
  • Employee portals. Lower risk because they don't typically contain PHI, but worth auditing.

The post-AHA v. Becerra analysis applies fully here. Generic marketing pages have a defensible argument; clinical-context pages and authenticated portal pages don't. Most hospitals don't realize the carve-out is narrower than they think.

2. BAA gaps with marketing and operational vendors

Hospitals tend to have BAAs with their EHR vendor, their billing system, and their major IT services contractors. Where the gaps appear:

  • Email marketing. Mailchimp, Constant Contact, SendGrid (without an enterprise plan), Klaviyo. Used for newsletters, donor communications, employee announcements.
  • Forms and scheduling. Calendly free/standard, Acuity standard, Typeform standard, JotForm standard, Google Forms.
  • Customer support. Intercom (without Premier), Drift, Zendesk (without Advanced), Tidio.
  • Productivity tools. Microsoft 365 (without the right plan + signed BAA), Google Workspace (same), Slack (without Enterprise Grid), Notion (without Enterprise).
  • Analytics and personalization. Microsoft Clarity (free; no BAA on any tier), Hotjar (without Business+), FullStory (without enterprise), LogRocket, Optimizely.
  • Video and meetings. Zoom standard (no BAA without the Healthcare plan), Whereby, Jitsi, Loom, Vimeo.
  • AI tools. OpenAI's ChatGPT API (no BAA on the standard plan; Enterprise plan or Azure OpenAI required), Anthropic's Claude (BAA only via specific deployment paths), various AI scribes and coding assistants.

The MMG Fusion case (March 2026) is a recent reminder that BAA gaps don't have to involve a marquee vendor to produce regulatory action. MMG was a dental marketing software company most healthcare lawyers had never heard of. The breach exposed 15 million records.

For a hospital, the BAA inventory should be reviewed annually, with new tools requiring privacy-officer sign-off before procurement.

3. Patient-portal subdomain hygiene

Patient portals usually run on a separate subdomain from the main hospital site — `mychart.healthsystem.org`, `patientportal.hospital.com`, `myhealth.system.org`. The portals are often managed by the EHR vendor or by a separate IT/digital team, not by the marketing team that runs the main site.

This split creates governance gaps. Marketing teams sometimes deploy trackers to the portal because they want unified analytics. EHR vendors sometimes embed Google Analytics by default in their portal templates without the hospital realizing. Hospital IT teams sometimes "lift and shift" Tag Manager configurations from the main site, including all its trackers.

The portal login page deserves the same treatment as a clinical page. Anything that loads on the login screen often persists after login. Anything that fires after login is operating in the most regulated context HIPAA covers.

For mobile apps, the analog is the SDK stack. Most hospital apps include analytics SDKs, crash reporters, push-notification services, and sometimes ad attribution SDKs (which is what made Cerebral's case so expensive). Those should all be inventoried separately from the website analysis.

4. Section 1557 accessibility

The HHS final rule under Section 1557 of the Affordable Care Act (effective July 5, 2024) requires healthcare practices that receive federal funding to make their websites and mobile apps accessible by May 11, 2026 (or May 11, 2027 for small entities).

Hospitals are not "small entities." The May 2026 deadline applies to nearly every U.S. hospital.

The standard is WCAG 2.1 Level AA. The most common failures we see in hospital scans:

  • Missing alt text on images
  • Inadequate color contrast on call-to-action buttons (especially "Schedule Appointment" buttons)
  • Forms that don't work with screen readers
  • PDF documents (especially patient education materials and forms) not tagged for accessibility
  • Navigation patterns that don't work with keyboard-only input

Section 1557 enforcement is separate from the ADA Title III lawsuit wave that's already targeting healthcare. UsableNet tracked roughly 4,600 federal ADA Title III website lawsuits in 2023, with healthcare ranking second by sector. The May 2026 deadline doesn't replace the ADA suits; it adds a federal regulatory channel on top of them.

5. Web-facing infrastructure exposure

Hospital websites typically have larger and more complex infrastructure than smaller practices. That creates exposure surfaces that don’t exist for a solo practice.

  • Subdomain proliferation. A typical hospital system has 50-200 subdomains: marketing, intranet, employee tools, vendor partners, legacy sites from acquisitions, dev and staging environments. Many are forgotten. Some have stale DNS records pointing to deprovisioned cloud resources, which makes them vulnerable to subdomain takeover (where an attacker registers the deprovisioned resource and effectively takes over the subdomain).
  • Exposed dev artifacts. `.env` files, `.git/` directories, old database backups, unencrypted log files. The 2024 .env extortion campaign found these on roughly 110,000 domains. Hospital systems have larger attack surfaces, so the rate of exposure is correspondingly higher.
  • Email authentication. SPF, DKIM, and DMARC records. Required by Google and Yahoo since February 2024 for any sender of bulk email. Misconfiguration makes the domain easier to spoof for phishing campaigns.
  • TLS configuration. Older TLS versions and weak ciphers are still common on hospital systems, especially on legacy applications. Cyber insurers check this in pre-bind questionnaires.
  • Exposed admin panels. WordPress login pages, Jenkins, Grafana, internal monitoring dashboards reachable from the public internet.

What good governance looks like

The hospitals that don't get sued generally have three things in place.

A privacy-officer-led review of any new third-party script before it goes on a patient-facing surface. The reviewer asks: does this vendor have a BAA? Does it need one? What data does it collect? What pages will it run on?

A continuous external monitoring program — either an internal capability or a vendor — that scans the public attack surface (including portal subdomains and mobile apps) on a regular basis and alerts the privacy team when something changes.

A documented incident-response process that includes tracking-tech findings as a category of incident. Most hospital incident-response plans were written for ransomware and email phishing; they don't cover "marketing accidentally installed Meta Pixel on the patient portal" as a separate scenario.

What to do this quarter

Three things in priority order.

First, run a full external scan including patient-portal subdomains and the public login pages of those portals. If you find any of the surfaces in section 1 or 2 above with issues, you have an immediate remediation problem.

Second, audit the BAA inventory against the actual vendor stack. Most hospital privacy offices have lists from 2-3 years ago that don't reflect what marketing and operations teams have actually deployed since then.

Third, start the Section 1557 accessibility work if you haven't. May 2026 is closer than it sounds, and remediation can take 4-6 months for a large hospital site.

We do this scan automatically across all of these surfaces. The free tier covers the first scan.