Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

On November 6, 2025, The HIPAA Journal reported that Pomona Valley Hospital Medical Center (PVHMC) agreed to pay $600,000 to settle a class action lawsuit over its use of Meta Pixel and similar website-tracking technologies. The case, Warren v. Pomona Valley Hospital Medical Center, centered on how these tools may have unintentionally transmitted user identifiers and patient information to third parties such as Meta (Facebook).

Website data leaks don’t require hackers. They happen when legitimate scripts, analytics pixels, and chat widgets transmit sensitive data to third parties through routine operations. Traditional security tools miss these leaks because they monitor server-side traffic while the exposure occurs in customer browsers. This visibility gap is why organizations use client-side monitoring platforms to detect browser-level data flows that security tools can’t see.

Back in 2022, PCI DSS v4.0 set the stage for a new era of payment security. For the first time, it asked organizations to look beyond their servers and into the browser itself. Then, on April 1, 2025, the “future-dated” requirements, 6.4.3 and 11.6.1, moved from guidance to mandate, decisively shifting attention to mitigating client-side risk. In plain English, the spotlight is now on what’s happening in the browser.

Think of your website as the front desk of your clinic. You wouldn’t let vendors set up recording equipment in your waiting room without contracts. But that’s precisely what happens when tracking pixels, session replay, and chat tools run on patient-facing pages without Business Associate Agreements.

Most HIPAA violations now involve websites and tracking technologies. Standard website tools like analytics, pixels, session replay, and chat create regulated data flows that many teams have never instrumented or reviewed. We’ve seen this play out in public: investigations and lawsuits involving Blue Shield of California and Novant Health showed how ordinary tracking technologies can expose Protected Health Information (PHI) at scale.

The US Department of Justice’s new Data Security Program (DSP) requires organizations to treat large collections of U.S.-person and government-related data as matters of national security.

Formjacking involves malicious code injected into payment forms that captures credit card data during transactions. The form functions normally, the payment completes, and nothing unusual appears in server logs. This happens in the browser, outside the reach of traditional server-side security controls. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 extend compliance to the client side to address this.

We see the same pattern across healthcare clients. The servers are locked down, databases encrypted, and GRC documentation is in order. Then we check the browser layer and find a Google Analytics pixel quietly sending appointment URLs and other PHI to third-party servers without a BAA.

By the time you reach PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1, the easy wins are behind you. This is the point where compliance turns into configuration. Tag managers, consent scripts, and payment flows all intersect here, and the guidance feels just vague enough to slow everything down. Which tag rules belong in scope? How do you prove a script was authorized? What’s the right way to detect a change without flooding alerts?

Every time someone clicks “accept cookies,” a new layer of risk begins. What appears to be a simple consent interaction can activate dozens of unseen third-party scripts that collect, share, or store user data beyond your control. For marketers, cookies power analytics and personalization. For privacy and security professionals, they often create compliance gaps and data-security blind spots.