Six Ways PCI DSS 3.2 Impacts Vendor Risk with Payment Application Developers

In 2012, Global Payments, a credit card payments processor, was compromised, and the credit card information of 1.5 million customers was stolen, costing Global Payments $94 million dollars in penalties and reparations.

A breach at third parties handling your payment applications may cost you as much, but companies still must conduct robust vendor risk management with these developers. Here are six ways version 3.0 impacts vendor risk management with payment application developers:

1. PA-DSS compliance doesn’t mean PCI compliance.

The new update clarifies that applications that follow PA-DSS standards are still within the scope of a PCI DSS audit. From a vendor risk management standpoint, you or the developer can’t assume that PA-DSS-compliant software is necessarily also complying with the PCI DSS.

2. Training standards

Vendor personnel with any PA-DSS responsibility must receive annual training. Companies must insist upon this from their vendors and check for as part of their vendor risk management initiatives.

3. Application updates

Vendors have to provide written details of any updates to their applications, which should give vendor risk management staffs more visibility into their payment application developers.

4. Risk assessment during the development process

The PA-DSS update mandates that vendors must incorporate risk assessment techniques into their software development, meaning knowledge software can be thoroughly vetted before you even screen the vendor.

5. Differing passwords

Vendors now require a unique authentication credential is now required for each individual customer environment. If the password information for another company is breached, the hacker won’t automatically possess the info for your company as well.

6. Source code integrity

Under the new standards, payment application vendors must verify the integrity of source code during the development process. Best practices in coding techniques are mandated as well. Furthermore, only people directly involved with an application should have write access to it. Vendor risk management screenings may ask about this final point; PA-DSS now requires it in the hopes of preventing unauthorized employees at the vendor from inserting their own, potentially invasive, code.