PCI SSF Validation

The PCI SSF is a framework of software security standards for software developers who create payment applications sold to merchants and service providers. The PCI SSF currently consists of two standards that apply to payment application vendors and payment applications developed for sale to merchants and service providers. The two standards include the:

• Secure Software Lifecycle Standard (Secure SCL)
• Secure Software Standard (SSS)

The first standard, Secure SLC, applies to software developers who create their payment software for resale. It is used to validate the integrity of the quality and governance processes used to develop software by the development companies. Companies which are validated and listed as Secure SLC companies may also be able to self-validate certain minor changes to their own software (i.e., delta changes).

The second standard, SSS, applies to individual applications, much as the PA-DSS did, though the SSS is broader than the PA-DSS regarding the coverage of types of applications. It also entails some additional testing requirements.

No to both questions. The PCI SSF only applies to third-party software vendors who develop and sell payment software to merchants and service providers. It does not apply to software developed by a merchant or service provider for their own internal use.

As a practical matter, yes it will. Some of the major card brands have already issued procedures and rules for merchants requiring any third-party payment software to be validated by the current PCI software standards—either PA-DSS or Secure Software Standard.

Yes it will, as part of a phased-in process starting in early 2021 and ending in 2022. New PA-DSS submissions will not be accepted after June 30, 2021, and the overall PA-DSS program will no longer be supported by the PCI SSC after October 30, 2022. Any existing PA-DSS application listings will expire after their expiration date.

No. Payment applications needing validation under the PCI SSS will need to undergo a separate assessment process under that standard no matter if they were validated under the PA-DSS. There are no grandfather options.

No, your company can elect to only validate applications under the SSS. But while the Secure SLC validation is not required for the individual application validations, it can be very useful if your company is developing multiple payment applications or is planning on expanding its lines into such.

No. The Secure SLC validation only applies at the company level, not per application.

This is probably the single most significant evolution for this framework. Objective-based means that the requirements are oriented towards controls that satisfy an objective—for comparison’s sake, the PA-DSS requirements instead specify a prescriptive, or specific, control against which the application would be tested.

This change means payment software companies will have to understand what controls they have in place to satisfy the requirements, as opposed to meeting a list of predetermined controls. This will initially require some planning and working with your SSF Assessor to understand the best ways to comply and be validated under this new framework.

The good news about this evolved approach is that it will work with newer technologies and software architectures, providing a flexibility for updated control processes while still ensuring solid industry standards for software security.

If your application was already validated under the PA-DSS, you may already have several things in place for this new validation process.   But the SSF has several new requirements and a unique structure of validation, and so any transitioning to the SSF from the PA-DSS will not happen overnight.

Proper planning will help ease this shift, and there are several steps that can be taken to prepare. First, go over the PCI SSC publication “Transitioning from PA-DSS to the PCI Software Security Framework.” Found under the documents section, this provides an excellent overview of the dates and the general elements you will need to know for your transition. Moreover, you will also want to review the Secure SLC Standard and the Secure Software Standard and their supporting documents.

As another part of the planning process, it might also be wise to undertake some sort of readiness assessment with a Secure Software Framework Assessor who is qualified by the PCI SSC for SSF examinations. The PCI SSF features a new lexicon defining the framework in the perspective of the control objectives, and the new Secure SLC and Secure Software Standards do not map exactly to the predecessor PA-DSS requirements due to the objective-based design of their requirements—as such, a readiness assessment with an SSF Assessor could be useful for navigating these new roads of compliance, saving a lot of time and money down the road.