On 28 September 2026, the PCI Security Standards Council published version 2.0 of the PCI Secure Software Lifecycle (Secure SLC) Standard, along with new program documents and reporting templates. The Council calls it the first major revision of the standard. If you are a payment software vendor with a validated Secure SLC, or you plan to get one, the clock on your move to v2.0 starts when assessor training is released.
What's affected
The Secure SLC Standard is one of two standards in the PCI Software Security Framework. It sets the security requirements and assessment procedures a software vendor uses to validate its development lifecycle. The other standard, the PCI Secure Software Standard, validates individual products. Its own v2.0 came out on 15 January 2026, and Secure SLC v2.0 is aligned with it.
According to the Council's announcement, v2.0:
- Adds a focus on "sensitive assets" and a new Sensitive Asset Identification Document (SAID).
- Adds content and requirements on digital tools, including how AI is accounted for in a vendor's Secure SLC processes.
- Covers only the vendor's Secure SLC, with objective-based requirements meant to work for vendors at different maturity levels.
- Keeps the two standards independent. The Council states that neither standard requires an assessment to the other.
usd AG, a PCI assessor, has published a walkthrough of the changes. Its summary lists:
- Security Objective 4 (new): document how the Secure Software Standard's requirements are built into your lifecycle.
- Tool risk, including AI-enabled tools: IDEs, build and compiler systems, repositories and AI tools need selection processes, training, human oversight, validation of results and traceable records.
- A new SSLC Steward role that oversees the whole lifecycle.
- A bill of materials that must be created and maintained.
- Security Objective 8 (new): secure software retirement, so customers can decommission products safely.
- Development environment controls: separation of pre-production and production, no live payment data such as PANs in testing, tamper-protected records of codebase access, and removal of test data before release.
- Change management: documented impact analysis for planned changes, traceable test results and a defined way to roll back to a previous version.
- Reporting: the Report on Validation (ROV) and Attestation of Validation (AOV) replace the old report formats. Former Control Objectives 2 and 7 are removed.
The published documents are the standard, a Summary of Changes from v1.1 to v2.0, a Program Guide for v2.x, the ROV and AOV templates, and updated SSF Assessor Qualification Requirements dated September 2026.
Does this apply to you?
Work through these criteria:
- You hold a Secure SLC validation today. You will need to move from v1.1 to v2.0 within the transition window. usd AG notes that existing v1.1 validations remain valid for now, and the move happens on your normal revalidation cycle.
- You sell payment software validated under the Secure Software Standard and want the program benefits a validated Secure SLC brings. The Council says vendors with a listed and validated Secure SLC receive benefits for products they develop under it.
- You are planning a first Secure SLC validation. Build to v2.0 now. Starting on v1.1 means doing the work twice.
- You are a merchant or service provider buying payment software. The standard does not bind you, but your vendor's listing status and its BOM practices are fair questions in procurement.
If none of these fit, nothing here creates a new obligation for you. Secure SLC validation is a program vendors choose to join.
What to do now
A dated checklist, based on what the Council has published:
- This month (October 2026): download v2.0 and the Summary of Changes from the PCI SSC Document Library. Assign one owner to map each changed objective to your current process documents.
- By end of November 2026: build your Sensitive Asset Identification Document for each in-scope product. If you already did this for Secure Software Standard v2.0, reuse it.
- By end of November 2026: inventory the tools in your lifecycle, including AI coding assistants, and record who approved each one, how outputs are reviewed and where that review is logged.
- By end of December 2026: confirm you can produce a bill of materials for every release, and that it is stored with the release record.
- Q4 2026: watch for the Council's assessor training release. The Council says computer-based training for existing assessors and instructor-led training for new assessors are expected in Q4 2026, and the 12-month transition from v1.1 to v2.0 begins once training is available. Put that start date in your compliance calendar the day it is announced.
- Before your next revalidation: talk to your assessor about whether to assess against v2.0 directly.
Why it matters
The AI tooling requirement is the change most teams will feel. Many vendors adopted AI coding assistants without a written record of who approved them or how their output is checked. v2.0 turns that into an assessable control, and the evidence has to exist before the assessor arrives.
The BOM requirement matters too. When the next library vulnerability lands, the vendors who can answer "which of our releases contain it?" in minutes are the ones who already keep a BOM per release. The standard now expects you to be one of them.
Try it yourself
Pick one release of a payment-related product and generate a component list for it. If you only have a manifest to hand, drop a package.json, requirements.txt or a CycloneDX or SPDX SBOM into the free scanner at https://gold.safeguard.sh/scan. It runs in the browser, the file never leaves your machine, there is no login, and it handles up to 100 dependencies per scan. Note any component you could not have named from memory. That gap is what the BOM requirement is meant to close.
Click through it at your own pace, or open it full screen.
Quick check
When does the 12-month transition from Secure SLC v1.1 to v2.0 start?
When assessor training for v2.0 becomes available. The Council expects that training in Q4 2026 but has not given an exact date.
Does a vendor need a Secure Software Standard assessment to get Secure SLC v2.0 validation?
No. The Council states that the two standards complement each other and that neither requires an assessment to the other.
Which reports replace the old formats under v2.0?
The Report on Validation (ROV) and the Attestation of Validation (AOV).
Sources
- PCI SSC: PCI SSC Releases Version 2.0 of the Secure Software Lifecycle Standard (28 September 2026)
- PCI SSC: PCI SSC Releases Version 2.0 of the PCI Secure Software Standard (15 January 2026)
- usd AG: PCI Secure Software Lifecycle Standard v2.0 Released, Key Changes at a Glance
- PCI SSC Document Library
