PCI Secure Software Standard (PCI SSS) v2.0: Key Updates for Modern Development Teams

The Payment Card Industry Security Standards Council has released a major revision of the PCI Secure Software Standard (PCI SSS), moving from v1.2.1 to v2.0. This isn't an incremental update but rather a fundamental restructuring that reflects how software security has evolved in today's interconnected digital landscape.

In this blog post, we’ll detail the major changes to the PCI Secure Software Standard, what this means for your organization, and how to prepare for compliance.

The Removal of Payment Software in PCI SSS

The most striking change is the complete removal of the term "Payment Software" from the standard. This signals a significant philosophical shift from focusing narrowly on payment-specific applications to embracing a broader, more comprehensive approach to software security.

In its place, PCI SSS v2.0 introduces the concept of "Sensitive Assets," which is a framework that encompasses data, functionality, resources, and modes of operation that require protection. This change acknowledges that modern applications are complex ecosystems wherein sensitive information flows through multiple components, not just via traditional payment processing modules.

New Foundation in PCI SSS v2.0: Sensitive Asset Identification

To support this expanded scope, the standard now includes a mandatory companion document called "Sensitive Asset Identification." This document isn't optional reading. It's a required part of the PCI Secure Software Program and provides the following information:

• Additional context for sensitive asset terminology

• Practical examples of what constitutes sensitive assets
• Guidance for identifying sensitive data, functionality, and resources
• Special considerations for EMVCo® 3DS-related data through the PCI 3DS Data Matrix document

PCI SSS v2.0 Structural Transformation: From Control to Security Objectives

The standard has reorganized its requirements into 11 comprehensive Security Objectives (formerly called "Control Objectives"). This restructuring creates a more logical flow that covers:

• Software architecture, composition, and versioning
• Sensitive asset identification and protection
• Storage, retention, and output requirements
• Cryptography, key management, and random number generation
• Threat management and secure deployment

Enhanced SDK Support in PCI SSS v2.0

Perhaps most notably for development teams, PCI SSS v2.0 introduces Module D specifically for Software Development Kits (SDKs). This new module addresses the growing importance of SDKs in modern development and includes enhanced support for an EMVCo® 3DS SDK assessment.

What PCI SSS v2.0 Means for Your Organization

These updates signal the industry's recognition that software security must evolve beyond traditional payment boundaries. To ensure compliance, organizations now need to:

1. Reassess their software inventory using the new sensitive asset framework
2. Understand the expanded scope of what constitutes sensitive functionality
3. Prepare for enhanced SDK assessments if they develop or use software development kits
4. Adapt to new testing methodologies based on documentation review, static analysis, and dynamic analysis

Moving Forward with PCI SSS v2.0 Compliance

The PCI Secure Software Standard v2.0 represents a maturation of software security thinking. By moving away from "payment software" to "sensitive assets," the standard acknowledges that security isn't about protecting just one type of data. It's about creating secure software that can handle any sensitive information appropriately.

The following documents are now available in the PCI SSC Document Library with additional details:

• PCI Secure Software Standard v2.0
• PCI Secure Software Standard – Sensitive Asset Identification (for use with v2.x)
• Summary of Changes from PCI Secure Software Standard v1.2.1 to v2.0
• PCI Secure Software Program Guide (for use with v2.x)
• PCI 3DS Data Matrix, v1.2

Ready to understand how these changes affect your specific development processes? In an upcoming blog post, we'll dive deeper into the 11 new Security Objectives and explore how they replace the previous control framework with a more comprehensive approach to software security.

Stay tuned for our detailed breakdown of the core requirements and implementation strategies. In the meantime, contact us today to learn more and discover additional payment card security insights here:

• Fortifying the Digital Checkout: Payment Page Security in E-Commerce
• Understanding SAQ A Eligibility for E-Commerce PCI Compliance
• The Value of a PCI Readiness Assessment
• PCI DSS Compliance FAQ: Script Management and Integrity Validation for Payment Pages