If you are a company that “stores, processes, or transmits” cardholder data as part of payment processing, then you should be familiar with the Payment Card Industry Data Security Standard (PCI DSS). However, fewer people may know that there is a related PCI standard for software vendors that develop the payment applications which are “sold, distributed, or licensed to third parties for the purposes of supporting or facilitating payment transactions.” Known as the PCI Payment Application – Data Security Standard (PCI PA-DSS), the standard was first introduced by Visa in the early 2000s as the Payment Application Best Practices (PABP). Recently, the PCI Security Standards Council announced major changes coming to the PA-DSS
On January 16th, PCI released the PCI Secure Software Requirements and Assessment Procedures (Secure Software Standards) and Software Security Lifecycle (Secure SLC) Requirements and Assessment Procedures, two components of its new PCI Software Security Framework. PCI describes the new framework as a “collection of software security standards and associated validation and listing programs for the secure design, development and maintenance of modern payment software.”
The framework differs from its PA-DSS predecessor in several ways:
- Strong emphasis on robust risk management practices
- Programmatic approach to payment application security with multiple components
- Focus on “software security resiliency” instead of “secure software development cycle”
- Requires separate secure software lifecycle validation
- Expanded recommendation of using the new standard for bespoke payment applications that are not sold or distributed commercially
To address the dynamic nature of software application development, the PCI Secure SLC framework offers “objective-focused security practices that can support both existing ways to demonstrate good application security and a variety of newer payment platforms and development practices.” Its goal is to “protect payment transactions and data, minimize vulnerabilities, and defend payment software from attacks throughout the software lifecycle.” The standard applies to “the vendor’s SLC processes, technology, and personnel involved in the design, development, deployment, and maintenance of the vendor’s payment software products and services.”
Vendors will attest to the new framework as a replacement for the current PA-DSS beginning in 2022.
Observations on the Framework
Here are some key takeaways on the new framework and how it is a welcome improvement:
- Fully embraces the concept of “secure by design”
- Demonstrates that the Council is paying attention to what is happening in the field, especially with the ongoing issue of breaches
- Is more scalable than the previous PA-DSS and will allow for the inclusion of emerging technologies
- Offers a clear and needed delineation between payment applications which have an ancillary role in payment transactions versus those that store, process, or transmit CND and/or SAD, which should cut down on the number of “Not Applicables” seen during attestation
- Could be used as an excellent security standard for non-payment applications, such as those which handle sensitive data or personally identifiable information (PII), and can aid in compliance for other standards such as GDPR
- Codifies development’s and engineering’s role in the security stature of an organization
- Re-emphasizes the need for secure coding training for developers and engineers, as well as security awareness training (SAT) for everyone.
As with all PCI Standards, there will be tweaks and clarifications over the next three years as the new framework is socialized in the payment application industry. However, the Council has released a strong standard that allows for the dynamic nature of software development and has at its core the need to protect consumers who use payment services.