Now that you are looking at your timeline, you may be wondering how you can get from where you are now, a sage of PCI DSS 3.2.1, to where you will need to be by 2024.
The PCI DSS 4.0 Summary of Changes
Using the PCI DSS Summary of Changes document, you can begin to look at what changed during the RFC process and how each of these changes reflect the ongoing progression in PCI DSS compliance.
Now let’s take a look at some of the changes required by the council, control-by-control. We’ll start in Requirement 1. I should state that, for the purposes of this and future blogs, I will not be discussing the “Customized Approach Objective” sections. We will deal with those in another blog series as they add a great deal of freedom, and complexity, to a PCI DSS 4.0 audit.
Requirement 1 Changes
In all Requirements, documentation has been moved from the tail-end of the requirement window to the front, emphasizing the importance of policies and procedures. If you don’t have proper policies and procedures, you will likely have trouble with compliance with most of the rest of the requirements in each area:
In 3.2.1, Requirement 1 had several controls in 1.1.x, but several of these have been transferred to 1.2x, reworded, and 1.1.4 has been removed. Here are a couple of notable examples of changes:
Control Clarification
In 1.1, configuration standards were mandated to be implemented and testing was also required. 1.1.x requirements have largely been refocused in 1.2.x and have been further specified to clarify what the requirement is asking. This language makes it easier for an entity to know what is required, and for an assessor to properly vet the control. Take a look at how 1.1.1a-c changed into 1.2.2.a-c:
As you can see, more clarification has been added, leaving less room for guesswork and interpretation with respect to the control requirement.
Control Splitting
Another example is the separation of requirements that were previously joined in section 1, such as 1.2.1. Here’s DSS 3.2.1 with both inbound and outbound traffic put into 1.2.1:
Compared with DSS 4.0 with inbound in 1.3.1:
And outbound in 1.3.2:
While this may seem like just adding more controls, if you’ve ever had to explain to a client that their outbound traffic looks great, but they failed the control because of one port allowing any/any traffic inbound, you’ll understand why this made sense to split.
Control Merging
How about some simplification, please? Check out how the council merged 1.3.1, 1.3.2, and 1.3.5.
DSS 3.2.1:
DSS 4.0:
Notice how 3 controls, which all focused on the same objective (inbound traffic restrictions) is now grouped into one objective for simplicity.
One final piece of news is that no new control requirements were added in the 4.0 iteration of Requirement 1! Given the complexity of Requirement 1 to both comply with, and audit, this is a breath of fresh air.
Feeling a little overwhelmed? If so, most of the community agrees. While the changes made to 4.0 have a goal of ultimately better protecting our cardholder data, they won’t come without some heavy lifting.
If you have further questions or are interested to see how your company fares against 4.0 today, reach out and we would be happy to discuss with you further.
Recent Comments