Flexibility is how the Council and their spokespeople tout PCI DSS v4 and the Customized Approach. The Customized Approach will allow your organization to make the PCI DSS your own and similar comments are made.
While those are all very true statements, the Council is wrapping the Customized Approach with some caveats that are not necessarily being broadcast to the general public.
The first caveat that comes through loud and strong during the PCI DSS v4 Transition Training that QSAs are required to take in order to use v4. That caveat is that the Customized Approach is really only for organizations that have a mature controls environment. The Council’s rationale for this is that the Customized Approach is not for organizations that have anything but strong and mature control environments because the Customized Approach requires mature and functioning controls that can be tested to show they are always functioning. This point was repeatedly pointed out whenever the Customized Approach was discussed. When you look at the documentation being required to use the Customized Approach it is very clear that only organizations that have strong control environments are going to be able to provide the documentation and evidence necessary to meet the Customized Approach documentation and evidence standards.
The next caveat is that much of the documentation and evidence that an organization needs to provide for the Customized Approach MUST BE developed by the organization, not their QSA. This goes back and reinforces the idea that only organizations with strong and mature control environments are going to be able to use the Customized Approach because such organizations are going to be the only ones that have their act together to be able to produce the necessary documentation and evidence.
If your organization does need assistance developing a Customized Approach, do not expect your QSA to be able to help you because they cannot and still maintain their assessor independence. So, organizations will have to get assistance from a different QSA if they need such help. While that QSA can be from the same QSAC, I am guessing that a lot of QSACs will want to have a different QSAC provide such assistance so that they ensure they are independent.
The final caveat is that the Customized Approach is not a new compensating control worksheet (CCW) exercise. Not even close and far from it! The Customized Approach is going to require organizations to not only provide documentation of the approach and how it works, but that it manages the risk at or below the PCI DSS approach, and evidence that the approach works and works consistently by conducting their own testing (hopefully independent, i.e., internal audit) and providing complete documentation of that testing. From all of that your QSA reviews the documentation, develops their own testing procedures and validates that the Customized Approach is functioning as designed. Better yet, the Council has been very, very clear to QSAs that this is not something an organization can just toss together when they figure out, they have a PCI compliance problem. This needs to have been implemented and thought out long before the organization got to conducting their PCI assessment.
All of which leads to why this will be the next battleground.
At any point in the PCI assessment, the QSA can reject the proposed Customized Approach for a number of reasons. Some of which could be:
- Inability of the organization to provide evidence that they have a mature and strong controls environment,
- A lack of complete documentation for the Customized Approach,
- Failure of the proposed controls to meet the PCI DSS requirements addressed by the Customized Approach,
- Lack of adequate organizational testing (i.e., testing not performed over a period of time), and
- Failure of the QSA to prove that the Customized Approach works through their own testing.
Keep in mind that QSACs are going to be on the hook for approving these Customized Approaches. If they blow up and result in a breach, this will put not only the organization on a legal hook, but also the QSAC that approved the Customized Approach. In these days of risk mitigation and management, most QSACs are going to be very, very careful as to what Customized Approaches get approved. I would not be surprised if QSAC senior management and their legal counsels will be involved in that approval process. All of which will most likely stretch out getting a finalized ROC out the door.
As someone that runs a PCI practice, while implied by the Council in their guidance on this subject, I would require documentation that an organization’s controls environment is mature and strong. First thing that fails that test is if the organization has had any control failures since their last PCI assessment. In my very humble opinion, if you have any reason to need a CCW, you do not get to use the Customized Approach. Nothing says your controls are not mature and strong is that you cannot execute required PCI controls 99% of the time. All of this starts to indicate to me that business as usual (BAU) and that an organization monitors those BAUs is going to become a requirement of QSAs to sign off on Customized Approaches. If an organization has not integrated PCI controls into their business processes and is not monitoring their compliance on a near real time basis, then do not expect your QSA to sign off on using a Customized Approach. Yes, control environments are not perfect, and mistakes/errors happen. But if you cannot prove that you knew almost immediately that the control failed and that you took action to correct the situation when you found the failure, then I really have difficulty judging your environment as mature and strong.
Who does the organization appeal to if they do not like the QSA’s assessment of their Customized Approach? While not clearly articulated by the Council, I am assuming it will be the acquiring banks or even the Card Brands.
The lesson here is, be very careful what you wish for. While you now have a way to customize the PCI DSS, it is not a panacea nor is it going to be available to everyone. Time will tell how this experiment works out.
I disagree with your opinion that an entity that uses a CCW is not eligible for using Customized Approach. You’re basically punishing the entity because they are subject to a legal, financial or technical limitation outside of their control that warrants a CCW. It’s unfair. The use of a CCW might be legitimate in that entity’s environment and they may not be using the CCW as a means to avoid using the defined control.
It is NOT that you cannot use a CCW and the Customized Approach in the same ROC. It is that you cannot have a CCW in a Customized Approach. Those are the Council’s rules, not mine. So do NOT shoot me! I’m just the messenger.
Okay. Went back and reread my post and get your comment now. I stick by may statement. If the Council says only mature organizations can use it, the those with CCWs need to be seriously assessed as to whether or not a CCW indicates maturity.
While I get your point, I think we must be VERY careful with organizations that are using CCWs to meet requirements but then are also relying on the Customized Approach. I am guessing one of the quickest ways for QSACs to end up in remediation will be to allow the use of CCWs and Customized Approach in the same ROC without some really, really good justification.
I agree wholeheartedly with this entire post! One of the few controls I see being able to utilize the customized approach is 8.3.9, the dreaded 90-day password change, that I really thought might get an upgrade with all the new password guidance. I would think that with all the published risk reviews and guidance of password length, complexities, and change frequency, and organization would be able to put together a solid argument/risk assessment for NIST-type password structures and have a QSAC approve it. I’d prefer MFA throughout the organization instead, but there still seems to be a ton of push back against that…
But the 90 day rule goes away as of April 2025, so why go through all of the effort?
As to the NIST approach, it has flaws that make it risky. The biggest of which is that NIST only requires the checking of bad passwords at the time the password is changed. So, a user could change it, it be compromised within days and you are unaware of the compromised PW until you’re dealing with a breach.