What compliance with PCI DSS 4.0.1 means for businesses [Q&A]

The latest revision to the PCI DSS standard for protecting payment data, PCI DSS 4.0.1, was announced last year and came into force last month.

But what do these new requirements mean for businesses? We spoke to Simon Wijckmans, CEO at web security platform c/side, to find out.

BN: Since the March 2025 deadline for PCI DSS 4.0.1 compliance, what are the most significant challenges organizations are facing in meeting these new requirements?

SW: From what we've seen, organizations are later in noticing and understanding the new PCI DSS compliance requirements than they ought to be. While thorough due diligence and multi-stakeholder approval processes are (of course) hallmarks of enterprise security, these necessarily longer implementation cycles need to be factored into compliance planning.

Additionally, client-side security is a relatively new domain for many organizations, requiring significant education and awareness-building across teams. We are, however, encouraged to see an increasing flow of information and educational resources in this space.

Another point here is that there's a big shift between the new PCI DSS mandates and the previous PCI DSS v4.0 scope that’s been out for three years now. Even if you use a third-party payment provider for online transactions in an iframe you still need to monitor your client-side security and security headers. Previously the mentality regarding PCI DSS was that you could push this over to a third-party service, but that alone under the new scope will not suffice.

BN: For enterprises that operate globally with multiple payment systems and regulatory frameworks, how do these new PCI DSS requirements overlap or potentially conflict with other data security standards like GDPR or regional privacy laws they need to maintain compliance with?

SW: We've learned from enterprise customers that they often have tens (if not more) websites along with their primary one (for specific events, partnerships, etc). These are often managed by external agencies, and with various payment gateways.

When it comes to PCI DSS, it's the same story as with the privacy laws you mention. Each site needs to be independently compliant. With third-party partners involved, the lines become a bit blurry on who’s actually responsible when it goes south. In my opinion, both enterprise and smaller companies alike need to be aware of this, and take the best practice of taking the reins themselves.

Unlike other frameworks that talk about 'third-party dependencies' more generally, PCI DSS calls out client-side security explicitly. This is a good thing, as it removes doubt whether client-side executed dependencies are in scope. Other frameworks like DORA, HIPAA and SOC2 talk about dependency management at too high a level. That’s caused the awkward situation that most website owners do not know how their website or dependencies behave in a user's browser.

BN: The new requirements 6.4.3 and 11.6.1 specifically target browser-side web scripts. Why has this become such a critical security focus for the PCI Security Standards Council?

SW: Companies and the cyber security industry have increasingly invested in cloud security, open source dependency security, etc. But the cyber security space is a bit of a leaky bucket. Once you patch one hole, the other leaks faster. This is exactly what is happening in client-side attacks.

Even though attacks using browser-side web scripts have been happening for a while, we are seeing a marked increase. The PCI community have rightly been aware of this, and are taking the needed steps to mitigate this problem. The majority of credit card theft nowadays happens in the browser, so imagine the wider scale attack surface with session tokens, sensitive information, crypto mining, and even DDoS attacks originating from third-party web scripts.

BN: Many enterprises are still using legacy security strategies for script monitoring. What are the potential blind spots or vulnerabilities this creates in today's threat landscape?

SW: A widely popular one is the use of a Content Security Policy (CSP). These are manually set rules that allow or restrict a script from fetching if it is not originating from an allowed source. However, the payload of a script is not verified.

The biggest client-side attack of last year -- the Polyfill attack -- saw nearly half a million websites compromised because of just one domain changing ownership. Almost no companies were aware of this change, and suddenly the new owner could load anything in the browser of the visitors. We're talking millions of visitors a day that were possibly being targeted between February and June 2024. And we don’t even know for sure which ones, because the bad actor had access to the domain but no one was watching during that period

It's very easy to pull off an attack by changing the payload. A CSP header wouldn't stop that, as the URL remained the same. This is why monitoring the exact payload of the script that loads is so important. Only then you are certain your users are not impacted.

BN: There's been a shift from annual audits to continuous monitoring in PCI DSS 4.0.1. How is this changing the way organizations need to approach their security infrastructure?

SW: In the client-side security space, the fact is that annual audits are too slow. JavaScript is designed to be dynamic so that it can load anything it wants in browsers, based on many factors. An attacker can load the safe script 99 percent of the time and the malicious one just one percent. Time zones, user agents, other scripts… These are all factors that an attacker can use to circumvent security systems.

With just one annual audit you're racing a fighter jet with a paper plane -- you'll never beat it.

BN: With potential penalties including six-figure monthly fines and suspension of card acceptance capabilities, how will or should organizations prioritize these new requirements against other cybersecurity initiatives in their 2025 planning?

SW: Fines from this perspective are due to non-compliance of PCI DSS and other regulations. The need to comply with requirements 6.4.3 and 11.6.1 (what we focus on) should be a priority to not lose your credit card acceptance capabilities that, of course, would be disastrous for any organization’s revenue stream.

This, however, does not rule out other fines. If an attack sneaks through, even though you were compliant with both requirements, you are still a target for possible lawsuits and fines. We've also heard of customers being informed that their cyber insurance rates would go up if any kind of attack should occur regardless of compliance. In fact, cyber insurers already require PCI DSS compliance, so should you tick the box but not implement proper security measures, you risk both compliance violations and insurance complications.

BN: Looking ahead, how do you see these new PCI requirements influencing the broader cybersecurity landscape and how organizations securely handle payment data?

SW: It's extremely positive to see these regulations becoming tighter. Yes, it often means an extra investment and workload from organizations to comply. We must, however, remember the core idea behind these regulations: keeping site visitors -- and specifically buyers in regards to PCI DSS -- safe on the web. This ultimately also benefits the companies bolstering their security, as an extra line of defense in a space which sees increasingly more attacks.

We are a proud member of the PCI SSC Associate Participating Organization program. This allows us to sit down, talk and inform the council on changes we see happening in the client-side security space. We can only applaud them for setting the benchmarks for a safer browsing experience.

Image credit: Audioundwerbung/Dreamstime.com