Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Most websites today are more complex than their owners realise. A single page can load a mix of analytics, pixels, and vendor scripts, all shaping how personal data flows through the browser. And because GDPR now treats this browser activity as processing, it becomes part of the compliance picture even when it comes from third-party tools. Which means regulators naturally expect organizations to understand this activity as it happens.

How do you choose a tool that can actually show what third-party scripts are doing on your payment pages? It starts with recognizing the scale of what runs there.

In late November 2025, developers and API users of ChatGPT and OpenAI’s platform received a note that felt personal: an alert about a data exposure linked not to OpenAI’s own servers but to a third-party analytics vendor. That vendor was Mixpanel.

You only really get to influence your PCI-DSS audit in two places: how you design your controls, and who you let judge them. QSA selection is the second one, and it’s usually underestimated relative to how much it shapes your next 3–5 years. Under PCI DSS 4.0.1, the assessor’s judgment matters more because several requirements move the discussion into client-side behavior. Scripts, page changes, and third-party components now factor into how compliance is validated.

When organizations fail PCI audits, it is rarely because they lack documentation or controls. They fail because they cannot prove those controls operate reliably when a QSA evaluates them. Requirements 6.4.3 and 11.6.1 expect evidence that reflects the page as the browser renders it. QSAs look for evidence that shows the controls running on the actual rendered page during the assessment period. This expectation is clear in the standard, and it is the point where many teams struggle.

Most teams spend more than 40 hours a week just keeping their payment page script inventories updated. And that’s meticulous work as they have to load the page, watch what scripts fire, map domains, and compare it all to the last version, just to ensure the changes are documented before the details go stale. Also check out How to Maintain PCI Compliance Across Hundreds of Payment Pages But for organizations with 50 to more than 200 payment pages, it goes even further.

Below is a look at how the Feroot platform evolved in 2025 and how these improvements support your compliance and security strategy heading into 2026.

When you’re operating with just five payment pages, PCI feels predictable. Not because controls are simple, but because the variables are contained. It’s simple math. You know the pages. You know the scripts. You know how often they change and who owns each one. So the environment is small enough that nothing surprises you, and predictability becomes the default. But then, your organization grows. New products, regional variants, A/B experiments, and acquisitions all add up.