Skip to main content
Commerce Security Authority
Category: Vulnerability and Software Security

Software Security Framework

Also known as: SSF, PCI Software Security Framework, PCI SSF
Simply put

The Software Security Framework (SSF) is a collection of standards and programs from the PCI Security Standards Council aimed at the secure design and development of payment software. It sets security requirements that software vendors follow to help protect payment data, and it changes how software vendors and the payment software they create are assessed and validated. Assessments are performed by independent organizations qualified by the PCI Security Standards Council.

Formal definition

The PCI Software Security Framework (SSF) is a collection of standards and programs maintained by the PCI Security Standards Council for the secure design and development of payment software. It addresses security requirements intended to protect cardholder data (CHD) and sensitive authentication data handled by payment software, and it represents a shift in how software vendors are assessed and how their payment software is validated. Validation activities under the SSF are conducted by SSF Assessor companies qualified by the PCI Security Standards Council. The SSF is distinct from PCI DSS and from other PCI standards; practitioners should confirm applicable standards, programs, and their current requirements against the currently published SSF documentation. Note that this SSF should not be confused with the unrelated NIST Secure Software Development Framework (SSDF).

Why it matters

Payment software sits directly in the path of cardholder data and sensitive authentication data, so weaknesses in how that software is designed and built can undermine other controls that protect payment data. The PCI Software Security Framework (SSF) matters because it establishes security requirements that software vendors follow, intended to help protect the cardholder data and sensitive authentication data handled by payment software. By defining these expectations for secure design and development, the SSF gives vendors, assessors, and the organizations that rely on payment software a common reference for evaluating software security.

The SSF also represents a shift in how software vendors are assessed and how the payment software they create is validated. Validation activities are performed by independent SSF Assessor companies that have been qualified by the PCI Security Standards Council, which supports consistency in how assessments are conducted. For organizations evaluating or selecting payment software, this structure provides a defined program under which software security can be assessed rather than relying solely on vendor assertions.

Because the SSF is distinct from PCI DSS and from other PCI standards, and because its standards, programs, and requirements can change over time, practitioners should not assume it substitutes for other applicable requirements. Its scope is the security of payment software, and it should not be confused with the unrelated NIST Secure Software Development Framework (SSDF). Confirm applicable standards, programs, and their current requirements against the currently published SSF documentation.

Who it's relevant to

Payment software vendors
Vendors that design and develop payment software are the primary audience for the SSF, since it sets security requirements they follow to help protect cardholder data and sensitive authentication data. The framework changes how these vendors are assessed and how their software is validated, so vendors should confirm current requirements against the published SSF documentation.
SSF Assessors and qualified security organizations
Independent security organizations qualified by the PCI Security Standards Council perform SSF validation activities. These assessors apply the framework's requirements when evaluating vendors and their payment software.
Compliance and security teams selecting payment software
Organizations that process sensitive payment data and rely on third-party payment software can use SSF validation as a defined reference point when evaluating software security. They should treat the SSF as distinct from PCI DSS and other PCI standards, and confirm which standards apply to their environment.
Practitioners distinguishing frameworks
Security professionals should note that the PCI SSF is separate from the unrelated NIST Secure Software Development Framework (SSDF). Confusing the two can lead to applying the wrong requirements, so clarify which framework governs a given control or program.

Inside SSF

Secure Software Standard
One of the two core standards within the PCI Software Security Framework, it defines security requirements and assessment procedures for payment software to help ensure the software adequately protects the integrity and confidentiality of payment transactions and data throughout the software lifecycle. Requirement wording and structure can change between versions, so confirm details against the current published standard.
Secure Software Lifecycle (Secure SLC) Standard
The second core standard within the framework, it addresses the security practices software vendors follow across the development lifecycle rather than validating a single software product. It is intended to promote ongoing secure design, development, and maintenance processes.
Relationship to PA-DSS
The Software Security Framework was introduced by PCI SSC as the successor approach to the Payment Application Data Security Standard (PA-DSS). It is a separate framework from PCI DSS and should not be conflated with it; PCI DSS governs the cardholder data environment, while the SSF governs payment software and vendor development practices.
Validation and listing
Software and vendors assessed against the framework standards may be evaluated by qualified assessors and, where applicable, listed by PCI SSC. Whether use of listed software affects an entity's PCI DSS scope or validation depends on implementation and the current program rules, not on the framework label alone.
Scope of protection
The framework concerns how payment software handles data such as cardholder data, and reinforces that sensitive authentication data (for example full track data, card verification values, and PINs or PIN blocks) must not be retained after authorization even in encrypted form, while some cardholder data may be handled under defined controls.

Common questions

Answers to the questions practitioners most commonly ask about SSF.

