Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Traditional HIPAA response plans were built for the incidents everyone can picture, like a compromised server, ransomware in the network, or unauthorized access to a clinical database. But website PHI leaks are different altogether. Often, there’s no attacker and no break-in. The leak comes from authorized tracking pixels or third-party analytics scripts simply collecting and sending data as designed, but on pages where it should never touch patient information in the first place.

Earlier, the anatomy of a HIPAA breach felt tangible. The threat landscape was shaped by risks you could point to, such as physical theft, phishing, or simple human error. Now, some of the biggest risks live in your website and run quietly in the background. Third-party scripts, tracking pixels, and analytics tags can collect or transmit PHI to external parties while looking like routine marketing infrastructure.

Content Security Policy looks like it was designed for PCI Requirement 6.4.3. You define which domains can load scripts on your payment page, the browser enforces it, and unauthorized code gets blocked. For teams drowning in third-party JavaScript, CSP feels like the obvious answer. Then you get to your audit, and the QSA starts asking questions CSP can’t answer.

If you operate pharmaceutical websites, portals, adherence tools, or patient support platforms, client-side execution is part of your compliance surface. Analytics, pixels, chat interfaces, and third-party libraries stop being neutral once they run alongside condition-specific content, authenticated access, or patient-initiated actions. At that point, they participate in disclosure. OCR’s clarification on tracking technologies did not create new obligations.

PCI used to fit neatly into a budget. You’d build your cardholder data environment, lock it down, gather evidence, and once a year prove to an assessor that everything worked. Costs were predictable because the work was concentrated: audit cycle, remediation sprint, then relative quiet until next year. That model broke somewhere around 2018. Now your payment flow touches cloud accounts, shared services, SaaS vendors, front-end code, and operational teams deploying changes on their own schedules.

Here’s a conversation that keeps happening: A compliance team passes their PCI audit in June. By September, they’ve had a card skimming incident traced to a third-party script nobody knew was running on their checkout page. Their tools didn’t catch it because none of them could actually see what was executing in the customer’s browser. That’s the gap PCI DSS 4.0.1 is forcing everyone to address.

Applicability thresholds of state privacy laws often hinge on size or scale. TDPSA is different. It puts no revenue thresholds like CCPA or CPRA. So if your business operates in Texas or reaches the state’s residents, you’re most likely inside the scope already. The law took effect on July 1, 2024, and by January 2025, the universal opt-out obligations became fully enforceable. That transition is what moved TDPSA from a policy update to a website-level requirement.