After reflecting on the PCI Community Meeting last week, it seems that there is a groundswell building. We’re getting ready to release our updated PCI DSS book on October 24 (pre-order here), and in it (as well as in talks I’ve given since the release) we speculate that the changes in 3.0 are mostly minor and give the merchant more flexibility. While I still stand by this, it seems that the perception in the community does not align with this. I had many conversations last week from disillusioned merchants who are struggling to come up with solid plans for updating their programs. We got detailed in the book on how to address some of these issues, including new chapters on Cloud and Mobile. I’m excited for you all to see it!

Fire, by Cindy Andrie

Fire, by Cindy Andrie

I got to thinking more about the shift to 3.0 and had to remind myself that PCI DSS is not something that is forced upon every merchant. In fact, it is something a merchant chooses to be burdened with as they architect their business rules and processes. Some companies have found ways to completely outsource their payments (albeit, mostly eComm merchants), and others have figured out how to reduce the scope to only their terminals using some form of P2PE and Tokenization. I’m saying this a little bit tongue in cheek as I know that some business rules seem to be non-negotiable—but you would be surprised how much wiggle room you can find.

Most of the merchants I talk to are doing some kind of terminal update to ensure they can take advantage of the liability shift on chargebacks thanks to EMV. Now that they are deploying new terminals with the ability to accept higher-security contact and contactless payment instruments, they have an opportunity to deploy more scope-reducing goodness. As an example, let’s say that an acquirer sells a merchant P2PE terminals that handle everything in the transaction stream securely, return tokens, and effectively allow the merchant to do everything they could before removing the data from the stream. By doing this, the acquirer could choose to exempt the merchant from submitting an AoC/ROC. The merchant buys a safer solution, and the acquirer reduces  risk in their business. It’s a win-win.

Merchants become less attractive hacking targets as the attack surface shrinks along with projected payoffs. POS malware becomes irrelevant—meaning that even if it is present, it won’t be effective at stealing this kind of data (but it could other kinds, so be careful). If I were a merchant, I would think this is an elegant enough solution to solve both issues: the pressure from your financial institution to remain compliant with PCI DSS, and the pressure from your board to not be the next Home Depot, Target, SuperValu, or Neiman Marcus.

Keep in mind, there will always be some kind of reporting responsibility or review of the terminals, but I think most merchants would agree that if they only had to have their terminals inspected once per year, they would be ECSTATIC. Additionally, if your business does not use terminals in that sense (because, perhaps, they use an integrated POS setup and do not accept Debit today), the engineering requirements to adjust the setup are more challenging than those with the separate PIN entry terminal.

Ironically, the biggest threat to PCI DSS may be the from merchants doing what the Council seemingly wants them to do in the first place—protect the security of payment information. So the next time you get upset at your QSA/ISA or you think about some huge assessment finding that is seemingly impossible to address, consider how you handle the data in the first place. There may be an easier long-term solution!

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts:


0