PCI DSS v4.0 is coming and will bring big changes. The exact nature of the changes aren’t yet available as the standard is still evolving under the PCI Councils Request For Comment (RFC) process. In the next few months, many articles will get published talking about what is coming. Organizations naturally want to know what to expect so they can be ready when v4 arrives. They also don’t want to invest their effort, resources, and funds in the wrong place. Sorting out what is certain from guesses, speculation, leaks, misinformation, and what may change should be a priority for any compliance team. In this article, we address all these issues to show you what is reliable and to help guide you through the maze. We address objectives, timelines, transitions, future dated requirements, and even some of the feedback on requirements. Lastly, we will tell you what we are doing to help our customers.
Everything known about PCI DSSv4 comes from official PCI Security Standards Council (SSC) publications and presentations. There are over a dozen publicly available documents and updates. You can find these organized, indexed and summarized at the end of this article. Details of the upcoming draft changes are restricted to participants in the RFC process who have all signed NDAs to ensure that the public receives reliable information about a stable standard. Any articles making more detailed claims should not be considered reliable as they are either speculating or leaking information.
While this article should help to raise awareness of v4 and to begin pre-planning, both the PCI SSC and Control Gap recommend NOT implementing new controls to meet draft compliance requirements that may yet change [#5]. DO take advantage of this information to prepare for the transition and future dated requirements implementation periods.
Updated per PCI Council publications: 2021-07-16 [#1b], 21-06-18 [#1a]. Originaly published 2021-05-07
This is the first major change to PCI DSS in many years (DSS v3.0 debuted in 2013Q4) and the long transition to migrate away from SSL and early TLS. Knowing v4 will be with us for a long period the SSC had several ambitious and much needed goals [#3, #9, #8, #7] if the standard was to keep up with changes to today’s rapidly evolving payment ecosystem. The objectives included evolving the standard to:
All while maintaining a technology neutral posture.
While the basic 12-requirement high-level structure of the standard will not change [#9], just reading between the lines of the goals and objectives hints at things like new controls, old controls applied in new places, more frequent activities, more rigour on big picture items, and significant rewording. Beyond this we know somethings from the DSS v3.2.1 feedback, published summaries of RFC#1 feedback, and some of the additional updates.
The description of RFC#3[#1b] describes the new validation documents. While new versions of templates and forms are expected, the notable news is a new document called a MAF:
The Feedback from RFC#1[#4] went into more detail including new and changed requirements including much feedback for the following verbatim:
Requirement 4: Protect cardholder data (CHD) with strong cryptography during transmission
Requirement 8: Identify users and authenticate access
Requirement 9: Restrict physical access to cardholder data
Requirement 11: Regularly test security systems and processes
Requirement 12: Support information security with policies and programs
New Customized Approach Option (to give)
The 2017 RFC / Feedback Cycle [#9] with stake holders identified a desire for changes in:
Note: this section was udpated to list changes in reverse chronological order
We’ve pieced together a timeframe of known and expected events from the inception of the DSS v4 initiative to the activation of future dated requirements as described in the referenced articles [#a, #1, #5, #10]. While future dates (in italics) may yet change, this timeline is based upon the published articles.
Organizations concerned about the impact of changes and future dated requirements should focus on the expected transition and future dated implementation period.
This transition and implementation strategy has been used in previous DSS releases. The specifics for v4 from [#5]:
At Control Gap, we are preparing for the arrival of v4 so that we can assist our clients. At this point in time, this is very much quiet work behind the scenes. We participate in the RFC process as a QSA company analyzing the drafts and providing feedback. The RFC process allows us to evolve our internal tools and processes to be DSSv4 ready, keep our assessors aware of the upcoming changes, and track potential client issues so that we can proactively help our clients as soon as DSSv4 is published.
We have analyzed all RFC changes and potential impacts in forensic detail, we will update our analysis during the upcoming RFC draft in June, and with any future changes. We will share our updated analysis with customers and friends once PCI DSS v4.0 is published and the RFC NDA no longer appies.
Control Gap publications:
Control Gap has participated in several PCI SSC initiatives:
This section contains helpful links from the PCI Council website to give insight on the upcoming changes.
A summary of DSSv4 updates from newest to oldest going back to the inception of the DSS v4 initiative in 2017. Articles cover the objectives, processes, consultation, timing, updates, expected publication, transition, and eventual future dated changes.