Category: Vulnerability and Software Security

Secure Software Standard

Also known as: PCI Secure Software Standard, Secure Software Standard (SSS)

Simply put

The Secure Software Standard is one of two standards within the PCI Software Security Framework that sets security requirements for companies that make payment software. It focuses on making sure that payment applications are securely designed and managed so that the sensitive data they handle is protected. It is distinct from PCI DSS, which applies to organizations that store, process, or transmit payment data.

Formal definition

The Secure Software Standard, published by the PCI Security Standards Council, is a component of the PCI Software Security Framework (SSF) that defines security requirements for software vendors and developers to ensure the secure design and management of payment software. It addresses controls relating to how payment software protects the data it handles, and is validated separately from PCI DSS assessments of an entity's cardholder data environment. It is complementary to but distinct from the Secure Software Lifecycle (SLC) Standard, which governs a vendor's overall software development processes rather than the security properties of a specific payment software product. The SSF collectively is intended to succeed the earlier PA-DSS program; practitioners should confirm requirement content and version details (for example, changes introduced in the Secure Software Standard v2.0) against the current published standard, as scope, wording, and applicability differ across versions.

Why it matters

Payment software sits at the point where sensitive data is captured, processed, and handled, so weaknesses in how that software is designed can expose cardholder data regardless of how well the surrounding environment is controlled. The Secure Software Standard addresses this by defining security requirements for the product itself, complementing the environment-focused protections of PCI DSS. For organizations that build or rely on payment applications, understanding the standard helps clarify which security responsibilities belong to the software vendor versus the entity operating the cardholder data environment.

The Secure Software Standard is one of two standards within the PCI Software Security Framework (SSF), which is intended to succeed the earlier PA-DSS program. This transition matters because the SSF takes a different approach: the Secure Software Standard focuses on the security properties of a specific payment software product, while the companion Secure Software Lifecycle (SLC) Standard addresses a vendor's overall development processes. Confusing the two, or treating either as equivalent to PCI DSS, can lead to gaps in assurance or misapplied validation efforts.

Because requirement content, wording, and applicability differ across versions—for example, changes introduced with the Secure Software Standard v2.0—practitioners should confirm details against the current published standard rather than assume a fixed set of requirements. The standard affects engineering, product management, compliance, and data governance functions, and is best understood as an ongoing security discipline rather than solely a one-time certification.

Who it's relevant to

Payment software vendors and developers

Vendors that make payment software are the primary audience, as the standard sets requirements for the secure design and management of their products. Engineering and product management teams need to understand how the standard applies to a specific product, and how it differs from the Secure Software Lifecycle (SLC) Standard, which addresses their development processes rather than the product itself.

Compliance and data governance teams

Compliance officers and data governance functions are affected because validation under the Secure Software Standard is separate from PCI DSS assessments. These teams help track which standard governs which control, confirm requirement content against the current published version, and avoid conflating the SSF with PCI DSS or the earlier PA-DSS program it is intended to succeed.

Merchants and entities that use payment software

Organizations that store, process, or transmit payment data remain subject to PCI DSS for their cardholder data environment, but benefit from understanding how a vendor's software has been validated against the Secure Software Standard. This helps clarify the division of security responsibility between the software product and the operating environment.

Assessors and security professionals

Practitioners who evaluate payment software or advise on the PCI Software Security Framework need to distinguish the Secure Software Standard from the SLC Standard and from PCI DSS, and to account for differences in scope, wording, and applicability across versions such as v2.0 when interpreting requirements.

Inside Secure Software Standard

PCI Software Security Framework context

The Secure Software Standard is one of the standards within the PCI Software Security Framework (SSF), which the PCI Security Standards Council introduced as a successor and complement to PA-DSS. It is distinct from PCI DSS, which governs the environment in which payment software operates, and should not be conflated with PA-DSS or with the separate PCI Secure Software Lifecycle (Secure SLC) Standard.

Security objectives for payment software

The standard defines security objectives that payment software is intended to meet, addressing how the software protects sensitive data and resists tampering and attack. It focuses on properties of the software itself rather than on the merchant or service provider environment covered by PCI DSS.

Protection of sensitive data handled by the software

The standard is concerned with how payment software handles account data, including cardholder data such as the PAN and any sensitive authentication data. Sensitive authentication data (for example full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks) must not be retained after authorization, even in encrypted form, a principle that also underlies PCI DSS.

Relationship to the Secure SLC Standard

Within the SSF, the Secure Software Standard addresses the security characteristics of a specific software product, while the Secure Software Lifecycle (Secure SLC) Standard addresses a vendor's ongoing software development and management processes. These are separate but related components that assess different things.

