Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

IT and business executives reading PCI DSS Version 2.0—slated to be released Thursday (Oct. 28)—will notice that it focuses on clarifications and additional guidance instead of providing a lot of new requirements. There are, however, two “Evolving Requirements” that, together with several clarifications, may impact how many retailers approach PCI compliance. Rather than taking the entire document apart piece by piece, we’ll highlight five items that caught this QSA’s attention, along with the implications of each for retail IT executives.

The short version: You can expect to spend more time at the beginning of your assessment, and some of the approaches and technologies you may recently have put in place may no longer make the grade.

Last April, StorefrontBacktalk took a look at what to expect from PCI DSS Version 2.0. The new version includes most of the items identified in that column&38212;including the minor prediction that the new version would be called 2.0.

The first thing readers will notice when they open PCI Version 2.0 is an expanded section defining PCI scope. Version 2 requires merchants and processors to identify explicitly all the locations and flows of cardholder data annually before they begin their assessment. The specific instructions are to make sure that no data has leaked outside your defined cardholder data environment and, if you find any, that you either eliminate the data or include it in your assessment.

The PCI Council stopped short of requiring merchants to use an automated data discovery tool to find all their cardholder data, even though security-conscious retailers and processors use such tools already. From the Council’s perspective, not mandating a specific technology makes sense, I guess, but the group might have mandated the procedure without naming a specific tool. From a risk perspective, it is difficult to see how a merchant can be certain that cardholder data hasn’t leaked into other systems or employee laptops by just asking users whether they store cardholder data or not. As a point of interest, the Council is instructing QSAs to report how the PCI scope was validated in the Report on Compliance (ROC).

In my perfect world, I would like to see the PCI Council mandate the use of automated discovery tools. I am convinced that such a move would eliminate at least some data compromises by removing hidden or unknown stores of cardholder data. But I will take this increased emphasis on thoughtful scoping before the assessment as validation of what I previously referred to as “PCI Requirement 0.”

Although there are no completely new requirements, two closely related “Evolving Requirements” will have an impact on retailers and processors who develop payment applications. Interestingly, each is considered a “best practice” until June 30, 2012, after which both will be required. Where Requirement 6.2 used to say, “Establish a process to identify newly discovered security vulnerabilities,” the PCI Council has appended “and assign a risk ranking to newly discovered security vulnerabilities.”