TL;DR
PCI DSS v5 is expected to expand beyond protecting only card data (PAN/CVV) to include broader payment and personal data
The standard is evolving from highly prescriptive requirements to a more flexible approach
Payment providers may have more responsibility to assess and justify their security decisions
While this introduces flexibility, it may also increase complexity and compliance burden
Organizations should begin preparing for a more dynamic approach to managing security and compliance
Introduction
For years, PCI DSS has been the foundation for securing payment environments.
It has provided clear guidance focused on protecting cardholder data, especially the primary account number (PAN) and sensitive authentication data like CVV. This approach has helped standardize how organizations think about security and compliance across the payments ecosystem.
But the payments landscape is changing.
Tokenization, alternative payment methods, and evolving data flows are reducing reliance on traditional card data. At the same time, new types of risk are emerging, often outside the narrow scope PCI has historically focused on.
Because of this, the standard itself is starting to evolve.
How PCI DSS Has Traditionally Worked
Prior to v4.0, the PCI DSS was very prescriptive.
Organizations were expected to meet clearly defined controls with little room for variation. Requirements like password length, access controls, and monitoring processes were spelled out in detail. Compliance largely came down to whether these specific requirements were met.
The scope was also straightforward.
If an organization stored, processed, or transmitted cardholder data, especially PAN or sensitive authentication data, it was considered in scope. If not, data often fell outside PCI requirements.
This structure made compliance easier to understand, even if it wasn’t always easy to implement.
What’s Changing in PCI DSS v5
While PCI DSS v5 is not expected to be released in the near future, early discussions within the PCI Security Standards Council point to two major areas of anticipated change.
1. Expanded Data Scope
In the past, PCI DSS has focused heavily on protecting PAN and sensitive authentication data.
Future versions may expand that scope to include broader payment-related and personal data, even if a PAN is not present.
This could include things like:
Cardholder name
Transaction-related data
Other forms of personal or payment-related information
The idea behind this is simple. Even if traditional card data is removed through tokenization, other data can still create risk, especially when you consider modern privacy regulations and breach scenarios.
2. A More Flexible Approach to Security
PCI DSS has already started moving in this direction with version 4.0, which introduced the Customized Approach and targeted risk assessments.
Version 5 is expected to take this further by focusing more on the intent of controls, rather than exactly how they are implemented.
In practice, this means:
Less rigid, one-size-fits-all requirements
More flexibility in how organizations meet security goals
More reliance on internal risk assessments to support decisions
For example, instead of being told exactly how often a control must be performed, organizations may determine the right frequency based on their environment, as long as they can explain and justify that decision.
Why This Shift Is Happening
These changes reflect what is happening across the payments industry.
First, tokenization and alternative payment methods are reducing exposure to traditional card data. Focusing only on PAN and CVV is no longer enough to understand where risk exists.
Second, risk has not disappeared. It has simply moved.
Personal data, transaction details, and other surrounding information can still be sensitive. In many cases, privacy regulations like GDPR make breaches of that data even more serious than traditional PCI DSS violations.
Finally, payment environments are getting more complex.
Organizations now operate across multiple systems, vendors, and integrations. That makes rigid, prescriptive controls harder to apply consistently.
The Tradeoff: Flexibility vs. Complexity
These changes introduce a clear tradeoff.
Benefits
A more realistic security model that reflects modern payment environments
Greater flexibility to adapt controls to specific systems
Better alignment between actual risk and how security is applied
Challenges
A broader set of data to manage and protect
More ambiguity in how requirements are interpreted
Greater responsibility on organizations to assess and justify their approach
For some organizations, this flexibility will be helpful. For others, it may make compliance more challenging, especially if internal resources or expertise are limited.
What This Means for Payment Providers
For ISOs, acquirers, PayFacs, and other payment providers, this represents a meaningful shift.
Compliance is becoming less about checking boxes and more about demonstrating that the right controls are in place for the environment.
This means:
More responsibility to evaluate systems and data
More emphasis on documentation and decision-making
Less reliance on fixed, standardized requirements
In practice, teams will need a clearer understanding of where risk exists, not just whether requirements are met.
How to Prepare for What’s Next
Even though PCI DSS v5 is still evolving, there are steps payment providers can take now.
Look beyond PAN and understand where other sensitive data exists
Review how risk is currently identified and managed
Be prepared for more flexibility, along with more accountability
Stay up to date with guidance from the PCI Security Standards Council
Taking these steps early can make the transition smoother as changes are introduced.
Conclusion
PCI DSS is moving away from a strictly prescriptive model toward a more flexible approach that better reflects how payment environments actually operate today.
As these changes take shape, payment providers will need to rethink how they approach compliance, security, and data protection across their systems.Will PCI DSS v5 expand the scope of compliance?