On September 28, 2026, the PCI Security Standards Council (PCI SSC) released Version 2.0 of the PCI Secure Software Lifecycle Standard. This is the first major revision since the standard was originally introduced.
The PCI Secure Software Lifecycle Standard (PCI SSLC) defines security requirements and assessment procedures for software vendors' development processes. Together with the PCI Secure Software Standard, it forms the PCI Software Security Framework.
In Version 2.0, the PCI SSC adopts key concepts from PCI Secure Software Standard v2.0 and removes overlaps between the two standards. New requirements address areas such as AI-enabled tools and risks across the software supply chain.
Key Changes Introduced by PCI Secure Software Lifecycle Standard v2.0
New Focus on Sensitive Assets
One of the most significant changes is the adoption of the "Sensitive Assets" concept from PCI Secure Software Standard v2.0. Software vendors must systematically identify and document the Sensitive Assets within their software products. The accompanying PCI guidance document "Sensitive Asset Identification" supports organizations in identifying, classifying, and documenting these assets.
Under the new Security Objective 4, organizations must systematically consider and clearly document how the requirements of the PCI Secure Software Standard are incorporated into the lifecycle of their software products.
New Requirements for Tools and AI
For the first time, the standard addresses risks associated with tools used throughout the Secure Software Lifecycle. These include:
- Integrated Development Environments (IDEs)
- Design tools
- Build and compiler systems
- Repositories
- AI-enabled tools
Organizations must establish clear processes for the selection and use of tools. This includes providing guidance and training for personnel, ensuring appropriate human oversight, and validating results. The tools and processes in use must also be documented in a traceable manner.
New SSLC Steward Role
Version 2.0 introduces the role of the SSLC Steward. The role may be assigned to an individual or a group and is responsible for overseeing the Secure Software Lifecycle as a whole. Responsibilities include coordinating training activities and approval processes, as well as overseeing the defined security activities. Organizations should evaluate whether existing roles can assume these responsibilities or whether responsibilities need to be consolidated differently.
Mandatory Bill of Materials
As already required by PCI Secure Software Standard v2.0, PCI SSLC will now also require the creation and maintenance of a Bill of Materials (BOM). This inventory helps organizations identify affected components more quickly when vulnerabilities are discovered in libraries or other dependencies.
New Security Objective for Software Retirement
With the introduction of Security Objective 8, Version 2.0 establishes requirements for the secure retirement of software. Vendors must define processes that enable customers to decommission software securely.
Enhanced Threat Management and Change Management Requirements
PCI SSLC v2.0 also strengthens requirements related to threats, vulnerabilities, and changes. Previously identified Sensitive Assets become a key focus within these processes. Organizations must document planned changes during the planning phase and analyze their impact on Sensitive Assets and relevant PCI Secure Software Standard requirements. Associated test results must also be clearly traceable. In addition, organizations must define how they can safely revert to a previous software version if issues arise.
Increased Requirements for Software Development Environments
Another new requirement is the explicit separation of pre-production and production environments through logical or physical controls. Real or live payment transaction data, such as Primary Account Numbers (PANs), must not be used for testing purposes. Organizations must also maintain auditable records of all access and access attempts by individuals and systems to the codebase. These records must be protected against tampering and retained for a defined period. Before software is deployed into production, any test data must be removed.
Removal of Existing Control Objectives
The PCI SSC has also removed two existing Control Objectives from Version 2.0. Control Objective 2 has been eliminated. It previously contained extensive requirements related to software security policies, strategies, and assurance processes. Control Objective 7 has also been removed. It previously covered security requirements for handling production data, for example during support or troubleshooting activities.
Changes to Reporting and Listing
In addition to the technical requirements, several program and reporting documents have been updated. The familiar Report on Compliance (RoC) and Attestation of Compliance (AoC) documents will be replaced by the Report on Validation (RoV) and Attestation of Validation (AoV), aligning PCI SSLC with PCI Secure Software Standard reporting terminology.
When Does PCI SSLC v2.0 Take Effect?
A twelve-month transition period from Version 1.1 to Version 2.0 will begin once Secure Software Lifecycle Assessor training becomes available. These training courses are currently planned for the fourth quarter of 2026. The PCI SSC has not yet announced a specific start date for the transition period.
Existing PCI Secure Software Lifecycle Standard v1.1 validations will remain valid for the time being. Since revalidations continue to follow the regular assessment cycle, the transition to Version 2.0 may not become relevant for already validated organizations until a later point, depending on their individual assessment cycle.
Our PCI Expert's Perspective
"The update to PCI SSLC v2.0 was a logical and necessary step following the extensive changes introduced with PCI Secure Software Standard v2.0. The two standards now align much more effectively and reduce previous overlap. At the same time, the new requirements address current challenges such as the use of AI in development processes and software supply chain risks by requiring organizations to create and maintain a Bill of Materials. Software vendors should begin aligning their development processes with these changes as early as possible and identify potential gaps, as Version 2.0 introduces new processes and documentation requirements in several areas."
Lorenz Heiler, Managing Consultant and PCI SSF Assessor, usd AG
Would you like to determine which PCI Secure Software Lifecycle Standard v2.0 requirements are relevant for your next assessment? Our PCI experts can help you review existing processes and documentation, identify gaps, and prepare efficiently for your next validation. Contact us.
