I was thinking about the future generation of PCI DSS standards and tried to summarize my view – what I would expect from PCI v5.0, and what I would like to see in the future version. Please don’t take it too seriously, this is just my opinion/prediction; however, I would be happy if this article kicks a discussion.

So, these are generic changes I would expect:

1. First and foremost – extending PCI DSS applicability from cardholder data to payment facilitation data – acquirer and issuer tokens, digital identity data, mobile wallet IDs, A2A transfers, etc.
2. Considering point A, it makes sense to make Part 2 of the PCI 3DS standard an appendix to PCI DSS for 3DS service providers.
3. Targeted risk analysis. It will stay in place. Currently, it is required to define the frequency of periodical activities and address customized approach to PCI DSS requirements. I would expect it to also address different sampling of components and applicable requirements (e.g., different approaches to CDE systems (Category 1) and connected systems and systems performing security functions (Category 2)). I mean, you would expect a penetration test of the CDE system, but you don’t necessarily expect a penetration test of the cashier’s PC.
4. Combine Defined and Customized Approaches – for example, when the entity uses a Defined Approach CDE (Category 1) and a Customized Approach for connected systems and systems performing security functions (Category 2).
5. Specify that certain assessment testing procedures may be performed by the customer (e.g. PingCastle AD assessment, ScoutSuite cloud configuration assessment, automated evidence generation) – if this is performed by qualified personnel (e.g. ISA) and organizational independence is maintained.
6. Specify what assessment steps cannot be performed by ISA – e.g., taking part in customized approach validation, assessing SAD storage requirements, etc.
7. Introduce categories of PCI service providers – similar to P2PE component providers. Currently, service providers undergo PCI DSS assessments, but often it is hard to say what specific requirements they are responsible for. I would suggest introducing specific categories of PCI DSS service providers (pretty much like it’s done for P2PE Component Providers). By doing so, we will have defined subsets of PCI DSS requirements, which must be covered by the service provider (e.g., Datacenter SP, Encryption Service/HSM SP, Tokenization SP, CSP, Payment Software Vendor, SOC, etc). This will help to eliminate ambiguity in this matter.
8. Considering the previous point, document how the entity may leverage the service provider’s validation to achieve their own compliance – pretty much how it’s already done for Software SLC vendors and Requirement 6.
9. Compensating control management – document approach to continuous improvement of compensating controls. The entity cannot be compliant using the same compensating controls for years.
10. Consider availability requirements for critical system components or systems performing security functions.

Now, let’s jump into 12 PCI DSS domains.

1. Install and Maintain Network Security Controls.
   1. For virtual and cloud environments, consider recommendations of “PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures” – those related to zero trust, infrastructure as a code, containerization, etc.
2. Apply Secure Configurations to All System Components.
   1. Add references to well-known and recognized bodies that provide guidance on system hardening (such as CIS).
3. Protect Stored Account Data.
   1. Add specific requirements to POIs and HSMs (whenever applicable) to align with PIN Security/P2PE requirements.
   2. Add specific requirements to End-to-End Encryption solutions to align with PIN Security/P2PE requirements.
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.
   1. For “trusted certificates”, if internal CA/third party CA is used, add specific high-level requirements to CA.
5. Protect All Systems and Networks from Malicious Software. Nothing really comes to my mind.
6. Develop and Maintain Secure Systems and Software.
   1. Emphasize the importance of software supply chain management.
   2. Align with Secure Software Appendix C in terms of Software Bill of Materials – SBOM.
7. Restrict Access to System Components and Cardholder Data by Business Need to Know. There’s not much to add.
8. Identify Users and Authenticate Access to System Components.
   1. Identify and restrict weak MFA methods – such as pre-shared VPN certificates, SMS OTP, etc.
9. Restrict Physical Access to Cardholder Data. There’s not much to add.
10. Log and Monitor All Access to System Components and Cardholder Data.
    1. Add requirements to the availability of log management and analysis mechanisms.
11. Test Security of Systems and Networks Regularly.
    1. For segmentation testing in virtual and cloud environments, consider recommendations of “PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures”.
12. Support Information Security with Organizational Policies and Programs.
    1. Add requirements to managing AI usage for CDE, connected systems, and systems performing security functions.

Read More About Security Audits: