This article was written by Ryan Bigelow, Director FoxPointe Solutions.
It’s hard to believe that PCI DSS v4 (now 4.0.1) has already been out for three years. The standard was officially released to the public on March 31, 2022. With it came a transition period to allow organizations time to prepare for the new requirements. Over the past three years, FoxPointe Solutions has performed many PCI DSS v4 assessments. We wanted to share some of the insights and lessons we’ve learned as assessors that may help organizations preparing for an assessment or the broader information security community.
Here are some of the top things we’ve learned over the past three years:
1. Early Gap Assessments Made a Big Difference
Organizations that took the time to perform gap assessments during the transition period were far more prepared for their first 4.0 assessments. On the other hand, organizations that skipped this step often found (or are finding) themselves rushing to remediate or create documentation during the assessment itself.
2. Targeted Risk Analysis Isn’t Your Annual Risk Assessment
The “Targeted Risk Analysis” (TRA) is a new concept introduced in PCI DSS v4.0, but it is not the same thing as an Annual Risk Assessment. While they are related, providing your enterprise risk assessment or a risk register does not fulfill the TRA requirements. The TRA is used to define the frequency of certain activities using a risk-based approach, where the standard allows for flexibility.
3. MFA May Be Required More Than Once
Multi-Factor Authentication (MFA) may need to be applied twice, depending on how your environment is structured. Organizations often must implement MFA for remote network access, and again for access to the Cardholder Data Environment (CDE). Each environment is different, so it’s important to work with your QSA to determine what PCI Requirement 8.4.2 means in your specific case.
4. Interactive Logins Take More Planning Than Expected
The new interactive login requirements have caught many organizations off guard, from small businesses to large enterprises. We’ve had a number of conversations with clients about how to identify interactive accounts and how to address PCI DSS Requirements 8.6.1, 8.6.2, and 8.6.3. These conversations often involve several different teams, so plan ahead and don’t assume this is a simple checkbox.
5. Custom Software is More Common Than You Think
The term “bespoke and custom software” has caused confusion. Requirement 6.3.2 requires an inventory of bespoke and custom software, but many organizations mistakenly believe this does not apply to them. Often, it turns out they do have in-scope custom web applications that meet the definition (SAQ A implementations are excluded.) Don’t assume this requirement is not applicable, talk to your QSA and confirm.
6. Script and Tamper Controls for E-Commerce Are Achievable
New e-commerce requirements related to payment page scripts (6.4.3) and unauthorized changes (11.6.1) were initially seen as too difficult for many organizations to implement. As a result, they were removed from the SAQ A and replaced with new eligibility criteria with similar intent. That said, our experience shows these controls are achievable, and there are vendor solutions available that can help. While we remain vendor-neutral, we can provide a few suggestions if needed.
7. SAQ D for Service Providers Requires Much More Effort
The SAQ D for Service Providers (SAQ D-SP) has been completely overhauled. It now requires detailed responses for every control, not just checkboxes. Organizations must provide testing descriptions, diagrams, in-scope systems, scan dates, and more. Completing the SAQ D-SP now takes significantly more time and effort than before.
8. Phishing Controls Don’t Mandate DMARC
Requirement 5.4.1 introduced a technical control to protect personnel from phishing attacks. Some misinformation on social media led some to believe that DMARC (Domain-based Message Authentication, Reporting & Conformance) was mandatory. The PCI SSC had to step in and clarify during assessor webinars. While DMARC is one acceptable method, it is not the only option. There are multiple ways to meet this requirement.
9. PCI Assessments Now Take More Time and Resources
Overall, our experience shows that the level of effort to complete PCI DSS v4.x assessments has increased significantly. This is true for both the QSA and the organization being assessed. With more than 54 new requirements and detailed reporting templates, organizations need to take PCI DSS seriously and allocate the right amount of time, staff, and budget to ensure a successful engagement.
10. Reporting Templates Have Grown Considerably
PCI DSS report templates have more than doubled in size. A blank ROC in version 3.2.1 was 193 pages, while version 4.0 increased to 492 pages. Assessors have reported issues like system crashes and instability when working with these documents. The PCI SSC has responded by trimming down the templates slightly in version 4.0.1, but from our experience, some issues persist. While organizations may not see these backend challenges, it’s a reminder that the standard and its documentation are still evolving.
11. Some Service Providers Are Trying to Avoid Scope
PCI compliance has grown more complex, and unfortunately, some service providers are now trying to dodge their responsibilities or claim they are out of scope. Merchants need to hold their service providers accountable. It’s always a best practice to work with providers that can provide an up-to-date Attestation of Compliance (AOC).
12. PCI SSC Is Listening to Community Feedback
Over the last three years, it’s been encouraging to see the PCI SSC respond to community feedback. For example, “In Place with Remediation” has been removed from the ROC, the problematic “Items Noted For Improvement” (INFI) worksheet was quickly retired, and as mentioned earlier, requirements 6.4.3 and 11.6.1 were removed from SAQ A. The reporting templates also continue to receive updates to address feedback and reduce complexity.
13. “Shared Hosting Provider” Is Now “Multi-Tenant Service Provider”
The term “Shared Hosting Provider” has been replaced with “Multi-Tenant Service Provider,” and the definition is now broader. It includes providers hosting multiple entities on shared infrastructure, such as e-commerce platforms, cloud applications, and payment services. This means that providers who were not previously considered in scope may now fall under this definition and be subject to Appendix A1 and other specific requirements.
14. Customized Approach Is Flexible but Often Unused
The “Customized Approach” introduced in PCI DSS v4.0 gives organizations more flexibility to meet the intent of requirements through alternative controls. However, this option comes with a heavy documentation burden, including a custom testing plan. In most cases, using the standard prescriptive control is more straightforward. Adoption of the customized approach has been low so far, but it may become more common as new technologies continue to outpace traditional security frameworks.
15. Future-Dated Requirements Are Now in Effect
As of March 31, 2025, all future-dated requirements are now officially in effect and must be assessed. We fully expect the PCI SSC to release version 4.0.2 in the near future to remove references to “best practices until March 31, 2025” and to incorporate other expected updates.
We hope these insights are helpful as your organization works through PCI DSS v4. If you’d like to learn how FoxPointe Solutions can support your PCI compliance efforts, contact me at rbigelow@foxpointesolutions.com or visit www.foxpointesolutions.com.
FoxPointe Solutions, a division of The Bonadio Group, is a Qualified Security Assessor (QSA) company registered with the PCI Security Standards Council under Bonadio & Co. LLP.