Evan Schuman's StorefrontBacktalk

The good part is you will be able to find (and remove?) cardholder data that can lurk in expected and unexpected places. The bad part is finding it all is likely to take some effort.

How do you find all the cardholder data? You can start with the places you know about now, including the back-office departments that do accounting, chargeback processing and dispute resolution.

The situation the revised guidance is designed to address, though, is not all the “usual suspects.” It’s the unknown unknowns; that is, the places where cardholder data may have leaked—intentionally or not.

Things get complicated when a processor uses insecure means to return transaction data to the merchant. Merchants report that in some cases their processors use E-mail or FTP to transmit cardholder data to them. In addition to bringing any number of the retailer’s systems into PCI scope, the operational result is a range of databases, flat files, servers, flash drives, laptops, spreadsheets and myriad other places that are used to “store, process or transmit” cardholder data. Confirming your PCI scope, therefore, is likely to take some effort under Version 2.0.

For example, how is an IT executive to know how many files were created or whether all have been securely identified and purged? Furthermore, how is your QSA to confirm that?

The guidance says: “The entity retains documentation that shows how PCI DSS scope was confirmed and the results, for assessor review and/or for reference during the next annual PCI SCC scope confirmation activity.” Unfortunately, there is no example of what the PCI Council means by “documentation.” Lacking something concrete, it will be hard for a QSA to meet this requirement.

During training, QSAs are instructed that it is their responsibility to determine the scope of the assessment. Currently, we rely on cardholder dataflow diagrams, network diagrams and interviews to make this determination. We often use sensitive number finders and other automated data discovery tools partly to confirm the scope but also to reduce the risk of a data compromise.

Under Version 2.0 these automated tools seem, at least to me, to be all but required. Without one of these tools, it is difficult to see how a merchant or processor can either be sure all their cardholder data has been found or document their findings.

The upside is that it won’t necessarily cost merchants any money for a good tool. A number of decent open-source tools are available. The investment will be in tuning the tool, applying it thoughtfully and carefully, and documenting the findings for the assessment.

For 2011, all merchants and processors have the option of using either PCI Version 1.2 or PCI Version 2.0. Given the quirks of the calendar, that means those who validate in the fourth quarter of this year can continue to use 1.2 again next year. In other words, they won’t have to validate compliance with PCI 2.0 until the end of 2012. I recommend that you decide carefully and with some deliberation.

Which version will you choose? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.