Table of Contents
Updated by 07.12.2023
There’s More Than One Way to Comply With PCI DSS v4.0. So Which Approach is Best?
Giving organizations the flexibility to use different methods of achieving security objectives ranks among the primary goals of v4.0 of the Payment Card Industry Data Security Standard (PCI DSS). Compliance with PCI DSS v4.0 will remain optional until March 31, 2024, when PCI DSS v3.2.1 is retired. But now, rather than later, is the right time for businesses of all types to start thinking about how they will implement and validate controls called for in PCI DSS v4.0 in other words, whether they will follow the defined approach and use compensating controls where necessary, or instead adopt the customized approach. Here is a rundown of these approaches to aid in the decision-making process.
As its name indicates, the defined approach is just that a set way of implementing and validating controls mandated in the PCI DSS. It is already being used to meet requirements set down in PCI DSS v3.2.1. As was the case with PCI DSS v3.2.1, entities that follow the defined approach when they transition to PCI DSS v3.2.1 can opt to leverage compensating controls if they have a “legitimate and documented technical or business constraint that prevents them from meeting the defined approach requirement as stated”, according to a recent blog post published by the Payment Card Industry Security Standards Council (PCI SSC). Entities often use compensating controls in situations where a legacy system or process cannot be updated to satisfy the requirement.
PCI DSS v4.0 includes a proviso that prohibits merchants from using compensating controls to retroactively address requirements with which they previously have not complied. For example, according to the blog, it was “never the intent” that compensating controls could be used “in situations where a task that should have been performed was not performed, and “no action was taken at the time to address it”.
Meanwhile, the customized approach differs significantly from the defined approach and compensating controls alike. It is intended for entities that choose to meet control requirements in a different manner than is stated in the PCI DSS rather than, as with compensating controls, for entities that have a constraint and are unable to meet PCI DSS requirements as stated. Instead of a stated requirement or requirements, organizations that elect to follow the customized approach must meet the stated customized approach objective(s) stipulated in the standard.
Which Approach and When?
The PCI SSC considers the defined approach to be well suited for organizations that have controls in place to meet a requirement and are comfortable with the current methods of validating controls prescribed in it. It is also deemed suitable for organizations that are new to PCI DSS and may want or need more specific direction on how to meet security objectives.
Meanwhile, according to the blog, the council considers the customized approach to be “most successful” when an entity has robust security processes and strong risk management practices in place. An entity will also be more successful with the customized approach if it has the ability to effectively design, document, test, and maintain security controls to meet the stated objective.
“The customized approach is an alternative to the defined approach and focuses on a PCI DSS requirement’s stated customized approach objective,” according to the blog. “This approach provides greater flexibility and is suited for organizations that want to use alternate security controls or new technologies that meet the PCI DSS customized approach objective”.
Compensating controls cannot be used with the customized approach. However, the PCI SSC notes in the blog, “an entity can use compensating controls for certain system components and the customized approach to meet that same requirement for other system components”. For example, for Requirement 5.3.1, “an entity could use a compensating control to meet that requirement for a certain type of server where there is a legitimate and documented business constraint that prevents the server from meeting the stated requirement”, while simultaneously harnessing the customized approach to “meeting the same requirement for other system components, where it has implemented a unique approach to detect and address malware threats. The entity could also use the defined approach to detect and address malware threats”.
Table of Contents