On 11 June 2024 the PCI SSC published version 4.0.1 of the PCI DSS standard, which replaces version 4.0 published in March 2022 This new version contains minor revisions, formatting and typographical corrections and clarifications without adding or removing requirements from version 4.0.
After a couple of years since the release of version 4.0 of the PCI DSS standard, the PCI Security Standards Council (PCI SSC) decided to evaluate and integrate some minor changes to the standard that emerged from experience in implementing security controls by entities affected by this standard (mainly merchants and service providers). As a result, PCI DSS version 4.0.1 was published in June 2024, the documents of which can be downloaded from the PCI SSC homepage: Standard PCI DSS v4.0.1. Likewise, all the details of the changes between versions can be found here: Summary of changes between versions 4.0 and 4.0.1.
Some of the most relevant changes in this release are:
Using disk-level or partition-level encryption (3.5.1.2):
- The following sentence was added in the Applicability Notes of the request: ‘This requirement relates to any encryption method that provides clear-text PAN automatically when a system runs, even though an authorized user has not specifically requested that data‘. This paragraph may lead to the inclusion of methods used in databases such as Transparent Data Encryption (TDE) as a control that may require the implementation of additional mechanisms such as those described in requirement 3.5.1.
Installing security updates (6.3.3):
One of the changes that most affected the deployment of updates was the 6.3.3 that in version 4.0 required that the updates critical or high they shall be installed within one month of their publication. Version 4.0.1 returns to the criteria of PCI DSS v3.2.1 where only critical updates must be installed within one month after publication, while the rest must be deployed according to the periods defined by the entity:
- PCI DSS v4.0: Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
- PCI DSS v4.0.1: Patches/updates for critical concerns (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
Monitoring of scripts on payment pages (6.4.3):
Clarifications were added that extend the responsibility in the monitoring of scripts on payment pages to those providers that allow their content to be embedded in the customer's payment page (through iFrames, e.g.). In this regard, the supplier must demonstrate that it complies with this requirement as part of its contractual responsibilities (req. 12.9).
Change passwords every 90 days (8.3.9):
It is clarified that the requirement to change passwords every 90 days or dynamic analysis in real time of the security posture of the account does not apply to system components in the range where MFA is used.
Use of MFA in non-console accesses to the CDE (8.4.2):
It is clarified that this requirement does not apply to user accounts that are authenticated only with factors that are resistant to attacks from phishing (phishing resistant).
A phishing-resistant authentication element (Phishing Resistant Authentication) are those designed to prevent the disclosure and use of authentication secrets to any party other than the legitimate system in which the user is attempting to authenticate (e.g. through in-the-middle or spoofing attacks). Phishing-resistant systems typically implement asymmetric cryptography as a basic security control.
Systems that rely solely on knowledge-based or time-limited factors, such as passwords or single-use passwords (OTPs), are not considered resistant to phishing, nor are SMS or magic links (magic links).
Some Examples of Resistant Authentication phishing are FIDO, including devices such as Yubikeys o Passkeys.
Use of physical access controls to the CDE (9.2.1):
It is clarified that this requirement does not apply to locations that are publicly accessible to cardholders (cardholders).
Use of automated mechanisms for the review of logs (10.4.1.1):
It is clarified that for the use of automated mechanisms for the review of logs it is important to establish a baseline (baseline) normal patterns of activity. Comparison between this baseline and new behaviours will facilitate the identification of suspicious activities.
Monitoring changes and manipulations in HTTP headers and content scripts on payment pages (11.6.1):
As with requirement 6.4.3, the scope of this requirement is extended not only to the entity but also to its service providers when content from such providers is embedded on the entity's payment page.
Written Agreements and Acceptances of Liability for Card Data by Providers (12.9.1):
It is clarified that a written agreement (written agreement) in which a provider is responsible for the card data provided by a client entity for the purposes of the service must be a separate document in which these responsibilities are explicit and cannot be replaced or covered by any of the following documents:
- The Attestation of Compliance (AoC) of PCI DSS provided by the provider
- A written statement on the provider's website
- A statement of principles (policy statement)
- A matrix of responsibilities
Entry into force of PCI DSS v4.0.1 and withdrawal of PCI DSS v4.0
PCI DSS v4.0.1 came into effect at the time of publication, so both versions of the standard (v4.0 and v4.0.1) will be valid until December 31, 2024, when version 4.0 will be withdrawn.
Other related documents such as templates Report on Compliance (RoC), Attestation of Compliance (AoC) and Self-Assessment Questionnaires (SAQ) will be updated throughout Q3 2024.
More information on the PCI SSC blog: Just Published: PCI DSS v4.0.1.
EN 
ES