In conversation with Simon Wijckmans, CEO at web security platform c/side, to understand the impact of PCI DSS 4.0.1 on organizations.
BN: Since the March 2025 deadline for PCI DSS 4.0.1 compliance passed, what key challenges are companies facing in trying to meet the updated standards?
SW: One of the main challenges we’ve noticed is that businesses are not recognizing or fully understanding the new PCI DSS requirements early enough. While it’s understandable that enterprises follow a rigorous process involving multiple stakeholders and careful planning, this slower approach needs to be considered when setting timelines for compliance.
Another challenge is that many organizations are still new to client-side security. This area demands more internal education and awareness, and while it’s a steep learning curve, it’s promising to see that more information and training resources are becoming available.
There’s also a big shift in the scope of PCI DSS with the 4.0.1 version compared to the earlier 4.0 framework. Even if you use a third-party payment service embedded through an iframe, you’re now expected to actively monitor your website’s client-side security and HTTP security headers. Previously, companies felt they could rely entirely on third-party services for compliance, but under the new rules, that’s no longer enough.
BN: For companies operating across borders with multiple payment systems and regional regulations, how do these new PCI DSS rules align or conflict with standards like GDPR and other privacy laws?
SW: Large companies often run dozens of websites beyond their main one — sometimes for specific campaigns, events, or partnerships — and these are usually handled by different agencies using varied payment solutions.
Just like with global privacy laws, each of these websites must meet PCI DSS standards individually. When multiple third parties are involved, accountability becomes unclear if something goes wrong. That’s why we believe businesses, whether large or small, should take full ownership of their compliance efforts instead of depending entirely on partners.
Unlike some other frameworks that vaguely refer to “third-party risks,” PCI DSS is very specific about client-side security. That’s a huge benefit because it clears up any confusion about whether browser-side scripts are included in the compliance scope. In contrast, frameworks like DORA, HIPAA, and SOC 2 mention dependency management in more general terms. This has led to a situation where many website owners don’t actually know what their website or its dependencies are doing inside a visitor’s browser.
BN: Requirements 6.4.3 and 11.6.1 focus specifically on browser-based scripts. Why has this area become such a high priority for the PCI Security Standards Council?
SW: Over the years, there’s been a strong focus on cloud security, open-source code protection, and backend threats. But cybersecurity is like a bucket with many holes — fix one, and another one starts leaking faster. That’s what we’re seeing with client-side attacks.
Browser-side web script attacks have been around for some time, but they’re happening more frequently now. The PCI community has recognized this growing risk and is working to stop it. Most credit card theft today happens right in the browser. And it’s not just card data at risk — session tokens, personal information, crypto mining scripts, and even DDoS attacks can originate from third-party browser scripts.
BN: A lot of companies are still using outdated methods to manage and monitor scripts. What kind of security gaps does that leave open in the current threat environment?
SW: A good example is the use of Content Security Policy (CSP) headers. These are essentially manual rules that restrict scripts unless they come from trusted sources. But here’s the catch: they don’t verify what the script actually does once it’s loaded.
Take the Polyfill attack, for instance — it was one of the biggest client-side breaches last year. Around half a million websites were compromised because a single domain changed ownership. The new owner could then deliver any malicious code directly into visitors’ browsers. This went unnoticed for months, from February to June 2024, possibly affecting millions of users. And since no one was monitoring the payload, we still don’t know exactly who was impacted.
The problem is that the script’s URL didn’t change, so CSP policies didn’t flag it. That’s why it’s so important to monitor the actual content — or payload — of the scripts being executed, not just the source URL. That’s the only way to truly protect your users.
BN: PCI DSS 4.0.1 now emphasizes continuous monitoring rather than just yearly audits. How is this transforming how organizations manage security?
SW: Yearly audits just aren’t enough in today’s environment — especially when it comes to client-side security. JavaScript is designed to be dynamic, meaning it can load different things based on conditions like time of day, browser type, user behavior, and more. Attackers can cleverly serve malicious code only a small percentage of the time or to very specific users.
If you’re only checking your scripts once a year, you’re like a paper plane trying to chase a fighter jet — it’s impossible to keep up.
BN: With businesses facing potential fines in the six-figure range and even the risk of losing their ability to process payments, how should they prioritize these PCI updates compared to their other cybersecurity efforts for 2025?
SW: The financial penalties for not complying with PCI DSS — and especially the possibility of losing credit card processing abilities — are serious. This makes compliance with critical requirements like 6.4.3 and 11.6.1 essential for any business that accepts payments online.
But even if you’re technically compliant, if a cyberattack slips through, you’re still exposed to lawsuits and other consequences. We’ve even heard of cyber insurers increasing premiums for organizations that suffer breaches, even if they were compliant at the time. In fact, many insurers now demand PCI DSS compliance, but that alone won’t guarantee coverage unless you’ve also implemented strong security controls. So skipping real implementation in favor of just ticking boxes is a risky move.
BN: Looking to the future, how do you think these PCI DSS changes will shape broader cybersecurity strategies and how businesses handle sensitive payment information?
SW: It’s very encouraging to see regulations becoming more specific and more rigorous. Sure, it means extra work and investment for companies, but it’s all aimed at protecting users — especially those making purchases online.
Better security also helps businesses in the long run. It strengthens their defenses and reduces their exposure to modern web threats. At c/side, we’re proud to be part of the PCI SSC Associate Participating Organization program. It gives us a chance to contribute insights to the council based on what we’re seeing on the ground. We fully support their work and the direction they’re moving in — toward a safer internet for everyone.
Source – https://betanews.com/2025/04/18/what-compliance-with-pci-dss-4-0-1-means-for-businesses-qa/