The PCI Secure Software Framework (SSF) is a set of standards currently made up of the PCI Secure Software Lifecycle (PCI SSLC) and the PCI Secure Software Standard (PCI SSS). Currently, there are two (2) standards under PCI SSF; however, this is dynamic and in the future there may be others that get added to better suit the needs of different software vendors and entities.
The PCI SSLC standard is for companies that would like to test and show their observance to secure development lifecycles.
The PCI SSS is for companies looking to validate a specific piece of software (similar to PA-DSS) and will undergo a rigorous examination including hands-on application testing for the specific product.
Both standards will result in a listing on the PCI SSC website. PCI SSLC will list the company, the products developed under these processes, and what kind of product categories the vendor develops. the PCI SSS will result in a list of the specific products that were validated.
We begin each project with your end goals in mind and to provide preparation for future key project activities. Effective communication and timely coordination of project planning activities are central to our methodology with our clients.
After the agreement is executed, the first phase of the engagement is planning. This is to ensure that Schellman and the Client are fully aware of the what, who, when, why, and how prior to the beginning of testing.
Proper planning is imperative to the success of a project. Schellman has standard processes to cover the important pieces of the engagement.
The kickoff is considered the start of the engagement. If needed, Schellman will schedule a call at the beginning of, or just prior to, the kickoff to finalize any outstanding items. Schellman will be available to the client with any questions.
By including communication prior to starting, Schellman ensures that no last-minute changes to the project or team have occurred and the Client has the plan prior to the testing and on-site visit.
Testing and gathering is the core of the compliance engagement. Due to the planning and understanding processes, this phase will be an accumulation of gathering the evidence needed for the objectives discussed.
Schellman has a no surprise policy and has daily contact with the stakeholders during the testing and gathering activities. Furthermore, Schellman will begin documentation of the draft deliverable to be able to provide it to the Client efficiently after this phase. The Client will have confidence the Schellman team has completed this phase timely and completely.
Schellman’s testing methodology ends with reporting, but the entire assessment is focused on creating a deliverable that is clear, concise, and accurate.
Schellman’s report takes into account the entire process and customizes a report for each Client. The draft report will be provided within 2 weeks of the last day of testing and gathering phase, and a final report will be provided within 30 days. This timing is unsurpassed by the industry.
Have a question? See a list of commonly asked questions below. If you still can't find an answer, contact us!
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:
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.
Joe O'Donnell is a Manager with Schellman mainly dedicated to the PCI and PCI specialty service lines. Before focusing his career on IT auditing services, Joe worked as an Enterprise Operations Computing Analyst where he gained experience in IT systems analysis and data center operations.
Whether it is an ISO 27001 certification, SOC 2 examination or a FedRAMP assessment, companies are often challenged by the need to address customer requirements while ensuring a return on compliance investment.
The most important factor in scoping a potential assessment is understanding what deliverable the recipient (i.e. your customer or partner) is expecting.
Once we have scoped your environment and needs, there are several factors that contribute to Schellman’s pricing: