Which version of PCI should you use to validate your compliance? Although Version 2.0 was recently released, it is not effective until Jan. 1, 2011, after which time it will exist in parallel with the current version—1.2. That means for all of 2011 retailers will have the option of using either version to validate their compliance.
On the surface, the differences between the two versions do not appear significant. So why would you not want to validate using the latest and greatest? Looking deeper, however, shows that one change in Version 2.0 could have an impact on your decision. That change is the new guidance on scoping.
For retailers and processors with a fourth quarter revalidation date, there is not much of a choice: You will use Version 1.2. Although a retailer could decide to validate using 2.0 now, I'd suggest talking to your acquirer before taking that step. Waiting until January, however, means you will miss your renewal anniversary and go out of compliance, if only for a few weeks.
You don't want to make a decision in haste because QSAs, like everyone else, are still digesting the new version. They will need to update reporting processes (including QA) and templates to reflect the changes. As such, a decision to use Version 2.0 now means that you would not have (and could not submit) your Report on Compliance (ROC) until sometime in January, at the earliest, which is well after your 2010 renewal date. Another tip: Check to make sure you don't end up with a fine or other penalty because of this decision.
For these "fourth quarter" retailers I suggest you at least consider using 1.2 now and then starting the revalidation process using 2.0 in the first or second quarter of the new year. That approach means you will be current with the latest version a bit ahead of the game while giving yourself more time to implement the new version.
Validating early (nobody said you could not validate earlier than 12 months from your anniversary date) may also get you off the fourth quarter treadmill.
Level 2 retailers who are doing their first assessment should start debating their decision soon. They could start with Version 1.2.1 and migrate to 2.0 in a year, or they could jump right in with Version 2.0. If these retailers choose the latter course, they should not wait too long to start the validation process. A first time assessment combined with a new version of the DSS could take longer than expected.
Why would retailers, regardless of merchant level, need extra time? At least one reason is the new emphasis on accurately determining your PCI scope under 2.0.
Version 2.0 requires you to identify all locations and flows of cardholder data and to ensure they are included in your PCI DSS scope. (I guess I could point out that you should have been doing this all along. In any event, it is now required by PCI DSS.) Every merchant and processor needs to do this identification prior to their annual assessment, but at least annually.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 [email protected].