PABP validation for applications that do not have "cardholder data"?

[markiyan]

Not sure if everyone has had a chance to read the white paper Chris Mark wrote titled "Cardholder Data Whitepaper"... it's a great read and i couldn't agree with it more.

This brings up an interesting point. If a merchant is using a secure card reader that encrypts the data right at the swipe and the POS system never has access to the unencrypted data or the key to decrypt the data... does that POS system still need to undergo a PABP validation?

I don't believe that the software needs to undergo validation since it never has access to cardholder data and has no way of decrypting the data, even if it is compromised. Does anyone think the software needs to be validated and if so, why?

[jbhall56]

This brings up an interesting point. If a merchant is using a secure card reader that encrypts the data right at the swipe and the POS system never has access to the unencrypted data or the key to decrypt the data... does that POS system still need to undergo a PABP validation?

Yes, the POS is out of scope as long as the QSA is satisfied that what you represent is actually the case. A QSA cannot just blindly accept facts without some examination. That said, a QSA should not spend a ton of time making this determination unless it's difficult to make such a determination due to lack of documentation or inability to provide the necessary tools.

I don't believe that the software needs to undergo validation since it never has access to cardholder data and has no way of decrypting the data, even if it is compromised. Does anyone think the software needs to be validated and if so, why?

If the facts hold true and the POS solution never comes in contact with cardholder data (CHD), then you are correct.

[mdahn]

In case anyone would like to read the white paper it's posted here (http://www.aegenis.com/whitepaper/Cardholder%20Data%20Whitepaper.pdf).