The global payment landscape is undergoing a pivotal transition. With the release of the PCI Secure Software Standard v2.0, the PCI Security Standards Council (SSC) has moved toward a more flexible, outcome-based framework. Effective January 2026, this update is available for use along with the previous version (v1.x) and introduces a more adaptable approach to software security.
These six principles are the most significant updates to the PCI Secure Software Standard, and they are important whether you are a developer, an auditor, or a business leader.
To assist with your compliance efforts, we have made available two downloadable guides. These include formal notification templates for the PCI SSC, aligned with the specified requirements for the Vulnerability Risk Assessment (VRA) and Customer Security Advisory.
1. New Scope Definition: The "Sensitive Asset"
The most impactful change is the removal of the term "Payment Software" as a classification. Instead, the standard now focuses on Sensitive Assets.
A Sensitive Asset is defined as any component of the software, including data, specific functions, or system resources, that, if accessed by an unauthorized individual, could jeopardize payment security.
- The SAID Document: To assist with this transition, the SSC released the Sensitive Asset Identification (SAID) document. This is a mandatory document that helps organizations identify exactly which parts of their software must be protected under the standard.
2. Security Structure: A Core-First Approach
The standard has been reorganized to align with modern software development. The previous "Control Objectives" are now called “Security Objectives”.
- 11 Core Objectives: Every piece of software must now meet 11 universal security goals, ranging from managing the "Bill of Materials" (a list of all software components) to detecting unusual system behavior.
- Standardized Cryptography: Rather than listing specific technical requirements that may quickly become outdated, the standard now requires a baseline of "Strong Cryptography." This allows the standard to remain valid even as encryption technology improves globally.
- Unified Glossary: All technical definitions are now found in Appendix A of the standard, ensuring all international stakeholders use the same terminology.
3. Expansion to SDKs and Public Networks
The update includes new modules that address specific types of technology used in modern commerce:
- Module D (SDKs): This is a new section specifically for Software Development Kits (SDKs). It provides a way to validate the security of tools that other developers use to build payment applications.
- Module C (Publicly-Accessible Software): Formally known as "Web Software," this module now covers any software that can be reached over a public network.
- Module B (POI Device Software): Requirements for point-of-interaction (terminal) software have been simplified and integrated with the core objectives to reduce repetitive tasks during the assessment.
4. Mandatory Source Code Reviews
Version 2.0 removes any uncertainty regarding the assessment process: Providing source code to the assessor will be mandatory under Version 2.0. It is no longer possible to complete a validation without a review of the underlying code nor can code be sampled. The testing methodology now follows three specific steps:
- Document Review: Evaluating security policies and design records.
- Static Analysis: Examining the code without running it to find vulnerabilities.
- Dynamic Analysis: Observing the software while it is running to ensure it handles both normal and malicious inputs correctly.
5. Efficient Update Management (Tiers and Wildcards)
To support faster development cycles, Version 2.0 introduces more efficient ways to manage software updates:
- Delta Change Tiers: Software changes are now categorized into newly defined tiers - Tier 1 (Low Impact) and Tier 2 (High Impact). Vendors who are Secure SLC-Qualified can now self-approve security patches as Tier 1, which avoids the need for a full external audit for every Tier 2 (High Impact) update.
- Wildcard Versioning: The use of wildcards (such as v1.0.x) is now officially permitted. This allows companies to release minor, non-security updates without needing to re-register the software with the PCI SSC each time.
6. Transparency and Response Requirements
The administrative rules have become stricter to ensure better communication between vendors and the Council:
- The 45-Day Administrative Period: If an organization misses a deadline for their annual review, their software listing will be marked in orange. If the issue is not resolved within 45 days, the product is listed as Expired, and a complete new assessment will be required.
- Standardized Vulnerability Reporting: A new section (Section 8) outlines exactly how companies must report security breaches. This includes using the Common Vulnerability Scoring System (CVSS) or other industry-accepted standard scoring to provide a clear, mathematical description of the risk level.
In Summary
The PCI Secure Software Standard v2.0 represents a global effort to make payment security more objective and data-driven. By focusing on "Sensitive Assets" rather than software types, the standard provides a clear path for organizations worldwide to protect the global payment ecosystem.