PCI Secure SLC 2.0: payment software needs a transition plan

On 28 September 2026, PCI SSC released Secure Software Lifecycle Standard version 2.0, addressing digital tools including AI. Assessor training is planned for the fourth quarter. The twelve-month transition from version 1.1 begins when training becomes available, not automatically on the publication date.

What is being assessed

Secure SLC concerns the development lifecycle. For buyers of payment software, the finished product and the process used to create it are distinct assessment subjects. PCI SSC explains that Secure SLC and Secure Software assessments do not require each other. A supplier's broad PCI-compliance statement is therefore incomplete without the standard and scope.

Consider an urgent payment-integration fix. The code change may be small, but a safe release still involves author access, review, a build, release authorization and a rollback route. If one step exists only as an informal chat agreement, reconstructing events after an incident becomes harder. This is an editorial example of why the development process matters independently.

AI tools add another part to that history. A team needs to understand which material reaches the tool and how its output enters the production application. A person pressing the release button does not alone explain the origin or review of a change. An up-to-date tool inventory and a documented code path have practical value.

Vendors should compare their current process with the new version and clarify programme timing with an assessor. Merchants need to understand the developer's actual validation and how it is maintained. This does not mean every store immediately needs a new assessment.

The transition condition is particularly important. If training is not yet available, its start cannot be replaced with a convenient press-release date. The actual calendar and assessment scope matter more operationally than the appearance of 2.0 in the title.

What vendors and PSPs should check

For payment-solution developers and PSPs that build their own payment pages, SDKs or integrations, the release is a prompt for a short process review before the transition period starts.

• Is the inventory of development tools current, including AI assistants, and are there rules about which data may be shared with them?
• Does every change, including urgent fixes, go through code review and release approval?
• Are builds, dependency origins and released versions recorded so the history can be reconstructed?
• Is developer access to production separated from access to cardholder data?
• Is someone responsible for tracking the transition calendar and the timing of assessor training?

What it means for merchants

Merchants should ask their payment-application vendors which standard and which scope their validation covers, when the current validation expires and how the vendor plans the transition. These questions belong in the annual vendor review and in the contract, especially where an integration affects the merchant's own PCI DSS scope. An answer of "we are PCI compliant" without a named standard and scope is best treated as incomplete, and a supporting document should be requested.

Internal development teams benefit from preparing an evidence pack in advance: a description of the release process, a change log and a tool list. It can serve both the assessor and large customers who ask for proof of secure development practices.

Sources: PCI SSC Secure SLC 2.0 release; PCI Secure SLC programme overview