Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

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.

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.

Two Indiana healthcare providers, Goshen Health System and Hancock Regional Hospital, recently reached settlements tied to the use of website tracking technologies, including Meta Pixel. Neither organization admitted to any deliberate misconduct, emphasizing that the settlement is done to avoid the cost and disruption of continued litigation.

You don’t have to dig far into a payment page before the pattern makes itself obvious. A few scripts are yours. A few belong to vendors you expected. But then the list keeps going, and you start to see something else.

It starts with a simple audit. Your legal team checks Business Associate Agreements after OCR’s tracking technology guidance. Google Workspace BAA: signed. Analytics platform BAA: signed. CRM and marketing tools: covered. Then the question that changes everything: Do we have BAAs for the tracking pixels on our patient pages?

The Office of the Australian Information Commissioner’s (OAIC) 2025 approach places more weight on how systems behave than how policies read. It reflects a broader shift that has been building for some time. APP 11, in particular, now rests on understanding the small, routine movements inside modern web and mobile environments. It’s because the environment drift rarely announces itself. New endpoints appear, SDK permissions adjust, and minor code changes influence how data is handled.

As a health-related technology company, you are not registered as a “healthcare provider”; therefore you are not HIPAA-covered. But under the Health Information Privacy Reform Act (HIPRA), your health app, wearable, or connected device may soon be held to the same privacy and security expectations as one.