PCI DSS 4.0.1 is public as of June 11, 2024, about two years and three months after the initial release of PCI DSS 4.0. Minor updates like this after such a major overhaul is expected, especially as all of you get your hands on the documents and start using them in assessments.
The update, which is available in the PCI Security Standards Document Library, contains mostly cosmetic changes that further align language introduced in PCI DSS 4.0. There was some shuffling of language from additional notes sections to the front matter as well as creation of some sections that did not exist prior. You will not see examples of the Customized Approach worksheets in the standard anymore as those are now on the PCI Council Website. This signals to me that the sheet is getting use and will likely need to be iterated for constant improvement as assessments continue and the Q/A process runs.
We now have content in the Errata section of our GitHub Community, so let’s dive into some of the updates.
Third Party Service Providers (TPSPs)
A clarifying note in the front matter helps to illustrate that the Council does not expect every TPSP to fill out documentation on how responsibilities are shared, but only those TPSPs that are meeting a PCI DSS requirement on behalf of the assessed entity. The end of the note further clarifies that TPSPs do not need to be compliant for the assessed entity to be compliant, they only need to support their customers’ compliance by providing status information so the assessed entity can manage and monitor for Requirement 12.8. There is also a change to Requirement 12.8.2, 12.9.1, and 12.9.2 that works to add more language clarifying the contractual requirements around TPSPs.
Requirement 3
Requirement 3.5.1.1 now includes a Customized Approach Objective, clarifying that it is eligible for the customized approach. Truncation and tokenization remain our favorite methods to meet this requirement.
Requirement 6
Requirement 6.3.3 reverts some of the requirement and guidance language to be in line with PCI DSS v3.2.1. The intent or interpretation of the requirement is the same, but more clarity around the Targeted Risk Assessment (TRA) that you would perform as part of 12.3.1. There is an example of 60 days for high-risk and 90 days for others, but all refers back to the TRA. Your QSA will want to review the process used in your TRA to determine your patch timeline requirements.
Requirement 6.4.2 includes expanded language on applicability, but suffice to say the intent is the same. You need to have an inventory of any piece of code that is part of your payment flow, or can affect the security of cardholder data and/or secondary authentication data.
Requirement 8
Requirement 8.4.2 now has a new exemption that looks to promote a strong passwordless flow. An addition was made in 4.0.1 that now says if you use phishing-resistent authentication factors (i.e., FIDO2 keys or Passkeys), that can be your only factor. Meaning, if you use this type of authenticator as a single, strong factor, that’s all you need, and no additional second factor is required. Note that FIDO2 is specifically called out in the definitions section of the Standard on page 389 which can include both a physical hardware key as well as a passkey.
Requirement 11
Requirement 11.6.1 is now focused on “security-impacting” HTTP headers and script contents. If you had a QSA using a broader interpretation and looking to review tons of items outside of that scope, those can be removed now. All that said, a good IT and Security shop will still monitor all code for modification, so this may be an appropriate internal security control to keep.
Requirement 12
Requirement 12.3.1 removes the periodic requirements language in favor of requirements that mandate a targeted risk analysis as a cleanup across the document to standardize language. The requirements in scope for this are: 5.2.3.1, 6.3.3 (recommended), 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.3.2 (applying to any requirement where the Customized Approach is used), and 12.10.4.1.
So there you have it. We’re in the middle of assessment season for PCI DSS 4.0(.1) and I’m sure you all will find more oddities or challenges as you work through your assessments.
We’d love to hear more from you! Don’t forget to participate in our GitHub Community! We’ve got tons of useful links there, including a link to join our Discord server for real-time chats about PCI DSS.