Is the Software Security Framework just the new name for PA-DSS?
No. The PCI Software Security Framework (SSF) is a separate program from the Payment Application Data Security Standard (PA-DSS), even though the SSF was introduced by the PCI SSC as the successor approach to PA-DSS. PA-DSS validated payment applications against a fixed control set, while the SSF takes a different structure built around two standards, the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. Because the frameworks differ in scope and validation approach, you should not treat an SSF listing and a PA-DSS listing as interchangeable, and you should confirm current program status, transition timing, and listing details against the PCI SSC's published materials rather than assuming a direct one-to-one replacement.
Does validating software under the SSF make my environment PCI DSS compliant?
No. The SSF governs the security of software products and the practices of software vendors; it does not by itself establish PCI DSS compliance for the merchant, service provider, or environment that deploys the software. PCI DSS applies to how the entity stores, processes, and transmits cardholder data and manages its overall environment, and that assessment is separate from any software validation. Using SSF-validated software may support certain aspects of your security posture, but you still need to validate your environment against the applicable PCI DSS requirements, and you should confirm how any software listing is treated in your assessment against the current published standard and your assessor's guidance.
How do the Secure Software Standard and the Secure Software Lifecycle Standard differ in what they assess?
The two standards under the SSF address different subjects. The Secure Software Standard is oriented toward the security characteristics and controls of a specific software product, while the Secure Software Lifecycle (Secure SLC) Standard is oriented toward the vendor's development processes and practices across the software lifecycle. When deciding which is relevant, identify whether you are evaluating a product's validated security properties or a vendor's ongoing development practices, and confirm the current scope, objectives, and applicability of each standard against the PCI SSC's published documentation.
When choosing payment software, how should I check its SSF status?
Review the software's listing details through the PCI SSC, and confirm what was validated, under which SSF standard, and whether the listing remains current. Because a product listing and a vendor lifecycle qualification cover different things, note which applies to the software you are evaluating. You should also confirm how any listing interacts with your own PCI DSS obligations, since software status does not replace your environment assessment. Verify all program and listing specifics against the PCI SSC's published resources rather than relying on vendor marketing language.
As a software vendor, which SSF standard should I pursue?
That depends on what you are seeking to demonstrate. If you want to validate the security properties of a particular payment software product, the Secure Software Standard is the relevant track; if you want to demonstrate that your development organization follows secure software lifecycle practices, the Secure SLC Standard applies. Some vendors may have reasons to consider both, depending on their products and processes. Determine your objective, then confirm the applicable requirements, assessment process, and any assessor qualification requirements against the PCI SSC's current published materials.
How does the SSF relate to our tokenization, encryption, and data-storage controls under PCI DSS?
The SSF concerns how software is built and validated, not the specific data-protection outcomes you must achieve in your environment. Controls such as tokenization, encryption, truncation, and masking, and the rule that sensitive authentication data must not be stored after authorization, are matters you validate against PCI DSS as it applies to your environment. Software validated under the SSF may implement such functions, but the effect on your scope and compliance depends on your implementation and validation, not on the software's SSF status alone. Confirm these details against the current PCI DSS and consult your assessor for how they apply to your deployment.

Common misconceptions

The Software Security Framework is just a newer name for PCI DSS.
The SSF is a distinct framework from PCI DSS. PCI DSS applies to the cardholder data environment and the entities handling account data, while the SSF applies to payment software and vendor software development practices. They are separate standards with different scopes and validation processes.
The Software Security Framework and PA-DSS are two independent, coexisting programs.
The SSF was introduced as the successor approach to PA-DSS. Practitioners should treat PA-DSS as the earlier program being replaced by the SSF and confirm current program status, transition timelines, and applicability against PCI SSC's current published materials rather than assuming both remain fully active.
Using SSF-validated software automatically makes an environment PCI DSS compliant or removes it from PCI DSS scope.
Validation of software under the SSF does not by itself establish PCI DSS compliance for the entity using it. The effect on scope and validation depends on how the software is implemented and on the current program rules; the entity remains responsible for its own PCI DSS obligations.

Best practices

Confirm which specific standard applies to your case, distinguishing the Secure Software Standard from the Secure SLC Standard and both from PCI DSS, PA-DSS, and other PCI programs.
Verify requirement content, version, and program status against the current published PCI SSC standards rather than relying on fixed requirement numbers or assumed effective dates.
Ensure payment software does not retain sensitive authentication data after authorization, including full track data, card verification values, and PINs or PIN blocks, even when encrypted.
Treat SSF validation and PCI DSS compliance as separate efforts, and document how any listed software is implemented before drawing conclusions about its effect on your PCI DSS scope.
For vendors, apply the Secure SLC practices as ongoing lifecycle processes rather than a one-time product assessment, maintaining secure design and maintenance over time.
Coordinate with qualified assessors and your acquirer or program contacts to confirm current validation, listing, and transition expectations before making compliance decisions.