The new version 4.0 of the PCI DSS standard that applies to organizations that handle payment cards is now mandatory as of April 01, 2024. As a QSA, I’ve heard rumblings about organizations that moved their annual PCI DSS assessments earlier in 2024 so they could squeeze in one last assessment under version 3.2.1 before it was retired on March 31. Similarly, some organizations are planning to perform their next annual assessment prior to the new version 4.0 future-dated requirements coming into effect after March 31, 2025. These organizations may be playing a dangerous compliance game.

I can’t fault organizations that have tried their best to implement PCI DSS version 4.0 or the future-dated requirements but want to move their assessment earlier because they are not confident they will pass their assessment despite their efforts. What worries me are organizations that seem to think they do not need to implement the new requirements until just before the next annual assessment after the effective date passes. For example, if they performed a version 3.2.1 assessment before the deadline in March 2024, they think the version 4.0 requirements do not need to be in place until just before their next assessment in March 2025 and that the future-dated requirements do not need to be in place until just before their March 2026 assessment.

PCI SSC FAQ 1176 states that “Future-dated requirements are considered best practices until the future date is reached, after which those requirements will be effective and applicable.” Note that the FAQ does not say that the requirements become effective and applicable just prior to the next annual assessment after the future date is reached. Most PCI DSS version 4.0 requirements should already be implemented as of April 01, 2024 when version 3.2.1 was retired, with the exception of the future-dated requirements, which must be implemented on or before April 01, 2025 to remain compliant. Organizations that are not attempting to implement the version 4.0 requirements by the effective dates are intentionally making themselves non-compliant, potentially for nearly an entire year.

Whether or not a QSA will know if an organization they are assessing implemented a specific requirement on time is a different question. An assessment occurs at a specific point in time, and it could be difficult for a QSA to detect if some requirements were not implemented by the effective date. Delayed implementation of some other requirements is much more obvious. It is much easier to identify when a requirement was first implemented if the requirement generates dated records that the testing procedures require the QSA to review, especially for activities that are required periodically.

Requirement 3.3.2 (which is future-dated to 2025) is an example where a QSA would have a hard time determining when the requirement was implemented. The requirement states that sensitive authentication data (SAD, e.g., CVV numbers) must be encrypted if they are stored prior to authorization. The PCI DSS testing procedures instruct the QSA to examine data stores, system configurations, and/or vendor documentation to verify that the SAD is encrypted. A QSA will have no way of knowing if encryption was only started a few days before the assessment unless someone tells them so during an interview, especially because all of the SAD must be deleted after authorization (Requirement 3.3.1), eliminating any old data that the QSA otherwise might stumble across.

The future-dated requirements that require a Targeted Risk Analysis (TRA) conducted in accordance with Requirement 12.3.1 are all examples where it will be easy for a QSA to determine when the requirement was first implemented due to an obvious paper trail. The PCI SSC template for documenting the TRA includes a field for both the date the TRA was originally performed and when it was last updated. The QSA is required to review the TRA documentation, and the date on the TRA form will show the QSA if the TRA was performed after the effective date unless the organization being assessed backdates the documents. Many of the activities that must be performed at a defined frequency will also generate records of their own, and the QSA may request to see these records all the way back to when the requirement first came into effect. Missing records are a clear red flag that should be cause for a QSA to dig deeper.

Keep in mind, this also applies to changes in the PCI DSS Self-Assessment Questionnaires. For example, SAQ A for eCommerce merchants did not include ASV scanning under PCI DSS version 3.2.1, but it was added in version 4.0. ASV scans are another example of a periodic activity where a late start will be immediately obvious due to the lack of third-party scan reports for previous quarters. eCommerce merchants using SAQ A should conduct their first  quarterly ASV scan by June 30, 2024 (the end of the quarter after version 3.2.1 was retired) at the latest, regardless of when they are next due to complete their SAQ.

QSAs have some leeway to mark organizations compliant if minor lapses are identified and corrected during the assessment. I can’t speak for all QSAs, but if I found an organization made efforts to comply with the changes and fell short due to a misunderstanding, I would work with them to correct the issue so they could be marked compliant. Conversely, I would not consider it a minor lapse if an organization was willfully and intentionally non-compliant for most of a year following the effective date of version 4.0 or the future-dated requirements. I would likely mark those organizations as non-compliant, barring extenuating circumstances. Additionally, I would have absolutely no mercy if I found a client was fraudulently backdating documents or lying during interviews to cover up their failure to be compliant on time.

PCI SSC has long had a predictable rollout timeline for new versions of PCI DSS so organizations have had plenty of warning and time to implement any necessary changes. Version 4.0 was released to the public in March of 2022. This means organizations had 2 years to implement the non-future-dated requirements in PCI DSS version 4.0 before version 3.2.1 was retired on March 31, 2024. Organizations will have had 3 years to implement the future-dated requirements by the time March 31, 2025 rolls around.

TrustedSec recommends organizations that are subject to PCI DSS compliance make every effort to align with the version 4.0 requirements immediately and preparing to have the future-dated requirements in place by March 31, 2025. Even if compliance is not perfect, it’s much easier to explain and address minor misses than wholesale non-compliance. TrustedSec has been helping our clients prepare for PCI DSS version 4.0 since it was released, and we continue to help our clients prepare for the future-dated requirements. We are available to help understand the requirements and the most efficient ways to implement them in any environment.