PA DSS Compliance for Software Providers

Reports of the steady increase in data security breaches led the Payment Card Industry Security Standards Council (PCI SSC) to publish the Payment Application Data Security Standard (PA-DSS). All software providers whose applications store, process, or transmit cardholder data must comply.

For any payment application system to be authorized PA-DSS compliant, it must conform to a set of requirements designed to protect secure card holder data and prevent storage of card holder data in such as way that it might be pilfered from a server connected to the Internet. Software vendors such as shopping cart vendors, payment service providers, and payment software companies who develop payment application and point-of-sale (POS) systems and want to verify that their application is PA-DSS-compliant must turn to a Payment Application-Qualified Security Assessors (PA-QSAs) for extensive payment application gap-analysis, payment application testing, code review, implementation guide assistance and several other key PA-DSS related services.

Versatalis offers alternatives to this complex and cost intensive process by eliminating all cardholder data from the processing environment and ensuring the Payment Application no longer stores, processes or transmits cardholder data. For a complete strategy, please click here for an integration strategy that eliminates PA DSS requirements from any software application and significantly reduces the scope of PCI Compliance for merchants.

What every Software Provider needs to know about PA DSS.

Misconception

A common misconception among Software Vendors is that the use of a PA-DSS compliant application will make the entity PCI DSS compliant.

The rules

If a Software Vendor has an integrated payment application that stores, processes or transmits cardholder data as part of the authorization or settlement, the application falls into scope of PA-DSS. Software vendors must validate that thier payment application complies with the PCI Payment Application Data Security Standard (PA-DSS). Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment. Click here for a complete outline of the Payment Application Data Security Standard.

Solution

Versatalis works with Software Vendors to eliminate all elements of cardholder data that put their application in scope for PA DSS. Our solution eliminates the requirement to validate PA DSS since the application no longer stores, processes or transmits cardholder data nor is this information part of the authorization and settlement records. We offer a full end to end encryption solution that eliminates all cardholder data from the software application. The benefits to your organization include:

1. Eliminates the costs associated with a PA DSS validation*
2. Increase the security of your application by eliminating sensitive cardholder data
3. Significantly reduce the scope of PCI Compliance for your customers

*In order to validate PA DSS compliance, a Payment Application-Qualified Security Assessor (PA-QSA) must be used to create a Validation of Compliance. A complete list can be found on the PCI Security Standards web page.

Initial PA-QSA Expense: $20,000 to $30,000
Development expense to achieve Validation: $10,000 +
Annual Listing fee: $1,250

Additional Reading as taken directly from the document used by Payment Application-Qualified Security Assessors (PA-QSAs) conducting payment application reviews, so that software vendors can validate that a payment application complies with the PCI Payment Application Data Security Standard (PA-DSS). This document is also used by PA-QSAs as a template to create the Report on Validation.

Scope of PA-DSS

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties. The following guide can be used to determine whether PA-DSS applies to a given payment application:

• PA-DSS does apply to payment applications that are typically sold and installed "off the shelf" without much customization by software vendors.
• PA-DSS does apply to payment applications provided in modules, which typically includes a "baseline"module and other modules specific to customer types or functions, or customized per customer request. PADSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies to those modules as well. Note that it is considered a "best practice" for software vendors to isolate payment functions into a single or small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can limit the number of modules subject to PA-DSS.
• PA-DSS does NOT apply to payment applications offered by application or service providers only as a service (unless such applications are also sold, licensed, or distributed to third parties) because:
  1. The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install,or control the application or its environment;
  2. The application is covered by the application or service provider's own PCI DSS review (this coverage should be confirmed by the customer); and/or
  3. The application is not sold, distributed, or licensed to third parties.

Examples of these "software as a service" payment applications include:

1. Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers' use. Note that PA-DSS would apply, however, if the ASP's payment application were also sold to, and implemented on, a third-party site, and the application was not covered by the ASP's PCI DSS review.
2. Virtual terminal applications that reside on a service providers' site and are used by merchants to enter their payment transactions.

Note that PA-DSS would apply if the virtual terminal application has a portion that is distributed to, and implemented on, the merchant's site, and was not covered by the virtual terminal provider's PCI DSS review.

• PA-DSS does NOT apply to non-payment applications that are part of a payment application suite. Such applications (for example, a fraud-monitoring, scoring or detection application included in a suite) can be, but are not required to be, covered by PA-DSS if the whole suite is assessed together. However, if a payment application is part of a suite that relies on PA-DSS requirements being met by controls in other applications in the suite, a single PA-DSS assessment should be performed for the payment application and all other applications in the suite upon which it relies. These applications should not be assessed separately from other applications they rely upon since all PADSS requirements are not met within a single application.
• PA-DSS does NOT apply to a payment application developed for and sold to a single customer for the sole use of that customer, since this application will be covered as part of the customer's normal PCI DSS compliance review. Note that such an application (which may be referred to as a "bespoke" application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications.
• PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant's or service provider's normal PCI DSS compliance.

For example, for the last two bullets above, whether the in-house developed or "bespoke" payment application stores prohibited sensitive authentication data or allows complex passwords would be covered as part of the merchant's or service provider's normal PCI DSS compliance efforts and would not require a separate PA-DSS assessment.

The following list, while not all-inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):

• Operating systems onto which a payment application is installed (for example, Windows, Unix)
• Database systems that store cardholder data (for example, Oracle)
• Back-office systems that store cardholder data (for example, for reporting or customer service purposes)

The scope of the PA-DSS review should include the following:

• Coverage of all payment application functionality, including but not limited to 1) end-to-end payment functions (authorization and settlement), 2) input and output, 3) error conditions, 4) interfaces and connections to other files, systems, and/or payment applications or application components, 5) all cardholder data flows, 6) encryption mechanisms, and 7) authentication mechanisms.
• Coverage of guidance the payment application vendor is expected to provide to customers and resellers/integrators (see PA-DSS Implementation Guide later in this document) to ensure
  1. customer knows how to implement the payment application in a PCI DSScompliant manner and
  2. customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS compliance.

Note that the payment application vendor may be expected to provide such guidance even when the specific setting

1)cannot be controlled by the payment application vendor once the application is installed by the customer or 2) is the responsibility of the customer, not the payment application vendor.

• Coverage of all selected platforms for the reviewed payment application version (included platforms should be specified).
• Coverage of tools used by or within the payment application to access and/or view cardholder data (reporting tools, logging tools, etc.)