New AI Requirements in PCI Secure SLC Standard v2.0
The PCI Security Standards Council (PCI SSC) opened a 30-day Request for Comments (RFC) period from May 15 to June 15 for the Secure Software Lifecycle (SLC) Standard v2.0. This draft introduces new requirements for "digital tools", explicitly including artificial intelligence (AI) in vendor secure development practices. Vendors must now account for AI in their lifecycle processes, creating a compliance checkpoint that many payment security teams are unprepared for.
This revision aligns with the recently published PCI Secure Software v2.0 Standard, which shifted focus to "sensitive assets" rather than just cardholder data. The Secure SLC Standard v2.0 extends that logic: if AI tools touch your software development pipeline, they're now in scope for validation.
Key Dates
- 2019: PCI Secure SLC Standard introduced
- 2025: First RFC conducted, stakeholder feedback collected
- May 15, 2026: RFC period opens for v2.0 draft
- June 15, 2026: RFC period closes
- Second half of 2026: Final standard publication expected
Identifying Missing Controls
The issue isn't a breach; it's a blind spot. Most payment software vendors use AI-assisted development tools like code completion engines, automated testing frameworks, and security scanners powered by machine learning. Until now, the Secure SLC Standard didn't require vendors to demonstrate how these tools fit into their secure development lifecycle.
Here's what's been missing:
No validation of AI tool provenance. You don't know if your vendor's code completion tool was trained on public repositories that include exposed credentials or insecure patterns. You don't know if the model's training data included payment card data.
No assessment of AI-generated code security. When an AI tool suggests a database query or API call, there's no requirement to verify that suggestion against secure coding standards before it ships. Your vendor might be running static analysis on human-written code but skipping AI contributions.
No lifecycle documentation for AI dependencies. Software Composition Analysis (SCA) tracks third-party libraries. Nothing comparable exists for AI models embedded in development tools. You can't answer: Which version of the model? What's the update cadence? Who validates output before merge?
No scope definition for "sensitive assets" in AI contexts. The shift from cardholder data to sensitive assets expands what needs protection. If an AI tool processes code that handles encryption keys, session tokens, or authentication logic, it's touching sensitive assets. But vendors haven't been required to map that exposure.
What the Standard Requires
The Secure SLC Standard v2.0 draft addresses these gaps by requiring vendors to integrate digital tools, including AI, into their secure lifecycle management practices. While the final requirements await publication, the draft's direction is clear:
Vendors must demonstrate secure lifecycle coverage for all tools that contribute to software development. This means AI code assistants, automated test generators, and ML-powered security scanners need the same lifecycle rigor as human developers and traditional tooling.
The standard maintains objective requirements to accommodate vendor maturity levels. A startup using GitHub Copilot and an enterprise with custom-trained models face different implementation paths. The standard won't prescribe specific tools or architectures, but it will require evidence that AI tools are managed within the secure development process.
Alignment with PCI Secure Software v2.0's sensitive assets focus. If your vendor's software handles authentication, cryptographic operations, or authorization decisions, AI tools that generate or modify that code are in scope. The standard will likely require vendors to identify which AI tools touch sensitive asset processing and document how they validate that output.
Action Items for Your Team
Start vendor questionnaire updates now. Don't wait for final publication in the second half of 2026. Add questions to your vendor assessment templates:
- Which AI-powered development tools do you use in your SDLC?
- How do you validate code generated by AI assistants before production deployment?
- What's your process for evaluating security risks in AI tool training data?
- Do you perform SCA-equivalent analysis on AI models embedded in your development environment?
Review your Secure SLC assessments for scope gaps. If you're a software vendor preparing for assessment, inventory your AI tool usage now. Code completion engines, automated refactoring tools, AI-driven security scanners, all of these will need lifecycle documentation. Map which tools touch code paths that process sensitive assets.
Participate in the RFC if you're an eligible stakeholder. The 30-day window closes June 15. If your organization holds PCI SSC stakeholder status, download the draft through the Portal and submit specific feedback. Generic concerns don't move standards development; concrete implementation challenges do.
Don't conflate AI governance with Secure SLC compliance. You might have enterprise AI policies covering data privacy and ethical use. Those don't satisfy Secure SLC requirements. The standard focuses on software security lifecycle integration, how AI tools fit into threat modeling, secure coding, testing, and deployment processes.
Prepare for the maturity flexibility clause. The draft's objective requirements mean you can't copy another vendor's approach wholesale. A payment gateway with 200 engineers needs different AI lifecycle controls than a three-person startup building a fraud scoring API. Document your current maturity level and build a roadmap that matches your risk profile and development scale.
Map AI tool updates to your change management process. When your code completion model updates, treat it like a dependency version change. What changed in the training data? What new code patterns does it suggest? How do you regression test AI-generated contributions? These questions need answers before the standard becomes mandatory.
The v2.0 draft signals where compliance is headed: AI isn't a future consideration, it's a current scope item. The vendors you rely on are already using these tools. The question is whether they're managing them within a secure lifecycle or treating them as invisible assistants outside the validation boundary.
