PCI DSS 3.2.1 to 4.0 Control Changes – Requirement 2

by | Feb 16, 2023 | Compliance, cybersecurity, PCI DSS 4.0

Print PDF

Submit your email address to access the PDF of this post.

  • This field is for validation purposes and should be left unchanged.

Today, let’s look at changes made to Requirement 2 for PCI DSS 4.0.

Requirement 2 Changes

In Requirement 2, we will find our first PCI DSS new control for 4.0:

In 3.2.1, roles were not necessary to be defined in 2.x controls.  While role definition was imperative in some sections of PCI 3.2.1, it was not required in 2. However, given that builders of in-scope systems have several critical functions to perform in deployment of secure technologies, this only made sense to add to Req 2.

Control Clarification

In 2.2.5, notice how the content of the control changed with the “if” statement to help clarify what might or might not exist on any given system. With 3.2.1, most of us got fed up with having to answer a question that assumed the affirmative, whereas this language leaves it up to the assessor to identify whether or not the system actually has insecure X.  Take a look at how 2.1.1 changed into 2.3.1 and 2.3.1:

changes to


This splits up the mouthful of 2.1.1 that existed in 3.2.1 into more manageable chunks where entities can be assessed separately on two different control sets.

While there hasn’t been much going on in requirement 2 that changed for 4.0, wait until you get a load of the new controls in Requirement 3!

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.