Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Conversations about GA4 in healthcare tend to stay strangely shallow, circling the same procurement question: “Is there a BAA?” It’s as if GA4 creates risk at the contract layer, when the truth is that the risk is born earlier and lower, in the collection layer, where ordinary telemetry becomes sensitive the moment it is attached to health context and allowed to leave your site.

While the objective of protecting personal data is to be lauded, the current setup in the US is one of the most complex in the world. Twenty states. Twenty different thresholds and definitions. ‘Sale’ means one thing in California, another in Virginia. Tracking 275 daily website visitors puts you in scope for CCPA/CPRA, but not Tennessee’s law. 274 keeps you out of both. Just determining if a law even applies has become a legitimate challenge for businesses.

Ask five compliance leads in the gaming industry how 6.4.3 applies to their payment flows, and you’ll get five different answers. Ever since PCI v4.0.1 has come into effect, gaming and iGaming operators have been struggling to identify where they fall in scope, which SAQ paths apply to their specific architecture, and if Requirement 6.4.3 and 11.6.1 apply to them or their payment processors.

Nearly 70% of online purchases now happen on mobile, yet PCI scoping decisions are still often made as if mobile is just a smaller browser. It is not. A native in-app payment flow and a mobile web checkout trigger materially different obligations under PCI DSS 4.0.1. In one case, risk concentrates inside the application runtime through SDKs, platform storage, and release controls.

Very few people know this, but passing a PCI audit has very little to do with having defensible evidence. Your processor passed its last PCI assessment. Three months later, a merchant using your payment forms gets hit with a Magecart attack. Card brands start asking: What monitoring did you have on that checkout page? When did you detect the compromise? What evidence can you provide? That’s when the gap becomes obvious.

Chances are, if you are reading this article, you are comparing Stripe, Adyen, and PayPal (Braintree) on fees, payout timing, and how quickly you can ship the integration. And that would be reasonable. But the security outcome is shaped earlier than most teams think. A payment processor protects card data once it enters its fields and systems. The transaction begins on your checkout page, inside a browser that is also running analytics, tag managers, A/B tests, support widgets, and third-party scripts.

If you stand behind almost any modern checkout today and inspect the network tab, you will rarely see a tidy, controlled set of assets. Instead, you will see 15 to 30 different scripts, ranging from payment orchestration and fraud tools to analytics and session replay, all the way to tag managers, experimentation, consent logic, and accessibility widgets, with many loading from domains your security team has never directly vetted.

If your latest PCI DSS audit report flagged gaps against Requirements 6.4.3 and 11.6.1, it’s not time to panic yet. These findings are common and entirely fixable. Most of the time, the gap is between static guardrails and continuous runtime governance. QSAs assess whether you have active control over what executes in the client browser, not simply whether guardrails are configured. That is also why traditional controls like CSP or manual reviews can feel complete and still fall short.

Even well-maintained Magento and Adobe Commerce environments still land PCI DSS findings against 6.4.3 and 11.6.1. When that happens, it’s usually not a server-side Magento configuration issue. Instead, it’s a client-side runtime governance gap that Magento and most server-side stacks aren’t designed to close, even with helpful guardrails like CSP and SRI on payment pages.

The answer to whether WAF can see and prevent browser attacks that break PCI compliance depends on the lens you use. Through the lens of Requirement 6.4.2, the answer is mostly yes. But through the lens of 6.4.3 and 11.6.1, it gets a little blurry. Requirement 6.4.2 is about stopping web-based attacks at the application layer by inspecting outbound and inbound HTTP traffic at the server side.