The PCI Security Standards Council released a statement this morning outlining some of the highlights from the feedback period we just finished this year as part of the PCI DSS lifecycle. If you are going to be at the community meeting next week (or later in October for EU), I strongly suggest you attend the session on the feedback and potential proposed changes to the standard (if they have the ability to turn that around this quickly). Here are a couple of notes from my analysis (note some of the wording is similar to the press release, go read it):

  • Scoping is still an issue. I think we all agree that at some point the framers of PCI DSS will have to take another crack at refining the scope definitions around PCI DSS, especially in light of this work now released to the public.
  • ASVs (or at least the applications of 11.2) need work. Requests for specific tools, ASVs to perform internal scanning, and more definition for the term “significant change.” Obviously, nobody should expect the Council to require a particular brand of tool, but it may require certain features. For example, something I would love to see is a requirement for quarterly authenticated web-application scans.
  • SAQ overhaul. Yet another one that is probably a long time coming. The SAQ process is still a bit cumbersome and doesn’t readily meet every merchant’s requirements. I have suggestions here that I will put to the Board of Advisors, time permitting.
  • PCI Requirement 8.5 overhaul. It’s the one requirement that features the most sub requirements. I’m not sure I’m in favor of changing this much for a number of reasons, but I would argue that a better use of this requirement would be to strike it all together, require users to have strong passwords (as defined by NIST or someone else), and use behavioral analytics to determine when valid credentials are used in an invalid way.

The other changes I am not listing here simply because I don’t agree with what is in the release. I think 3.4 is fine as it is, but may just need some minor definition updates. I also think that the service provider definition can’t be made any easier except to just say, “An entity that can impact the security of payment card data.”

I will be at the community meeting next week from Wednesday evening through Thursday. If you are there, please come find me!

This post originally appeared on