Category Archives: pa dss

PA DSS Process Change

pa dss, pci dss

We’ve just been reading the monthly assessor newsletter as sent from the PCI SSC, and there’s an update in there that will affect a number of our PA DSS clients.

It’s a process change relating to payment of the SSC’s invoice. To quote:

“As soon as a ROV is submitted, we will invoice the application vendor and the ROV will not be reviewed until payment is received.”

Therefore, please be aware that the SSC will invoice you directly once we submit your ROV, but they will not review it until their invoice is paid.

This change is effective immediately.

New QIR Program for Integrators and Resellers

pa dss, pci dss

If you’re an integrator or reseller of a PA-DSS application or a PA-DSS software vendor implementing PA DSS applications within the merchant environment, then this will be of interest to you.

The PCI SSC has announced the Qualified Integrators and Resellers program. This will train and certify software integrators and resellers on the secure installation and maintenance of validated PA DSS applications.

The program is a response to market demand for guidelines for integrators and resellers, as well as challenges with secure installation and configuration of payment applications.

Training will take place later this summer, and a global list of certified organisations will be available thereafter.

Links:

The QIR Program: https://www.pcisecuritystandards.org/qir
Press Release: https://www.pcisecuritystandards.org/pdfs/pr_120510_qir.pdf

PA DSS Program Guide v2.0

pa dss, pci dss, security, ,

The PA-DSS Program Guide v2.0 and Attestation of Validation (AOV) v2.01 are now available for immediate use.

These document updates are primarily about alignment and clarification. They don’t represent a change to the PA DSS standard.

Software vendors will be particularly interested in the pricing guide which details the fees charged by the PCI SSC for listing applications, and the associated transition FAQ. Amongst the changes contained within the new Program Guide are details of “minor change” classifications, now referred to as “No-Impact”, “Low-Impact” or “High-Impact”. In short, only a “High-Impact” change to an application would trigger a complete reassessment, although there’s plenty of detail about what needs to be done in the event of No or Low impact changes being identified.

Which Applications Are Eligible for PA DSS?

mobile, pa dss, smartphone, , , , , ,

A FAQ, which is neatly addressed in the PCI SSC guidance note available from here.

In summary:

If you can answer “yes” to any of the following questions, then your application is not eligible for validation under PA DSS (but may still be required to operate in a PCI DSS compliant fashion)

  1. Is this a beta version of the application?
  2. Does the application handle cardholder data, but the application itself does not facilitate authorization or settlement?
  3. Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
  4. Does the application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements?
  5. Is the application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions? For example Reporting and CRM, or Rewards or fraud scoring
  6. Is the application developed in-house and only used by the company that developed the application?
  7. Is the application developed and sold to a single customer for the sole use of that customer?
  8. Does the application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components?
  9. Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
  10. Is the application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own?
  11. Is the application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties?
  12. Is the application an operating system, database or platform; even one that may store, process, or transmit cardholder data?
  13. Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?

Point 13 above is expanded upon in the SSC document “Mobile Payment Acceptance FAQ“, where the different categories of mobile payment acceptance applications are detailed.