Source: Dark Reading
Why the PCI Council Needed a New Framework
The PCI Security Standards Council released the PCI Software Security Framework, a new software security standard designed to validate payment ecosystem security in the context of modern software architectures and development practices. The framework is intended to ultimately replace the existing PCI Payment Application Data Security Standard (PA-DSS).
The motivation is straightforward: payment software is no longer built or delivered the way it was when PA-DSS was written. Organizations now ship software multiple times per day, build on microservices, deploy to hybrid clouds, and rely heavily on containerization and third-party libraries. The old standard was not designed with any of that in mind.
“Software development practices have evolved over time, and the new standards address these changes with an alternative approach for assessing software security.”
Troy Leach, CTO, PCI Security Standards Council
The Problem with PA-DSS in a DevOps World
Jeff Williams, co-founder and CTO of Contrast Security and a participant in the expert council that contributed to the new standard, described PA-DSS as “very brittle.” The standard mandated specific controls in a prescriptive way — “you had to do A, B, and C” — which left little room for the reality of modern development pipelines.
“When you’re looking at DevOps projects that are releasing seven times a day and moving super fast and using tons of libraries, and building APIs, and deploying in the cloud, that old standard just didn’t work well.”
Jeff Williams, CTO, Contrast Security
PA-DSS was designed to guide traditional payment software developers in securing the software development lifecycle (SDLC). It was not built to account for the pace, tooling diversity, or architectural patterns that characterize mature DevOps organisations.
What the PCI Software Security Framework Introduces
Rather than a rigid checklist of controls, the new framework takes an objective-focused approach. This gives organisations greater flexibility in how they demonstrate that their software meets security goals, while still providing a consistent validation methodology for payment application security.
Key changes include:
- Broader security testing options: In addition to static analysis (SAST), dynamic analysis (DAST), and manual penetration testing, the framework explicitly recognises Interactive Application Security Testing (IAST) as a valid testing methodology.
- Support for continuous testing: IAST is particularly relevant for DevOps environments because it can monitor applications during runtime as part of automated pipelines, rather than requiring a discrete testing phase that interrupts delivery.
- Secure Software Lifecycle qualification: The framework introduces a separate qualification path for vendors that can demonstrate mature, security-focused design and development practices — going beyond individual application validation.
- Expanded scope: Where PA-DSS focused on the SDLC for traditional payment software, the new framework addresses overall software security resilience, covering a broader range of modern payment platforms.
IAST and Continuous Security Validation
The inclusion of IAST as an accepted testing method is significant for DevOps teams. Unlike SAST (which analyses source code without executing it) or DAST (which probes a running application from the outside), IAST instruments the application itself during execution. This allows security testing to happen continuously as part of integration or staging pipelines, fitting naturally into CI/CD workflows without requiring separate test windows.
For teams releasing software frequently, this removes a longstanding friction point: the need to pause the pipeline for a dedicated security testing phase in order to remain compliant.
Transition Timeline: PA-DSS Is Not Going Away Immediately
The PCI Council was clear that the transition from PA-DSS to the new framework would be gradual. Organisations that have already invested in PA-DSS validation will not be immediately disrupted. According to Troy Leach at the time of the announcement:
- PA-DSS validated applications would continue to be governed under that programme until 2022.
- A formal validation programme for the new Software Security Framework was expected to be released during 2019.
- The two standards are described as “not mutually exclusive” — organisations can leverage either or both during the transition period, with the new framework offering a progressive path.
“There will be a gradual transition period to allow organizations with current investments in PA-DSS to continue to leverage those investments.”
Troy Leach, CTO, PCI Security Standards Council
What This Means for DevOps and Security Teams
For engineering and security teams building or maintaining payment-related software, the PCI Software Security Framework represents a meaningful shift in how compliance intersects with modern delivery practices. The key takeaways are:
- Flexibility over prescription: The objective-based model gives teams room to choose security tooling and processes that fit their pipeline, rather than mapping to a fixed list of required controls.
- DevOps-friendly testing: Recognition of IAST removes a significant barrier for teams using continuous delivery.
- Vendor maturity rewarded: The Secure Software Lifecycle qualification offers a pathway for vendors with strong security practices to demonstrate that at an organisational level, not just per-application.
- Plan for the PA-DSS sunset: Teams still operating under PA-DSS validation should understand the transition timeline and begin evaluating alignment with the new framework ahead of the eventual retirement of PA-DSS.
The framework was developed with input from payment technology and security industry experts, reflecting a broader effort by the PCI Council to keep its standards relevant as the technology underpinning payment systems continues to evolve rapidly.