PABP Compliance Does NOT Imply PCI DSS Compliance
December 30th, 2007 by Jeff Hall Posted in Service Provider, Third-Parties, Vendors, pa-dssIt has come to my attention that software vendors do not fully understand their responsibilities regarding Payment Application Best Practices (PABP) compliance and their customers’ PCI Data Security Standard (DSS) compliance. PABP compliance does not automatically imply PCI DSS compliance and visa versa. What follows is a recent real-life example of how a major vendor handled this situation and how it adversely impacted their customer.
One of my clients is implementing a new point-of-sale (POS) system in one of their operations so that this operation will be PCI DSS compliant. This POS vendor is not only providing the software solution but is also providing remote management and support of the solution.
The first problem my client ran into was their demand that the contract with the vendor contain language to ensure that the vendor’s services being provided were PCI DSS compliant. The vendor explained that their software was PABP compliant and that they were therefore PCI DSS compliant. We explained that the software was only part of the equation because the vendor would be remotely administering the system and that those services needed to be PCI DSS compliant. The vendor continued to argue that their PABP compliance was all that was needed but finally relented to the PCI DSS compliance provision.
We are now assessing the implementation of the vendor’s software for revising their PCI Report On Compliance (ROC). While the software is definitely PABP compliant, we have consistently had difficulty getting information out of the vendor regarding how to assess my client’s implementation of the solution. They have finally, and very reluctantly, admitted that cardholder data (CHD) is stored encrypted on the server at each location. In very tense discussions, they have also finally relented and released the process for managing the encryption keys to my client for their management. My client was relying on the fact that since the software was PABP compliant, they would not have to worry about additional controls. However, my client now has to rapidly make implementation changes to make sure that they meet the PCI DSS requirements for data center monitoring and controls because the new solution stores CHD locally on each server.
All through this process, the vendor has been arrogant and indignant. They have repeatedly stated that as they understood the process, PABP compliance was all they needed to be compliant with all PCI processes.
This has been meant to give software vendors a relevant example of why it is so important for them to be forthcoming with all information regarding their solutions with their customers. There is important information regarding the solution that the customer needs to know so that their implementation will be PCI DSS compliant. PABP compliance means that an application properly protects, manages and controls CHD. It does not mean that your customers will not have to implement their own management procedures and controls at their end to ensure their PCI DSS compliance.
If a vendor is providing management or other services to their customers that are covered by the PCI DSS, vendors need to understand that those services are not covered by any PABP compliance process and that these services need to comply with the PCI DSS.
And this situation will not change with the introduction of the PA-DSS.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
10 Responses to “PABP Compliance Does NOT Imply PCI DSS Compliance”
By wconway on Dec 30, 2007
Jeff,
Thanks for an outstanding post on an issue surrounded by a lot of confusion. The details of your client’s experience are a case study for everyone. What a shame it took all your professional knowledge and persistence to get to the truth. I only wonder if the vendor really learned anything…
By Michael Dahn on Dec 30, 2007
I agree, merchants should always ask for a copy of the “implementation documentation” or “implementation guide”, which is a requirement for PABP validation.
You can find more resources here.
By Jeff Hall on Jan 14, 2008
The problem is that the relevant PCI compliance information is NOT in the vendor’s user or implementation guides for the application. The reason given by the vendor was that since they are PABP compliant, there is no need.
That’s the problem. The vendors seem to think that because they go through the PABP process, their job is done and that PCI DSS compliance is assured and that’s just not how the process works.
By Garland L. McLaughlin on Feb 18, 2008
CentralPayment
Corporation
Agent Representative
Garland L. McLaughlin
Agent #235793
Direct Phone Line: 1-888-221-3676
Office: 617-533-8241
Voice Mail: 617-934-5534
consultingguy2000@yahoo.com
By INFO on May 23, 2008
First and foremost - keep in mind that someone is selling you something. They want to close the deal and move on to the next customer. By saying or implying that they are fully PCI compliant simply because they are PABP compliant may induce people into buying their service. A lot of service providers use this technique for numerous certifications such as SAS70, HIPPA, etc. It should be no surprise this is used for PCI as well.
This article highlights the fact there is no easy answer to PCI. Companies need to look closely at their service providers and their own systems before blindly believing they are compliant.
http://www.MBridge.com
By P. Boucher on Jul 21, 2008
I am a small merchant attempting to fill out the PCI DSS SAQ.
I have a POS that is on Visa’s List of Validated Payment Applications, and it is connected to the Internet, but is not connected to any other computers in my environment. If I otherwise qualify to use SAQ C (I retain only paper records, etc.), I’m not sure if I have to independently verify that my PABP validated payment application is not storing my customer’s PANS before filling out SAQ C.
I know that PABP validated payment applications do not store prohibited data (Track, CVV, etc.), but it may be storing PANs. If so, it is presumably storing the PANs securely (since it is on the List of Validated payment Applications).
So, do I have to use SAQ D if my PABP compiant POS can store PAN’s, or can I use SAQ C?
Thanks for your help!
By Phil Cox on Jul 21, 2008
P. Boucher,
From your description, I BELIEVE that you fall into the SAQ C (i.e., type 4) category. This is based on the my interpretation of the “do not store cardholder data on any computer system”. I read that to mean “anything other than the POS device”. Basically what you should have is a POS device with the Internet connection directly to it, and NO other systems on that network.
Just my $.02
Phil
By wconway on Jul 21, 2008
@P Boucher, As I understand it, you are running a PABP app on your system, and you are connected to the Internet. First, I’d check your configuration to see if you have installed the app correctly (see earlier posts on this thread), then confirm it is NOT storing PANs. If you are storing PANs electronically, you are looking at SAQ D; if you are not storing PANs, you should be clear for SAQ C. Bottom line: check the configuration and what you are/are not storing. That the app is on the PABP list is good but not a free pass.
I guess this gets us up to $.04…
By P. Boucher on Jul 31, 2008
Just in case anyone was wondering, regarding the PABP-validated POS that may store PANs, you do have to find out, and either configure the POS to not store PANs, or fill out SAQ D.
I got this official answer from the PCI SSC: “The PCI Security Standards Council highly recommends that you contact your POS software vendor to determine whether your software stores PANs within or anywhere in the POS system. If the answer is yes, then such storage of PANs disqualifies you from completing SAQ form C.”