For those software vendors out there that are digging into PA-DSS and what it means for their organization, please read on.  This is not an in-depth discussion of PA-DSS, just a couple of things that have been popping up repeatedly for me in conversations with your peers - things that sometimes need clarification or that should be mentioned. 

Stuff You Probably Should Know About PA-DSS

1. It’s not PABP - this may sound obvious, but I’m going to repeat it - PA-DSS is not PABP.  Accept this fact - if your assessment partner hasn’t accepted this yet, find a new assessor.  For a more detailed documentation of the differences, there is a PABP vs. PA-DSS document on the Council’s website (although the differences listed don’t necessarily translate easily into an understanding of what the changes mean for the assessment process).  If you take a look at that document, you’ll also want to look at the changes from PA-DSS 1.1 to PA-DSS 1.2 - here’s the link.
2. It’s not cheap - the level and amount of work involved with a PA-DSS assessment is significant.  Even PA-QSAs that have long-term expertise with PCI, software development, and software security have to put a lot of time into this process.  The documentation review is in-depth, the lab testing is detailed, and the reporting is extremely ‘robust’.
3. Yes, you sorta have to do it - as long as the broader PCI-DSS is in place, the deadlines are most likely going to hold.  In other words, if you want to continue selling your products to companies that take credit cards, you are going to have to go through this process or you are going to be ‘left behind.’  The council posts the list to the public with very clear language and the list itself is already being used to qualify or dis-qualify applications by merchants looking to purchase new solutions. 
4. You are probably not ready - if for no other reason than your documentation (at the very least) most likely doesn’t meet the standard’s requirements.  NetSPI (the company that I work for) is one of the few PA-QSA firms to actually have multiple applications on the PA-DSS list under the current standard (1.2) and we have a number currently in-process.  So far we haven’t seen initial documentation (even from the largest vendors) that met the requirements of the standard without having to go through an update process.
5. Given #4, Expect a Collaborative Process with your PA-QSA - you are going to require effective and actionable feedback from your PA-QSA assessor and you should be prepared to take action based on their feedback.  Don’t get upset if things need to be changed or if assumptions are challenged.  On the flip side, expect your QSA to provide direction and to explain how they and the council will interpret the standard.
6. Don’t expect an easy ‘pass’ - look at #1 again.  This isn’t PABP - this isn’t a voluntary process that results in a high-level review of your application.  This is a robust investigation of your application, your SDLC, your support process, your documentation, etc.  Expect this to be a somewhat painful process, but expect it to also improve your best-practices from a security perspective.  At the end of the day you should come out of this process in a better place.
7. Don’t look at this assessment as a ‘one-off’ - the way that PA-DSS is structured, you are going to have to address the entire ‘program’ concept day 1 - with the ‘major’ and ‘minor’ release approach, you are being forced to look at security and PCI EVERY time you have a significant release of code.  Sounds hard.  Sounds expensive (it can be.)  It needs to be addressed from the beginning and it needs to be addressed in a manner that takes the long-term into consideration - where can efficiencies in your SDLC be found?  If you have multiple product lines, can you isolate the PCI-relevant code out into a standard ‘module’?  Are you storing data that you simply don’t need to store?  How can you prepare yourself in a way that minimizes the cost/disruption the next time (or for other applications)? Etc.
8. PA-DSS applies equally to all software vendors, regardless of size - the PCI Council doesn’t care if you are a 3 person shop building a minimal POS for 10 customers or a Fortune 500 multi-national with a large suite of applications, the PA-DSS standard is the same regardless.  Unlike PCI-DSS, there are no tiers, no designation of levels - just a standard that applies to all PCI-relevant applications sold.

This is just a quick note and hardly scratches the surface on PA-DSS, but it’s a start and might provide some useful information for you.  PA-DSS has proven to be a confusing standard to those that didn’t go through the PABP process previously and even those that dealt with PABP are often under the impression that PA-DSS is basically the same thing….  

Thanks for looking through this and if I have confused more than I have enlightened, if you are looking for some additional feedback on what’s above, if you have an issue with my points, or you simply need a sympathetic audience, please feel free to comment or to use the contact page and I’ll get back to you directly.  Thanks.