[in]security blog

PCI DSS v4 is Coming – What Can You Rely On

Written by David Gamey | Mar 4, 2022 2:00:00 PM

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

Goals and Objectives

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:

  • Accommodate changes in technology and new risk mitigation techniques
  • Address changes in the threat landscape
  • Promote security as a continuous process
  • Improve flexibility in meeting PCI DSS security objectives
  • Transition requirements from prescriptive controls to a more objective based approach
  • Increase industry participation in the development of the standard

All while maintaining a technology neutral posture.

Changes

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:

  • New attestation forms (AoCs) and Report on Compliance Templates (RoC)
  • Merchant Assessment Forms (MAFs) which are "a new approach to merchant self-assessments ... intended to replace Self-Assessment Questionnaires"

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

    • Protection for all transmissions of CHD
    • Use of self-signed/internal certificates
  • Requirement 8: Identify users and authenticate access

    • Password length, history, and change frequency that aligns with industry guidance
    • Comparing new passwords against a list of known, bad passwords
    • Confirming all multi-factor authentication factors before providing any indication of success or failure of a factor
    • Secure authentication for application/system accounts
  • Requirement 9: Restrict physical access to cardholder data

    • Location of sensitive areas within cardholder data environments
  • Requirement 11: Regularly test security systems and processes

    • Authenticated scanning for vulnerability scans
  • Requirement 12: Support information security with policies and programs

    • Usage policies for protecting critical technologies
    • Methodologies for data discovery and data leak prevention
  • New Customized Approach Option (to give)

    • More flexibility to organizations using different security technologies and methodologies to meet the objective of PCI DSS

The 2017 RFC / Feedback Cycle [#9] with stake holders identified a desire for changes in:

  • Authentication which aligns with NIST guidance on multi-factor authentication and passwords
  • Broader applicability for encrypting cardholder data on trusted networks
  • Monitoring requirements that consider technology advancements
  • More frequent testing of critical controls by possibly incorporating some Designated Entities Supplemental Validation (DESV, PCI DSS Appendix A3) requirements into regular PCI DSS requirements

Note: this section was udpated to list changes in reverse chronological order

Timelines from Development to Full Implementation

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.

Development

  • 2017 DSS v3.2 Feedback Cycle kicks off the DSS v4 Initiative
  • 2019Q4 RFC#1 generated over 3000 comments on the draft standard and sample reporting changes
  • 2020Q4 RFC#2 generated over 1800 comments on the revised drafts
  • 2021 July RFC#3 will look at the validation documents ROC reporting template, SAQ, and attestations (Revised from June)

Transition and Implementation Periods

  • 2022-01 Stakeholder Preview of DSS v4 DRAFT for Participating Organozations, QSA companies, and ASV companies (new)
  • 2022Q1 (v4) expected publication date for the Standard and validation documents (Revised from 2021Q4)
  • 2022Q2 (v4 + 6 mo.) publication of Validation Documents and Assessor Training and supporting documents, DSSv4 becomes fully usable
  • 2024Q1 (v4 + 2 yr.) DSS v3.2.1 retired and DSS v4 becomes mandatory (Revised from 2023Q4)
  • 2024Q3/2025Q1 (v4 + 2.5 to 3 yr.) various future dated requirements are expected to come into effect. A maintenance version of DSS is normally published once the future dates have all been passed. (Revised form 2024Q2/Q4)

This transition and implementation strategy has been used in previous DSS releases. The specifics for v4 from [#5]:

  • "The future date will be dependent on the overall impact that the new requirements will have on the standard. Based on the current draft, the future date is expected to extend beyond the planned transition period, with a possible future date being between 2½ – 3 years after PCI DSS v4.0 is published."
  • "The PCI DSS v4.0 standard is scheduled for completion six months prior to the release of the supporting documentation, training, and program updates that are required to support the use of PCI DSS v4.0. The PCI DSS v4.0 standard will therefore be available for 2 years prior to the retirement of PCI DSS v3.2.1."

We are Preparing for v4

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.

How Control Gap Contributes

Control Gap publications:

  • Our Weekly [in]Security news feed which covers all updates from the PCI Council and much more
  • Detailed change analyses of PCI standard updates
  • Specific articles on compliance and cybersecurity topics
  • An up-to- date index of all PCI FAQs

Control Gap has participated in several PCI SSC initiatives:

  • The ongoing Encryption Task Force
  • Small and Medium Business Task Force
  • SSL and Early TLS Migration Webinar
  • Information Supplement: Third-Party Security Assurance v1.0
  • Various PCI RFCs

Learn More

This section contains helpful links from the PCI Council website to give insight on the upcoming changes.

Official PCI Council Publications on DSS v4.0

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.

PCI Stakeholders and Request for Comment Publications

Control Gap References