Validation and listing

Payment software may be assessed against the Secure Software Standard and, where validated, listed by the PCI SSC. Validation reflects assessment against the standard's requirements as published; specific requirement wording and structure may change between versions, so readers should confirm details against the current published standard.

Common questions

Answers to the questions practitioners most commonly ask about Secure Software Standard.

Is the Secure Software Standard the same as PA-DSS?

No. The Secure Software Standard is one of the standards within the PCI Software Security Framework and is distinct from PA-DSS. PA-DSS was the older program that governed payment applications, and the Software Security Framework was introduced as a separate approach. Although the Secure Software Standard addresses related subject matter, it is not simply a renamed version of PA-DSS, and you should confirm which program applies to a given product against the current published PCI SSC documentation rather than assuming equivalence.

Does validating software under the Secure Software Standard mean my environment is PCI DSS compliant?

No. The Secure Software Standard governs the security of the software product itself, while PCI DSS governs the environment in which cardholder data is processed, stored, or transmitted. A validated payment software product does not by itself make the surrounding environment compliant, and using validated software does not remove the need to assess your environment against the applicable PCI DSS requirements. The two standards address different scopes and should be treated separately.

How does the Secure Software Standard relate to the other standards in the PCI Software Security Framework?

The PCI Software Security Framework comprises more than one standard, with the Secure Software Standard focused on the security characteristics of the software product and a separate lifecycle-oriented standard addressing the vendor's software development practices. When determining which standard or standards apply to a product or vendor, confirm the current structure and applicability against the PCI SSC published materials rather than assuming a single standard covers all requirements.

What should software be designed to do with sensitive authentication data under this standard?

Software handling payment data should be designed so that sensitive authentication data, such as full track data, card verification values, and PINs or PIN blocks, is not retained after authorization, even in encrypted form. This differs from cardholder data such as the PAN, which may be stored under defined protective controls. Design and validation should reflect this distinction, and you should confirm the specific control expectations against the current published standard.

How do tokenization, encryption, truncation, and masking factor into secure software design?

These are distinct data-protection techniques that transform or reduce data in different ways, and their effect depends on how they are implemented and validated rather than on the label alone. Software design should identify which technique is applied at which point and confirm that its use meets the relevant control objectives. The choice among them should be documented so that reviewers can assess the actual protection provided rather than inferring it from the term used.

How should we confirm which requirements apply, given that wording and numbering change across versions?

Requirement wording, numbering, and applicability can differ between versions of PCI standards, so you should validate against the current published version of the Secure Software Standard and any associated Software Security Framework documentation rather than relying on a fixed requirement number. Confirm the version in effect for your assessment and check the PCI SSC materials for any program-specific guidance that applies to your product type.

Common misconceptions

The Secure Software Standard is just the new name for PA-DSS, so validation carries over directly.

The Secure Software Standard is part of the PCI Software Security Framework, which the PCI SSC introduced as a successor to and replacement for PA-DSS, but it is a distinct standard with its own objectives and requirements. It is not simply a renamed PA-DSS, and organizations should confirm current transition and applicability details against PCI SSC's published materials.

If software is validated against the Secure Software Standard, the merchant or processor using it is automatically PCI DSS compliant.

The Secure Software Standard assesses properties of the software, while PCI DSS assesses the environment in which the software is deployed and operated. Using validated software may support an organization's compliance efforts, but it does not by itself establish PCI DSS compliance, which depends on the surrounding controls and configuration.

The Secure Software Standard and the Secure SLC Standard are the same thing.

They are separate components of the SSF. The Secure Software Standard evaluates the security characteristics of a specific payment software product, whereas the Secure SLC Standard evaluates a vendor's software development lifecycle and processes. An organization may engage with one, the other, or both.

Best practices

Identify explicitly whether a given requirement or claim belongs to the Secure Software Standard, the Secure SLC Standard, PA-DSS, or PCI DSS, since these are separate and address different scopes.

Confirm requirement wording, structure, and applicability against the current published version of the standard rather than assuming fixed content, as these may change between versions.

Ensure payment software handling account data does not retain sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks) after authorization, even when encrypted.

Treat validation against the Secure Software Standard as supporting, not replacing, an organization's PCI DSS obligations for the environment in which the software runs.

When evaluating a vendor, clarify whether they hold product validation under the Secure Software Standard, lifecycle qualification under the Secure SLC Standard, or both, and what each attestation actually covers.

Verify the current validation and listing status of payment software through PCI SSC's published listings rather than relying on marketing labels alone.