To be clear, P2PE is not a silver bullet that makes PCI go away. It can, however, shrink a retailer's PCI scope. If retailers read nothing else, they need to look at Appendix A (page 81). There are a couple of new attestations, but these are not much more than elaborate versions of the Confirmation of Compliance Status boxes already in the Self-Assessment Questionnaire (SAQ).
The big news is where the Council says in the report that "it is expected that PCI DSS controls that will be applicable to a merchant's validation will include (but will not be limited to): Protection of media and devices; Maintaining information security policies and training for personnel; Processes for management of third-party providers (including P2PE provider); Incident response and escalation procedures."
(Related story: The PCI SAQ Problem: Versions Are Much Too Incomplete)
That means a retailer implementing approved P2PE might reduce its PCI compliance to just requirements 9 and 12 (and maybe 11.1). The Council's words "will include (but not be limited to)" are important. Retailers still need to validate PCI compliance, and, as with anything dealing with PCI and payments, retailers need to consider their own unique environment. Nevertheless, the promise of reduced scope seems significant for a POS environment.
Retailers will need to individually assess any scope reduction that might apply to their call centers, Web transactions or payment applications that require a primary account number (PAN).
We have, effectively, a new PCI standard with the accompanying infrastructure. I am still trying to understand why the Council could address tokenization in 39 pages while the full P2PE description requires 96 pages—roughly 2.5 times as long—of detailed hardware and software specifications, an independent P2PE validation process and two new flavors of specialized QSAs.
The Council breaks the P2PE validation into six domains. Each domain is, in effect, a P2PE requirement with further sub-requirements vendors need to meet. The Council seems to have introduced a P2P DSS (or PCI P2P) standard without calling it that, modeling it on PCI PTS and PA-DSS.In another parallel with PA-DSS, P2PE has two new categories of specialized QSAs: P2PE QSAs, companies and individuals who evaluate point-to-point encryption solutions; and P2PE PA-QSAs, companies and individuals who evaluate applications on PCI-approved Point of Interaction (POI) devices for point-to-point encryption solutions. Not all QSA companies will be P2PE QSAs or P2PE PA-QSAs. (I may have just set a record for the most acronyms in a single paragraph.)
This will not happen quickly. As highlighted previously, although the Council announced the validation requirements, we will not see the actual testing procedures until the end of the year. We also only have the validation requirements for using secure hardware devices for encryption and decryption (so called "hardware/hardware" approaches). Requirements for packages using software decryption within hardware ("hardware/software") should come out by the end of the year, too. It also will take time for vendors to get their hardware devices through the testing process. Lastly, QSA training will not be available until the spring of 2012, about six months or so from now.
Retailers must coordinate their P2PE decisions with their acquirers. Other than the four pages of that appendix, this document is aimed at the vendor community. There is a section on Roles and Responsibilities, though, and it identifies how merchants can reduce their PCI scope using P2PE. The first step is some good advice: "Coordinating with the acquirer (merchant bank) to determine which payment device (as part of a validated P2PE solution) the merchant should implement."
Following the Council's advice is smart. The PCI Council site will list validated hardware and software. You do not want to spend money and time on a vendor package that does not meet the validation requirements or that causes your acquirer to challenge your reduced PCI scope.
If you have a P2PE system in place, monitor your vendor's validation progress. I raised this issue for early adopters before, and the advice stands.