Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Learn how to make your website HIPAA compliant in 2025 with 30+ checklist items, from BAAs and access controls to client-side monitoring and audit-ready evidence.

PCI DSS 4.0.1 compliance becomes manageable once you recognize that each tool protects a different layer, and the strongest programs combine them thoughtfully. With Requirements 6.4.3 and 11.6.1 now bringing the browser into focus, organizations can finally see the complete picture they need.