As organizations face new challenges with PCI DSS 4, we explore what these changes mean and how businesses can effectively manage compliance.
PCI DSS 4 requirements such as 6.4.3 & 11.6.1 will affect any merchant or payment provider with a payment page or application that accepts credit cards, debit cards, and more.
This Q&A features key considerations from a HUMAN security x SADA webinar on PCI DSS 4 compliance
Robert Kusters, product marketing manager at HUMAN; Rocky Giglio, global director of security solutions, SADA; and David Mundhenk, co-founder of PCI Dream Team, discussed the impact of PCI DSS compliance on business operations.
View the full webinar here.
Q: What are your customers' levels of concern with PCI DSS 4 right now?
A: David Mundhenk
My concerns have grown since I started doing PCI DSS 4 assessments. When we wrote The Definitive Guide to PCI DSS 4 with the PCI Dream Team, we had not yet completed any assessments under this new framework.
Now that I’ve done a few, I see most of my clients are very unprepared—not just in understanding whSat’s required but also in knowing how to achieve compliance.
There are a lot of lessons learned so far, and most of my clients are struggling with these changes. Many QSAs [qualified security assessors] and QSA firms didn’t anticipate how much work would go into completing these assessments either.
A: Rocky Giglio
It’s similar to what David has seen. There are key changes in PCI DSS 4, but many customers are still in the “We’ll get to that” mindset. They’ve checked some boxes, but more work must be done.
There’s also been a shift in how PCI DSS 4 brings good security practices to the forefront, which should help prioritize efforts. However, the general consensus is that there’s still much left to tackle.
Q: David, since you've done a couple of audits under PCI DSS 4, what did you learn? What was the difference you saw?
A: D.M.
PCI DSS 4 is a significant leap from the previous version. The PCI Security Standards Council did a great job clarifying requirements; everyone benefits from that. However, one major challenge is the level of detailed documentation required. While many companies have been documenting policies for years, they often fall short in documenting processes and procedures, which is now essential.
Many of my clients are trying to get by with the minimum effort, aiming for a checkmark rather than truly meeting the spirit of the standard. We go back and forth, with them submitting documentation and me responding that while it’s good, it’s insufficient. That’s been a big hurdle.
Q: When PCI DSS first started, almost everyone was on-premises. There was none of this cloud stuff. There may be some client servers, but 90%, maybe even 100% of clients, have a direction to move to the cloud.
Q: How will the move from on-prem to the cloud or hybrid deployments affect customers with PCI DSS 4?
A: R.G.
In summary, I don’t think there’s a huge change in the challenges we’ve always faced. We still have connected systems with layers of complexity—payment outsourcers, merchants, and others involved in the transactions. The core issues remain: protecting data, securing systems, and doing encryption right. Those challenges carry forward.
What changes with the cloud is the speed at which we can deploy systems and environments. It’s become much easier to integrate third-party services like marketplaces, so while the core challenge is the same, the scale and speed of operations have evolved. In general, security best practices are shifting toward code-driven infrastructures, and we’re starting to see that approach make its way back to on-prem environments. However, many on-prem users still struggle with this transition.
In cloud environments, things may be easier. But as David mentioned, we still face the same struggles. The key challenge remains: we must focus on security through system design, whether in the cloud, on-prem, or [in] a hybrid setup. If security isn’t built in, you’ll always be playing catch-up.
Q: How does someone in the GRC compliance practice prepare for an audit, especially when using various services, particularly in the cloud?
A: D.M.
Rocky made some important points about the speed and scale of cloud environments. Many of my clients are constantly tearing down and rebuilding their cloud environments, which adds complexity to their operations. At the same time, they’re incorporating new technologies like serverless computing and containers. The traditional secure software development lifecycle (SDLC) still applies, but with agile development, no one’s doing waterfall anymore.
You have to be strategic about where to apply security design, evaluation, testing, and quality assurance; it must all be baked into the process. Unfortunately, many organizations are still playing catch-up in this area.
I’m a big fan of Microsoft’s security development lifecycle framework, where innovative security practices are integrated from start to finish. However, many clients struggle to keep systems running and secure without even getting into compliance.
As a former application security professional, I trained people on secure coding and application threat modeling. What I’m seeing now is that many are in reactive mode, making it hard for them to stay ahead of security and compliance requirements.
Q: Are there tools or parts of the cycle that make it easier to document or understand as you go along?
A: D.M.
Yes, I’m a big fan of Microsoft’s SDL processes, but over the past five or six years, I’ve noticed a significant gap in most secure SDLC practices—they tend to ignore the client-side web browser completely. I’ve coined the term "Mariana Trench of Attack Surfaces" to describe this gap. The only people paying attention to client-side browser interactions have been malware creators, social media platforms, and some unscrupulous marketers.
I use the Mariana Trench analogy because, much like the deep ocean, the client-side web browser is largely uncharted. It wasn’t until 1960, when a submersible dove 27,000 feet down, that we gained visibility into that space. Similarly, HUMAN provides visibility into this previously overlooked area, helping companies meet PCI DSS requirements like 6.4.3 and 11.6.1. HUMAN’s technology is crucial in providing that visibility, and I commend them for it.
A: R.G.
Thanks, David. I like your example with 6.4.3, where visibility into scripts is essential. In web development, the first thing many developers do is copy-paste code from elsewhere. It’s common practice, but the problem is: who knows what’s in those scripts? A simple script can call others, which can contact even more. You could add ten scripts to a website and end up with 100 scripts being executed.
That’s where HUMAN stands out, offering protection for these scripts, which is critical because everything from banking to buying a house is now done online. Many payment transactions through websites and mobile apps are enormous, and many rely on scripts. Securing them is a big challenge, but HUMAN makes it easier.
Of course, other tools are available in the end-to-end security space—tools for compliance tracking, audit reporting, and more. But before diving into tools, developing solid policies and practices is essential. PCI DSS 4 requires organizations to document what scripts are being used and why they are being used.
Once you’ve established these practices, you can look at tools that simplify documentation, integrate with other systems, and help with audit reporting. Many emerging tools streamline processes like configuration management and data collection, and these tools are evolving to meet the growing needs of the industry.
Q: When you talk about tools, one of the main things you need is integration between them. Do you see that in the tools you're recommending?
A: R.G.
Yes, absolutely. We’re seeing a lot of overlap in the tooling space, particularly with configuration management. Every security company now seems to have a cloud security posture management tool.
So, you'll find tools that handle PCI audits and cloud security posture management and then offer additional features like compliance tracking or vulnerability management.
This is why it’s essential to step back and first ask: What do we actually need to accomplish? If you don’t, you’ll end up with a stack of tools, spending a ton of money, but without better clarity into your environment—just a bigger bill. So, have that strategy conversation first, and then look for tools that integrate well with your existing stack.
There are big players everyone supports and smaller vendors specializing in integration, focusing on specific tasks like documentation. Many of these tools have many integrations that allow you to pull data from other systems, giving you a clearer picture of your security posture.
Ultimately, the goal is to avoid retooling your entire setup. The better the integration, the easier it becomes to manage everything efficiently.
Q: David, many companies outsource tasks like payment processing. If I outsource my payment page or processing to third parties, am I still responsible for ensuring compliance?
A: D.M.
Absolutely. The PCI Council has made it clear over the years that even if you outsource payment processing, you’re still responsible for ensuring those third parties comply. You’re also on the hook to ensure your service providers have their processes in order.
Rocky touched on an important point: the supply chain in software development. Many developers today aren’t writing code from scratch; they’re pulling code from GitHub or other repositories without thoroughly vetting it for integrity. SolarWinds and the recent CrowdStrike incidents are perfect examples of how this can go wrong. CrowdStrike may not have gone through all the proper QA and validation steps before rolling out the affected updates.
Even if you outsource, if your company’s logo is on the website or product, you’re still responsible for ensuring the third-party provider is compliant. PCI DSS also requires that you hold these providers accountable through service-level agreements (SLAs) and written contracts covering both business and incident response obligations.
With cloud services—whether SaaS, PaaS, or IaaS—there’s a shared responsibility between you and the provider, depending on your chosen model. You need to have all these shared responsibilities clearly outlined in SLAs. The last thing you want during a disaster is to have everyone pointing fingers in a “network family feud” scenario, where no one takes responsibility.
It’s essential to hammer out these agreements before deploying anything. This remains a serious challenge for many organizations.
R.G.
David, you touched on a growing theme here. The CrowdStrike incident highlighted that there’s still a lot of work to be done in patch management, which is now a key part of PCI DSS 4.0. For customers aiming for compliance, vulnerability management is something you must cover and plan for.
You also mentioned the liability and legal aspects. It’s not as simple as saying, “We’re doing patch management.” You need to explain why and how you’re doing it. This involves legal teams and contracts that outline the liabilities. For example, when did you last read a software’s End User License Agreement (EULA)? There are disclaimers there that you need to be aware of.
In today’s fast-paced world, everything is moving faster, and understanding these contracts and managing liabilities can’t be overstated.
OK. So, Rocky, does compliance mean secure?
A: R.G.
Wouldn't that be great? David’s laugh says it all. Unfortunately, no—compliance doesn’t mean you’re fully secure. There’s no scenario where you can say, “We’ve done everything, and now no one can breach us.” Unless you’ve taken everything offline and shut it down, which isn’t realistic for doing business, there will always be risks.
We have to strike a balance. Even when you’ve followed all the right steps, there’s no guarantee. Take the CrowdStrike incident as an example. Many of those customers likely had good patch management strategies. They followed the proper steps and had QA teams testing everything, but things still went wrong.
So, we need to shift our mindset. It’s not just about checking boxes; it’s about preparing for what could go wrong. As David mentioned earlier, a response plan is essential. Compliance ensures you’re closing doors and locking windows, but you also need a backup plan in case something does happen. Think of it like having a homeowner’s insurance policy—you lock your doors but are also prepared for a fire or break-in.
In cybersecurity, the question isn’t just, “Are we compliant?” It’s, “What do we do if something goes wrong?” Who do we call? Who’s in charge of handling it? Having those answers is critical.
AI and machine learning are in the news everywhere. Will AI make it easier or harder for customers to comply with PCI DSS 4?
A: D.M.
The PCI Council has already issued a guideline on how AI impacts the PCI space. Obviously, payment card data is personally identifiable information (PII), which is very sensitive. But PII isn't the only thing that's sensitive when interacting with applications online.
AI can both help and complicate things when it comes to compliance and security. On one hand, AI can streamline processes and make compliance easier. On the other hand, it could add new challenges as we figure out how to manage it effectively going forward.
Organizations must start thinking about AI now, not when it’s too late. And they’re facing issues head-on. I’m still trying to catch up with all the implications AI brings—it’s moving so fast that it feels impossible to keep pace. However, organizations need to look at how AI fits into their compliance strategies. I’m sure Rocky has some thoughts on this, too.
A: R.G.
Absolutely. AI is a massive focus for us at SADA, mainly because we’re Google’s largest partner. From their cloud platform to Google Maps and Workspace, there’s an incredible amount of AI work. You’ve probably seen the ads for Google’s Gemini, and they often talk about how, in the next five years, we’ll see the equivalent of 100 years’ worth of innovation.
David is right—things are moving faster than we can keep up with, and AI offers benefits and challenges. On the positive side, let’s say you’re building a website. You can use a GenAI tool like Gemini to write code that integrates secure payment systems, pulling scripts from repositories worldwide in a matter of minutes. What might have taken weeks before can now be done in minutes, which is fantastic for creating new revenue streams and improving platforms.
AI also helps with security by reviewing code and integrating it into response plans and analytics. Some third-party tools use AI to enhance everything, from security audits to real-time threat response. But, as much as AI brings these benefits, we still don’t know a lot. That’s why it’s essential to have organizational-wide discussions about AI and how to integrate it into policies and compliance strategies.
Just like with PCI compliance, companies need a plan for AI. It’s already being used inside your organization, so it’s not a matter of “if”—it’s about understanding how to manage it effectively.
Given that PCI DSS 4 is now in effect, and we have until March 2025 to meet the new requirements, what are the top three things an organization should focus on to get ready for compliance?
A: D.M.
First, it’s crucial to actually understand the standard. I can’t tell you how many clients haven’t even sat down to read through the entire thing. Sure, it’s not the most exciting reading, but if you don’t know what you’re being measured against, you will struggle to meet the requirements.
Second, be aware of the documentation requirements. Ensure you understand what you’re responsible for and what needs to be documented. Many organizations underestimate how much documentation is involved, so don't overlook this.
Third, some requirements—like the Threat Risk Analysis (TRA)—have been pushed out until next year. You must document and demonstrate that you’ve done your due diligence well before March for many requirements. Many people think they can deal with it later, but that’s like trying to re-engineer a 747 mid-flight. You need to get ahead of it.
Lastly, you need visibility into client-side web activity, especially if handling online payment card data. As Rocky mentioned, all the scripts and third-party script calls being executed must be understood and documented.
You won't be compliant if you don’t have visibility into what’s happening with those scripts. This is where HUMAN technology really helps—you need that visibility to meet the requirements, and HUMAN provides it.
Thumbs up to HUMAN for offering that capability.
Q: Rocky, what are your top three things to focus on for PCI DSS 4 compliance?
A: R.G.
For me, the top three start with policy discussions. Have an organization-wide, leadership-driven conversation about what needs to be accomplished. Who are the key players? Who’s responsible for each part of the standard, and how will you drive compliance from a policy perspective?
Second, focus on the basics—start with a secure foundation. If you're working in the cloud, SADA always helps our customers with this. Build security from the beginning. Make sure basic things like multi-factor authentication (MFA) are turned on for all users.
Third, ensure you have basic logging for everything happening in your environment. This might sound like general good security practice, but that’s precisely why it’s critical. These foundational elements are required for PCI DSS 4 compliance.
As a bonus, I recommend getting your vulnerability management sorted out as you go. This will be important for keeping your systems secure and compliant.’
For more on PCI DSS compliance, check out HUMAN here.
