This post is a result of many, many conversations with software companies regarding the PCI Payment Application Data Security Standard (PA-DSS).  What’s really interesting about all those conversations is that they tend to fit into two categories – the first involves software companies that know that they need to go through PA-DSS validation and are looking for real guidance, the other typically involves organizations that are looking for someone to tell them that the standard doesn’t apply to them for some reason.

The questions below are the most common ones that we receive from that second group.  Hopefully, the answers will help those non-POS companies that are wondering whether PA-DSS applies to them.

1.    We are a healthcare (or some other type of) software company, not a POS vendor. We’re not even implemented in a retail setting. PA-DSS doesn’t really apply to us, right?

No, this is not correct. If your situation matches the criteria for the standard (just below), then PA-DSS applies. That doesn’t mean that you have to go through the validation process, it just means that you have to go through the validation process if you want to keep selling your software to companies that accept Visa transactions. Keep reading and I’ll explain.

General Criteria:

• Is the application being sold, distributed, or licensed to a third party?
• Does the application store, process, or transmit cardholder data (credit card information)?  Note – ‘process’ doesn’t necessarily mean financial transaction. For example, taking and hashing a card number would be considered ‘processing’ cardholder data.

2.    Our company is really a Service Provider – 80% of our business is hosted, and we only sell our software to a subset of our clients for implementation at their location. We don’t have to bother going through this, do we?

According to the PCI SSC, if your software matches the criteria (see #1), then you need to go through the process. In fact, if you haven’t already, you most likely need to go through the full PCI DSS process as a Service Provider as well.

There are exemptions for one-off, customized solutions, but if you are selling the same base application to two or more clients (and, again, you meet the criteria) you need to address PA-DSS.

3.    Isn’t there some way of doing this more cheaply?

Not really. The process of validating an application under PA-DSS is actually quite involved. It includes documentation review, lab testing, interviewing, process and controls review, documentation, documentation, documentation, and some more documentation.

This is not PABP (if you are familiar with the original Visa software security standard). We have seen significant issues with companies that thought they could treat PA-DSS with the same level of attention and effort as they gave to the older standard.

4.    Are the PCI Council and the card brands trying to put my company out of business?

No – I honestly don’t think so. They are just looking to make sure that applications capable of being implemented in a PCI-compliant manner are what are being sold in the marketplace to handle credit card information and transactions. Their interest is primarily in keeping their card data secure and in making sure that the merchant is choosing applications that will support that goal.

5.    Are they really going to enforce this?

Yes, I think they are. Visa has given every indication that they fully intend to enforce PA-DSS validation and, given their willingness to do so on the broader PCI DSS, I would be willing to bet that they won’t back down.

6.    Do my customers need to have our product validated for them to be compliant with the PCI DSS?

No, your customers are not required by the PCI DSS to utilize PA-DSS validated applications today.

In practice (a point stressed at the recent PCI Community Meeting), Visa will be requiring merchants and service providers to use PA-DSS validated applications (unless the applications are developed internally). That Visa announcement makes PA-DSS a practical requirement (even if not technically a PCI requirement) for companies that want to continue accepting Visa as a form of payment.

7.    How long does the PA-DSS process take?

It actually depends heavily on the software vendor. If they are highly motivated, committed, and well prepared (and timing with the PA-QSA matches up), the process can be fairly quick. This isn’t necessarily typical, however.

At NetSPI we work with our PA-DSS clients in a very interactive manner. We want to identify gaps and allow you to address them prior to testing and review being complete. Closing identified gaps requires the software vendor to take real action; without that action and commitment, the process can really drag. There is little the PA-QSA can do to move the process along without that commitment.

8.    Why are there fewer PA-QSAs vs. PCI-QSAs?

In my opinion, it is due to a few things:

• Application expertise and app security expertise are NECESSARY for PA-DSS – it’s not quite so easy to throw outside resources at PA-DSS and try to survive on a rigid audit process; you actually have to know what you are talking about.
• The rigorous QA program that the PCI SSC has implemented on the PCI DSS side was actually ‘turned on’ from day one on the PA-DSS side and required a level of documentation and commitment on the part of the PA-QSA that many in the PCI community simply didn’t want to (or couldn’t) handle.
• In PA-DSS, the relationship between the firm validating the software and the vendor going through validation is extremely important. This isn’t just about an audit and we’re done. If a PA-QSA firm is doing its job correctly, the QSAs are having discussions with their client about future updates, version control issues, architecture issues, how to operationalize future PA-DSS validation efforts, etc. That’s a consulting/partnership relationship, and many in the PCI community aren’t focused on that type of relationship.

9.    Implementing our solution in our PA-DSS partner’s lab is a real pain, do we have to?

Not necessarily – the council prefers that your application be tested in a PA-QSA’s lab, but it’s not required. If it is impractical for the application to be installed in the testing lab (and your PA-QSA feels comfortable defending that opinion), you can bring the PA-QSA to your location.

10.    We think this whole thing is ridiculous. What if we refuse?

You certainly have the right, but the PCI SSC has been very straightforward: the PCI PA-DSS list is to be the de facto standard on PCI–acceptable applications. If your application is not on the list, you are taking a risk, the potential impact of which would most likely go far beyond the expense of going through the process.

11.    We’ve gone through CCHIT (or some other standard that includes security). Aren’t we covered?

No. PA-DSS is not a suggestion from Visa– it’s a requirement. It is also the only standard that is entirely focused on cardholder data (the data that card brands really care about). If your solution has been successfully audited or validated under another security-focused standard, you may have a head start on getting your solution to a PA-DSS-compliant state. That effort may help prepare you for PA-DSS validation.