When I was in training for my PCI ISA certification in 2012, I heard the instructor say, “and remember, the DSS requirements loop.” As someone brand new to the world of PCI Compliance, I had no idea what he was talking about.
The more experienced I became, the more I understood just how interconnected and interdependent the PCI DSS requirements are. As I grew in my role as a PCI ISA, I was able to avoid the perils and pitfalls that come with the complexity of hundreds of PCI requirements, sub requirements, guidance documentation and other cross-reference material.
For example, did you know that requirement 11.2.3.b loops back to requirement 6.1? In fact, the QSA must validate that all rescans were performed until “either passing results were obtained or all “high-risk” vulnerabilities as defined in PCI DSS requirements 6.1 were resolved.” Not all requirements that are interdependent have a direct call out like this.
If you have high-risk vulnerabilities that haven’t been resolved in your environment, your QSA could very well mark more than one requirement as not in place.
There’s often a cascading effect on requirement failures when one requirement is not in place. Given that a PCI Report on Compliance is an all or nothing endeavor, the cascading effect of requirement failures is definitely a pitfall you want to avoid.
Some pitfalls exist in places were you might not normally think to even check. For example, in 2018, the PCI Security Council added PCI DSS requirement 6.2 to the SAQ-A, which brought servers that redirect to hosted payment pages into scope for patching. No doubt, a wise update; however the change was not widely broadcasted nor made apparent to merchants who redirect their internal payment systems to an internal billing page on an iFrame. Whether you have one or thirty internal payment systems redirecting to an internal iFrame, those servers are now in scope for requirement 6.2.
The peril that most ISA’s or PCI program managers will face is having to tell the finance department, application developers, system admins, etc., that their systems are now in scope and they must provide evidence of patching. Let’s hope they’re doing it anyway.
Scope is another pitfall that many merchants may stumble into. We’re going to chat about scope in an upcoming blog post. Stay tuned!
At Payment Card Assessments, we know how to cross check all the relevant requirements, guidance documentation, FAQs, etc., to ensure PCI DSS Compliance. We can help your organization avoid the perils and the pitfalls and get your program off and running in the compliant direction. Request a call back today!
