Preparing for PCI DSS 4.0

Andrew Barratt, Managing Principal, Solution Validation, Coalfire

PCI DSS 4.0 is currently in its request for comments (RFC) process, where the industry can provide comments and feedback to help shape the next iteration. This process is initially open to the participating organizations – members that help steer and inform the PCI SSC based on their experiences. The RFC period for PCI DSS 4.0 ends in November 2019, and the council hopes to release PCI DSS 4.0 toward the end of 2020. 

The PCI SSC has highlighted the specific areas below for the industry: 

  • Authentication, specifically focused on NIST MFA/password guidance (NIST SP 800-63)
  • Broader applicability for encrypting cardholder data on trusted networks
  • Monitoring requirements to consider technology advancement 
  • Greater testing frequency for critical controls; for example, incorporating some requirements from the DESV (Designated Entities Supplemental Validation) – PCI DSS Appendix A3 – into regular PCI DSS requirements

If we delve more deeply into each of these areas, they show support for some new payments initiatives as well as help the standard evolve to some emerging risks.

Authentication is important, not just as part of the access control processes that we need for logging into systems, but also as an expectation in the payment process. With PCI SSC and EMVco working closely together, I’m sure more will be presented that shows how the new 3DS standard (both PCI and EMVco) can be used as part of a transaction authorization to enable Secure Customer Authentication. The new 3DS standard enables pluggable authentication options – allowing issuers the flexibility to build solutions that can meet a variety of regulatory requirements around the world as well as adapt to changing expectations from cardholders and the devices they use for payment, while still supporting the “in-transaction” risk management that is so common with the EMVco approach.

The PCI 3DS standard is an interesting indicator of the direction the PCI SSC may take with future iterations of the PCI DSS. It’s a much more flexible, “Control Objective”-based standard with fewer of the requirements being prescriptive; rather, it sets a security objective and allows the standards adopter to put controls in place that they feel meet that objective. Theoretically, this will allow the standard to support more seamless cross-over with others such as ISO 27001 and the Trust Principles.

The broader applicability for encryption has been mooted over the years, and with the PCI-P2PE standards getting more traction among the service provider community, it could be an area that becomes more prevalent, perhaps in response to threats that take up residence in a network and harvest cardholder data in transmission.

I can envisage the greater frequency of testing and addition of controls from the DESV standard getting a lukewarm response. DESV is very prescriptive and was originally geared toward entities that had suffered a breach and needed to have both their controls and assessment programs scrutinized. However, a lot of the more robust requirements that have made it into the PCI DSS’ current incarnation started out in the DESV, so it’s not too much of a surprise.

The PCI SSC’s “monitoring of requirements to consider technology advancement” is the biggest indicator that we may see a more risk-based approach take hold in the standard. This may well lead to a shift toward a more pluggable adoption of other PCI standards, such as the Software Security Framework and security objectives that, with guidance, allow for adoption of technology solutions that can move more quickly without being put into a specific control box.

Andrew Barratt


Andrew Barratt — Managing Principal, Solution Validation, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS