The first half of 2022 has been quite interesting for the cybersecurity community due to the publication of the ISO/IEC 27002:2022 - Information security, cybersecurity, and privacy protection - Information security controls standard in February and the publication of the version 4.0 of the PCI DSS standard in March. In both cases, the objective was to update existing security controls and add new requirements to adapt them to current technological changes and cybersecurity threats.

In the case of PCI DSS v4.0, Advantio has prepared a series of articles where a detailed analysis of the development process of this version of the standard, the changes in the requirements, and the adaptation process from version 3.2.1 to version 4.0, among other topics, will be made.

In this first part of this series, we will discuss the history behind version 4.0 of the standard, the variables that influenced its change, and the associated review and publication process. Subsequent articles will review the changes to the requirements and reporting documents and finally, we will propose an action plan for aligning the controls from version 3.2.1 to version 4.0 to meet the timelines established by the PCI SSC and the payment brands.

History

The Payment Card Industry Data Security Standard (PCI DSS) was created as a result of the joint work of the main payment card brands, which opted to centralize the security controls of their different compliance programs in a single standard that would facilitate the implementation of security measures and the management of cardholder data protection in a homogeneous manner, avoiding overlaps, duplications, and inconsistencies.

Analysis of PCI DSS v4.0 - Part I: Introduction

Figure 1. Centralization of payment brand security controls in the PCI DSS standard

 

Thus, in 2004, the first version of the PCI DSS standard was published, which defined the basic principles of cybersecurity for the protection of payment card data to be implemented by any entity that processes, stores, and/or transmits such data, mainly merchants and service providers. Subsequently, in 2006, version 1.1 of the standard was published, this time developed by the Payment Card Industry Security Standards Council (PCI SSC), an independent entity composed of the main payment card brands and responsible for managing the life cycle of PCI DSS and other payment industry standards.As the affected companies implemented and managed the controls of the standard, the PCI SSC began to receive comments and suggestions from different organizations related to payment security, something that would eventually influence the publication of the following versions of the standard, incorporating improvements, clarifications and minor corrections based on the feedback provided by the community.

Analysis of PCI DSS v4.0 - Part I: Introduction

Figure 2. Timeline of the PCI DSS standard

 

In order to manage specific periods in the publication of the PCI DSS standard that would allow the PCI SSC to analyze and incorporate updates in the document based on the experience of the companies with its implementation and the evolution of technologies and threats, a period of 36 months was defined with eight stages that would allow a gradual and staggered introduction of the changes.

However, this initiative did not last for long due to different external variables that forced the publication of subsequent versions of the standard to be brought forward or delayed, including the impact of different SSL and TLS vulnerabilities in the transmission of cardholder data over open public networks and the optimization of the processes for receiving comments from different organizations. In fact, in the development of version 4.0 of the standard, the periods set out in this lifecycle were not followed, and this will probably not be the case with future versions either.

Analysis of PCI DSS v4.0 - Part I: IntroductionFigure 3. Change management lifecycle of the PCI DSS standard (not currently used)

 

Development and publication of the PCI DSS v4.0 standard

PCI DSS version 3.2.1 was released in May 2018 as a minor version that included some clarifications and revisions to version 3.2, released in April 2016. Arguably, no substantial changes were added to the standard since that year (2016), as a balance had been struck between the maturity level of controls and cybersecurity needs at that time.

However, the technological changes in infrastructures linked to the massification of cloud services, the adoption of container-based platforms and orchestration and microservices, and the implementation of development practices such as DevOps, made it necessary to adapt the PCI DSS standard to recent times in order to face the challenges arising from emerging threats against cardholder data.

Unlike previous versions of the standard, for the development of PCI DSS version 4.0, the PCI SSC defined a new working model that allowed the different organizations related to card payments to actively participate in the review and preparation of the standard and its supporting documents through comment periods (Request for Comments (RFC)). For the development of PCI DSS version 4.0, two RFC exercises were executed: one in the last quarter of 2019 (with more than 3,200 comments) and another between September and November 2020. Similarly, at the close of the RFC processes, a draft of the standard (PCI DSS v4.0 Draft for Stakeholder Preview) was shared exclusively with Participating Organizations, Qualified Security Assessors, and Approved Scanning Vendors to finalize version 4.0, which was published at the end of March 2022, following more than 6,000 comments received from more than 200 entities.

Although the RFC processes allowed for the aligning of the standard to the reality of the entities that must implement security controls, they also forced the postponement of the release of version 4.0, initially scheduled for Q2 of 2021, then for Q4 of 2021, and finally published in Q1 of 2022.

PCI DSS v4.0 Implementation Periods

Once PCI DSS version 4.0 and its supporting document templates (Report on Compliance (ROC) and Attestation of Compliance (AOC)) were published, the PCI SSC confirmed the dates during which the two standards would be valid in parallel, the official withdrawal date of PCI DSS v3.2.1 and the applicability date of controls with an effective date in the future, to allow for proper implementation by affected entities:

Advantio PCI DSS Blog Artwork_4 (1)

Figure 4. Implementation periods of PCI DSS v4.0

 

In accordance with these dates, a transition period of 24 months has been defined from the publication of the PCI DSS v4.0 standard (March 2022) in which the previous version (3.2.1) and version 4.0 can coexist, which means that affected organizations can be assessed with either version indifferently. However, as of March 31, 2024, the only valid version for evaluations will be version 4.0.

Translations of the standard and the related Self-Assessment Questionnaires (SAQ) and Attestation of Compliance (AoC) will be published during the second quarter of 2022.

Main changes in the standard's approach

Note: Changes related to the requirements of the standard will be discussed in future articles in this series.

During the process of developing version 4.0 of the PCI DSS, the PCI SSC's priorities were to manage evolving risks and threats to payment data and to strengthen security as an ongoing process. As a result of applying these criteria, the names of the groups of requirements and the requirements of the standard changed between version 3.2.1 and version 4.0 to reflect this evolution in controls and to adopt changes in technologies:

Advantio PCI DSS Blog Artwork_5Figure 5. Changes in the names of the 6 groups of PCI DSS 4.0 requirements

 

Advantio PCI DSS Blog Artwork_6

Figure 6. Changes in the names of the 12 PCI DSS v4.0 requirements.

 

On the other hand, version 4.0 incorporates a large number of clarifications in the applicability of the standard that had been expected for years, so that those ambiguous areas or those that gave rise to interpretations have been clarified and there is now an official position on the matter, which previously might not exist or might be present in the PCI SSC Frequently Asked Questions (FAQ) or in other supporting documents, but not in the standard as such.

Some of these clarifications are:

Advantio PCI DSS Blog Artwork_7-3Figure 7. List of clarifications included in the PCI DSS v4.0

 

However, the most significant change between PCI DSS versions 3.2.1 and 4.0 is the introduction of the Customized Approach concept. While in the traditional approach (now called "Defined Approach") the entity implemented the established technical controls as they appeared in the standard, in the Customized Approach the entity can select the control it considers most adapted to its environment to manage the related risk, offering greater flexibility and adaptation to emerging solutions. Thus, in PCI DSS v4.0, an entity can choose to use either the Defined Approach or the Customized Approach depending on its needs.

Advantio PCI DSS Blog Artwork_8Figure 8. Description of the Defined Approach and the Customized Approach in PCI DSS v4.0

 

In addition, the PCI SSC has added a large number of graphical aids (flowcharts and figures), as well as clarifications in the margin, guidelines on each of the requirements, templates, examples, etc. that make this version one of the most descriptive and self-explanatory of all those that have been published, although this has meant going from 139 pages in PCI DSS v3.2.1 to 360 pages in PCI DSS v4.0.

The second part of our PCI DSS v4.0 Analysis series will look at requirements 1 and 2 of the standard, which is a part of the "Build and Maintain a Secure Network and Systems" group, focused on the monitoring and control of incoming and outgoing network traffic, as well as the configuration of system components or hardening.

 

Read Part 2: Requirements 1 & 2 here.

 

Advantio_PCI-DSS-V4.0_Part-1_CTA_V1.0 (1)

References 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.

Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor

Schedule a call with an expert