On March 31, 2022, the PCI Security Standards Council released the new version of the Payment Card Industry Data Security Standards (version 4.0), which represents an update almost four years in the making. In addition to some clarifications and rearrangements, the new PCI DSS 4.0 includes 51 new requirements for all entities, and 13 new requirements for service providers (now called TPSPs—third party service providers). Of those new requirements, 13 are effective immediately for anyone undergoing a PCI DSS v4.0 assessment; 51 are “best practice” until March 31, 2025, at which time they will be mandatory. In addition, each requirement now includes an entry for “Customized Approach Objective,” because the Council will allow entities to adopt an approach that “does not strictly follow the defined requirement” as long as it meets the stated objective in accordance with the Council’s requirements. The Council noted that this new approach “is intended for risk-mature entities that demonstrate a robust risk-management approach to security, including, but not limited to a dedicated risk-management department or an organization-wide risk management approach.” (Standards at 28.) The previous version of PCI DSS (3.2.1) is retired as of March 31, 2024. Either PCI DSS 3.2.1 or 4.0 can be used for assessments between now and March 31, 2024 (page 36).
Customized Approach
For those entities that elect to follow the Customized Approach, note that the approach need not be used for all requirements. The Council has provided new Appendices D and E that include further information and sample templates for documenting the controls matrix as well as the targeted risk analysis, both of which are mandatory for each requirement using this new flexible approach.
This new approach requires documentation and evidence about each customized control, as well as a targeted risk analysis for each such control. Under Appendix D, the entity would have to perform testing of each control “to prove effectiveness, and document testing performed, methods used, what was tested, when testing was performed, and results of testing in the controls matrix.” The entity would also need to monitor and maintain evidence about each customized control’s effectiveness.
New Requirements for All Entities
Some of the changes in v4.0 reflect changes in technology over the past four years, such as changing “firewalls” and “routers” to “network security controls” in Section 1. Others reflect changes in the environment, such as new requirements relating to malware and phishing in §§ 5.3.2, 5.3.3, and 5.4.1 (all best practice until March 31, 2025). Others reflect changes in security recommendations, such as increasing password length from 7 to 12 characters (in § 8.3.6) and use of multi-factor authentication (in §§ 8.4.2 and 8.5.1) —best practice until March 31, 2025, as well as a new option to determine access via dynamic analysis as opposed to changing passwords every 90 days (in § 8.3.9). As indicated, there are many new technical requirements, which are generally best practice until March 31, 2025, but you will probably need to get started now with planning and implementation.
Some changes are granular. For example, Section 12.10.7 requires that “Incident response procedures are in place, to be initiated upon the detection of stored PAN [primary account numbers] anywhere it is not expected, and include: . . . determining where the account data came from and how it ended up where it was not expected.” In other words, you may need to perform a data inventory to locate whether you have or are transferring any primary account numbers in the clear and, if so, update your incident response plan if they appear anywhere else.
One of the new requirements that is effective immediately for any organization undergoing a v4.0 assessment is the documentation requirement for roles and responsibilities of the individuals in charge of each section’s requirements, and making sure that they are assigned and understood. Another such requirement is an annual assessment of PCI DSS scope (§ 12.5.2).
Service Providers
There are 13 new requirements for TPSPs, including some new ones only for “multi-tenant service providers” (formerly, “shared hosting providers”), which will be required to support their customers for external penetration testing in § 11.4.7 (best practice until March 31, 2025). In addition, the multi-tenant service providers will be required to confirm that access to the customer environment is logically separated to prevent unauthorized access–and the provider must confirm the effectiveness of those controls via penetration testing every six months in §§ A.1.1. and A.1.4 (best practice until March 31, 2025). The multi-tenant service provider must also implement “processes or mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities” in § A.1.2.3 (best practice until March 31, 2025).
All TPSPs will need to have a documented description of their cryptographic architecture that includes prevention of the use of the cryptographic keys in both the test and production environments, in § 3.6.1.1 (best practice until March 31, 2025). Similar to the requirements for covered organizations, if the TPSP uses passwords as the only authentication for customer user access, passwords must be changed every 90 days or conduct a dynamic analysis to determine real-time access to resources” in § 8.3.10.1 (best practice until March 31, 2025). TPSPs will also be required to use intrusion-detection and/or intrusion-prevention techniques to detect, alert, prevent, and/or address covert malware communication channels, in § 11.5.1.1 (best practice until March 31, 2025).
Although the Council did not designate it as a “new” requirement, v4.0 replaces the terms “system breach” and “compromise” with the broader “suspected or confirmed security incident” in § 12.10.1. One aspect of the PCI DSS that did not change was the scope: the Council maintains that the standards apply to “entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE [cardholder data environment].” (see page 4). Those relevant requirements would apply to TPSPs as well. The Council provides this example: “TPSPs that store backups of cardholder data on behalf of customers would need to meet the applicable requirements related to access controls, physical security, etc., for their customers to consider those requirements in place for their assessments” (pages 16-17). The Council provides TPSPs with two ways to validate PCI DSS compliance to their customers: (1) an annual PCI DSS assessment, with evidence to customers that it meets the standards or (2) undergo assessments from each customer upon request of the customer (page 17).
Our Take
For those companies that wish to use the new flexible standard, you should start now with assessments to determine which requirements would be good candidates. With respect to all other entities subject to the new requirements, you should carefully review the many changes and determine how best to get into compliance. You may need new policies and procedures, new tools, and revised agreements with your third parties, so you should start the inventory and planning process now.
