Category: PCI Secure Software

The PCI Security Standards Council (PCI SSC) has published the Payment Card Industry Key Management and Operations (PCI KMO)™ Standard v1.0, introducing a unified framework for organizations that operate and manage systems using cryptographic keys to protect account data.

Published on 14 September 2026, the standard brings key-management security requirements, testing procedures and guidance into a common structure. Its initial focus is on the secure management of PIN and Point-to-Point Encryption (P2PE) keys, while also addressing modern operating models such as cloud-based and remote Hardware Security Modules (HSMs). For financial institutions, payment processors, service providers and organizations supporting cryptographic environments, PCI KMO is more than another security publication. It creates an opportunity to examine whether key-management responsibilities, processes and supporting evidence remain effective across the entire cryptographic key lifecycle.

What Is the PCI KMO Standard?

The PCI KMO Standard defines security and testing requirements for entities involved in operating and managing systems that use cryptographic keys to protect account data.

Its scope follows a key throughout its lifecycle – from secure generation and distribution to storage, use, rotation, replacement, archival where applicable and final destruction. It also considers the procedures, systems, people and equipment involved in managing those keys.

This lifecycle view matters because strong cryptography alone does not guarantee strong security. A secure algorithm can still be undermined by weak access control, unclear custody, poor key-component handling, inadequate monitoring or incomplete destruction records. PCI KMO therefore places the operation of key management within a structured, assessable control environment.

Why Has PCI SSC Introduced KMO?

Key-management requirements have historically existed across different PCI standards and programs. Organizations working with multiple payment-security use cases could consequently encounter overlapping requirements, separate validation activities and different forms of evidence. PCI KMO is intended to become a single source of requirements for key-management operations across relevant PCI programs. The initial release consolidates, aligns and updates requirements related to PIN and P2PE keys and their associated data types.

This structure is designed around an “assess once, use many” approach. Subject to the applicable program rules and scope, one PCI KMO assessment may validate key-management security for both PIN and P2PE key types. An eligible KMO Listing may also be referenced by a PCI P2PE implementation where appropriate.

The practical objective is not simply to reduce duplication. A common framework can help organizations establish clearer ownership, more consistent control implementation and reusable assessment evidence across supported payment environments.

Key Areas Covered by PCI KMO v1.0

1. The Complete Cryptographic Key Lifecycle

PCI KMO covers the stages through which cryptographic keys pass—from generation to destruction. Organizations should be able to demonstrate that controls remain effective at every stage and that keys cannot be exposed, substituted, misused or retained beyond their authorized purpose.

This requires more than technical configuration. Policies, operating procedures, approval records, access logs, key inventories, custody arrangements and destruction evidence may all contribute to an effective control environment.

2. PIN and P2PE Key Environments

The initial version focuses on requirements for the secure handling of PIN and P2PE keys and data types. This is particularly relevant for entities that manage key-management services supporting payment acceptance, processing, encryption or PIN-security operations.

Organizations whose environments support both areas should examine whether controls are implemented consistently across teams, systems and locations—and whether their evidence can support the consolidated assessment model.

3. Cloud-Based and Remote HSMs

Cryptographic infrastructure increasingly extends beyond locally managed hardware. PCI KMO directly addresses cloud-based and remote HSMs, recognizing that key-management operations may depend on shared-responsibility models, remotely administered services and distributed infrastructure.

This makes accountability especially important. Organizations need clarity over who configures the HSM, who administers access, where keys and backups reside, how privileged activities are monitored, how responsibilities are divided between the customer and provider, and what evidence is available for assessment.

4. Alignment with PCI HSM v5

PCI SSC states that the KMO Standard has been developed in alignment with the recently published PCI HSM v5 requirements. The relationship is significant: HSM requirements address the security capabilities of the device, while KMO focuses on how keys and key-management systems are operated and managed.

A secure device must still be supported by secure procedures, trusted roles, access governance and effective lifecycle controls.

5. A Modular Framework

PCI KMO is designed to support different key data types and operational models through a modular structure. Its initial application centres on PIN and P2PE, while PCI SSC has indicated that future revisions may address additional needs, including data types covered by the PCI Card Production Standards.

Organizations should therefore treat PCI KMO as an evolving part of the wider PCI ecosystem rather than a one-time compliance exercise.

Who Should Pay Attention to PCI KMO?

The standard is particularly relevant to organizations involved in the management or operation of cryptographic keys used to secure payment account data, including:

• Financial institutions and payment processors
• Acquirers, issuers and payment service providers
• Entities operating PIN-security environments
• P2PE solution providers and supporting service providers
• Key-management service providers
• Organizations using cloud-hosted or remotely managed HSM services
• Technology providers supporting cryptographic operations
• Security, compliance, risk and internal-audit teams responsible for payment environments

Applicability should be determined through careful scoping. Simply using encryption does not, by itself, establish the exact PCI KMO assessment obligation. The types of keys handled, services performed, contractual responsibilities, system boundaries and relationships with other PCI programs all need to be understood.

What Should Organizations Do Now?

PCI KMO is new, but organizations do not need to wait before improving readiness. A structured review can begin with the following actions.

• Identify Relevant Keys and Services –  Build or validate an inventory of cryptographic keys, their purposes, associated data types, custodians, locations, supporting systems and service providers. Map which operations support PIN, P2PE or other payment-security use cases.
• Review the Entire Key Lifecycle –  Assess how keys are generated, distributed, loaded, stored, used, rotated, revoked and destroyed. Look for stages where ownership is unclear, evidence is incomplete or manual activity creates avoidable risk.
• Clarify Roles and Segregation of Duties –  Document who can authorize, administer, access and monitor key-management activities. Confirm that sensitive operations use appropriate dual control, split knowledge or other safeguards where required.
• Examine Cloud and Remote-HSM Responsibilities –  Where third-party or cloud services are involved, review contracts, responsibility matrices, administrative-access models, data-location considerations, incident responsibilities and the availability of assessment evidence.
• Compare Existing Controls with PCI KMO Requirements –  Organizations already working with PCI PIN or PCI P2PE may have many relevant controls in place. A focused comparison can identify what is reusable, what needs to be aligned and what new evidence or procedures may be required.
• Monitor the PCI KMO Program –  PCI SSC has released the PCI KMO Requirements and Test Procedures v1.0 and the associated Program Guide. At the time of publication, PCI SSC stated that the KMO Assessor Qualification Requirements were expected soon. Organizations planning a formal assessment should monitor official PCI SSC updates and engage only appropriately qualified KMO assessors when validation is required.

How PCI KMO Can Strengthen Payment-Security Governance

The value of PCI KMO extends beyond assessment efficiency. A consolidated framework can help organizations reduce fragmented ownership of cryptographic controls, improve visibility into key-management dependencies and apply more consistent governance across hybrid infrastructure. It can also encourage better conversations between security, infrastructure, cloud, payment operations, risk, compliance and third-party-management teams. Ask a simple question: Could your organization trace every high-value payment key to its owner, purpose, location, authorized users, last rotation and approved destruction method?

If the answer requires several teams and disconnected records, PCI KMO readiness may be an opportunity to improve the operating model – not merely prepare documentation.

Preparing for PCI KMO with QRC

QRC Assurance And Solutions is a PCI SSC Qualified Security Assessor Company with experience across PCI PIN, PCI P2PE and other PCI security standards. QRC is closely tracking the evolving PCI KMO program and its assessor requirements. Organizations can begin by understanding the applicability of the new standard, identifying relevant cryptographic services and reviewing their existing key-management controls against the published framework.

Is your organization ready to evaluate how PCI KMO v1.0 may affect its payment-security environment?

Connect with QRC to discuss your current cryptographic key-management landscape and identify practical readiness priorities.

Frequently Asked Questions

1. What does PCI KMO stand for?
   PCI KMO stands for Payment Card Industry Key Management and Operations. It is a PCI SSC standard covering the secure operation and management of systems that use cryptographic keys to protect account data.
2. Which key types are initially covered by PCI KMO v1.0?
   The initial focus is on the secure handling of PIN and P2PE keys and their related data types. PCI SSC may extend future revisions to address other specific data types and programs.
3. Does PCI KMO address cloud-based key management?
   Yes. PCI SSC states that the standard directly addresses cloud-based and remote HSMs and aligns with PCI HSM v5 requirements.
4. Can a single PCI KMO assessment support more than one PCI program?
   PCI KMO is designed around an “assess once, use many” approach. A single assessment may validate security for both PIN and P2PE key types, and an applicable KMO Listing may be referenced by a PCI P2PE implementation where appropriate. Exact use depends on program requirements and confirmed scope.
5. Is every organization using encryption required to undergo a PCI KMO assessment?
   Not necessarily. Applicability depends on the cryptographic services performed, keys and data types handled, system scope, organizational responsibilities and relevant PCI program requirements. Organizations should conduct a formal scoping review before drawing conclusions.

Official References

• PCI SSC: Just Published—PCI Key Management and Operations (KMO)™ Standard v1.0
• PCI SSC Standards and Program Resources

The PCI Security Standards Council (PCI SSC) released version 2.0 of the PCI Secure Software Standard in January 2026, marking a major revision from the previous v1.2.1. If your organization develops, assesses, or relies on payment software, this update carries significant implications. Here’s a breakdown of what’s changed and what you need to know.

A Major Revision – Not A Minor Update

First and foremost, the PCI SSC has emphasized that this is a major revision. Unlike incremental updates, there is no definitive one-to-one mapping between v1.2.1 and v2.0. Organizations should approach this as a significant rethink of the standard’s structure, language, and scope – not simply an updated checklist.

Key Terminology Changes

One of the most immediately noticeable shifts is the language used throughout the standard. The term “Payment Software” has been removed entirely. In its place, the standard now revolves around the concept of “Sensitive Assets.” This broader framing better captures the range of data, resources, and functionality that software must protect. Several related glossary terms have also been updated:

• “Critical Asset” is now “Sensitive Asset” (and has been rewritten)
• “Sensitive Function” is now “Sensitive Functionality” (and has been rewritten)
• “Sensitive Data” and “Sensitive Resource” definitions have both been revised
• A new term, “Strong Authentication,” has been introduced

The glossary itself has been moved in-house: v2.0 includes a new Appendix A that supersedes the previously external SSF Glossary document, making all defined terms available within the standard itself. Additionally, “Control Objectives” have been renamed “Security Objectives” throughout the document.

New Companion Document: Sensitive Asset Identification

A brand-new external companion document has been introduced alongside v2.0 – the Sensitive Asset Identification document. This is not optional reading: it is a mandatory companion to the standard and forms part of its program.

The document provides additional context and examples for understanding Sensitive Assets, Sensitive Data, Sensitive Functionality, and Sensitive Resources. For vendors working with EMVCo 3DS-related data, the standard also relies on the PCI 3DS Data Matrix document.

Restructured Test Requirements And Methodology

All test requirements have been essentially rewritten in v2.0. The new approach is structured around three core methods:

1. Documentation Review
2. Static Analysis
3. Dynamic Analysis

Additional new sections include Software Testing, Provision of Source Code, Technical Constraints, and Technical FAQs – the last of which mirrors language from existing PCI Technical FAQ documents.

Overhauled Core Requirements

The core section has been retitled “Core – All Software” to emphasize that these requirements apply universally to all software assessed under the standard. The eleven Security Objectives now cover:

• Security Objective 1: Software Architecture, Composition, and Versioning – including requirements for Bill of Materials (BOM), versioning practices, and the use of wildcards.
• Security Objective 2: Sensitive Asset Identification – relies on the new companion document covers identifying Sensitive Data, Sensitive Resources, Sensitive Functionality, and Sensitive Modes of Operation.
• Security Objective 3: Sensitive Asset Storage and Retention
• Security Objective 4: Sensitive Modes of Operation – applies only when a Sensitive Mode of Operation is present introduces “Strong Authentication.”
• Security Objective 5: Sensitive Asset Protection – including the software design itself as a sensitive asset, and formalizing the concept of “anomalous behavior.”
• Security Objective 6: Sensitive Asset Output – formalizes secure channel requirements.
• Security Objective 7: Random Numbers – covers both leveraging an external RNG and implementing one within the software.
• Security Objective 8: Key Management
• Security Objective 9: Cryptography (a single encompassing requirement for cases not covered elsewhere)
• Security Objective 10: Threats and Vulnerabilities
• Security Objective 11: Secure Deployment and Management – includes implementation guidance and software versioning.

Changes To Modules : Modules are additional requirements that apply on top of the Core – All Software section, based on defined criteria.

• Module A (Account Data Protection): Requirements have been revised to focus specifically on PAN and SAD in relation to PCI DSS.
• Module B (formerly Terminal Software Requirements, now POI Device Software): The module has been retitled and its requirements refined and reduced. Several requirements previously in Module B have been absorbed into the Core – All Software section. SRED requirements have also been revised.
• Module C (formerly Web Software Requirements, now Publicly-accessible Software): The module has been retitled to better reflect its intent. Several requirements from the old C.1 section have been moved to the Core section. Requirements C.1.5 and C.1.6 have been removed, as they are now covered by the PCI Secure SLC Standard.
• Module D (NEW – Software Development Kits): This is an entirely new module. v2.0 is now better suited to accommodate the assessment of SDKs, including EMVCo 3DS SDKs. Module D introduces a new set of objectives and requirements specifically for this category.

Structural And Administrative Changes

Several structural changes have been made to align v2.0 more closely with the broader PCI Standards framework:

• A new “Sensitive Assets” section has been added to the introduction.
• The “Stakeholder Roles and Responsibilities” section has been removed from the standard and relocated to the PCI Secure Software Program Guide.
• The “Scope of Security Requirements” section has been removed entirely.
• Related Publications have been moved to a new Appendix B.
• A new Appendix C covers Technical References.
• SLC-related requirements have been removed from this standard, as they are now covered under the PCI Secure SLC Standard.
• The standard now relies on “Strong Cryptography” as the baseline for cryptographic requirements, replacing the previous “Effective Key Strength” framework.

What This Means For Your Organization

Whether you are a software vendor seeking or maintaining certification, an assessor reviewing compliance, or a payment brand evaluating software, v2.0 represents a meaningful shift. The expanded focus on Sensitive Assets (rather than Payment Software alone) broadens the standard’s applicability. The introduction of Module D makes it relevant to SDK developers for the first time. And the comprehensive rewrite of test requirements means existing assessment processes will need to be revisited.

Organizations currently certified or in the process of certification under v1.2.1 should review the full v2.0 standard and the new Sensitive Asset Identification companion document to understand how requirements map (or don’t map) to their current implementations.

The PCI SSC has made clear that this version is designed to be more structured, more broadly applicable, and better aligned with the evolving software security landscape – including the growing role of SDKs, third-party components, and complex software supply chains.

For the full standard and companion documents, visit the PCI Security Standards Council website at PCIsecuritystandards.org.

Need Help Navigating PCI Secure Software Standard V2.0?

At QRC Assurance and Solutions, we understand that major standard revisions can be complex to interpret and even more challenging to implement. Whether you are a software vendor preparing for assessment under v2.0, an organization reviewing your current certification status, or a development team working through the new Sensitive Asset framework for the first time – our team of qualified security experts is here to guide you every step of the way.

Our services include:

• Gap assessments against PCI Secure Software Standard v2.0
• Pre-assessment readiness reviews
• Support for Module D (SDK) assessments – new to v2.0
• Guidance on the mandatory Sensitive Asset Identification companion document
• End-to-end PCI SSF assessment and certification support

Don’t let a major revision catch your organization off guard. Get ahead of the changes with expert support from a team that lives and breathes payment security compliance. Contact us today to schedule a consultation or learn more about how QRC Assurance and Solutions can help you achieve and maintain compliance with confidence.

Visit us at: www.qrcsolutionz.com | Email us at: connect@qrcsolutionz.com

The PCI Software Security Framework (SSF) marks a significant shift in how payment software should be designed, developed, and secured across its lifecycle. At the heart of this framework is the Secure Software Standard (SSS), a set of robust security objectives that go beyond launch-time checks to ensure ongoing protection of payment software.

But for many payment software providers, implementing PCI SSS can be a daunting task. The standard introduces more rigorous requirements, continuous accountability, and deeper technical oversight than its predecessor, PCI PA-DSS.

In this blog, we’ll break down the key challenges organizations face in implementing PCI SSS-and, most importantly, how to overcome them through strategic alignment, modern tooling, and security-driven development practices.

What is the PCI Secure Software Standard (SSS)?

The PCI SSS applies to payment software that stores, processes, or transmits cardholder data-or directly supports those functions. It’s a component of the PCI Software Security Framework, which replaces the legacy PA-DSS program.

The SSS emphasizes:

• Secure software architecture
• Threat modeling and risk identification
• Secure coding practices
• Testing and validation
• Software integrity and authenticity
• Governance of updates, patches, and support
• Security controls around data protection and access

Unlike the checklist-based, point-in-time PA-DSS, the SSS promotes a continuous, outcome-focused approach to software security.

Top Challenges in PCI SSS Implementation (and How to Overcome Them)

Understanding the Shift from PA-DSS to SSS

Challenge: Familiarity with PA-DSS makes it hard for teams to grasp the broader and deeper scope of SSS.

Solution:

• Conduct a detailed gap analysis between PA-DSS and SSS.
• Engage a PCI SSF Qualified Software Assessor (QSA) early to clarify scope.
• Update documentation, security architecture, and training materials to align with SSS objectives.

Lack of Integrated Secure SDLC Practices

Challenge: Many organizations treat security as an afterthought in QA or pre-release.

Solution:

• Adopt DevSecOps principles with embedded threat modelling, SAST, DAST, and secure code reviews.
• Define security gates at each SDLC phase.
• Train developers in secure coding and software composition analysis (SCA).
• Automate evidence collection (e.g., scan reports, logs, test results).

Insufficient Threat Modeling and Risk Analysis

Challenge: Teams struggle with identifying when, how, and by whom threat modeling should be performed.

Solution:

• Use lightweight frameworks like STRIDE or DREAD during design sprints.
• Integrate threat modeling into feature planning and architecture reviews.
• Assign threat modeling responsibilities to security champions within dev teams.
• Maintain a threat register to track and update known risks.

Software Integrity and Tamper Resistance

Challenge: Lack of signing, verification, or integrity checks in cloud-native and distributed environments.

Solution:

• Implement code signing for all builds and releases.
• Use hash verification and digital signatures within CI/CD pipelines.
• Scan containers and serverless functions for drift or tampering.
• Integrate runtime protection tools to detect anomalies and injection attacks.

Documentation and Evidence Collection

Challenge: Incomplete, decentralized documentation that fails to meet QSA assessment needs.

Solution:

• Maintain a single source of truth for all security policies, procedures, and artifacts.
• Automate the generation of logs, scan reports, deployment approvals, and incident tracking.
• Use GRC platforms or compliance tools to map controls to SSS objectives.
• Prepare an assessment-ready evidence pack before engaging a QSA.

Managing Dependencies and Third-Party Components

Challenge: Limited visibility into the security posture of open-source libraries and vendor components.

Solution:

• Use Software Composition Analysis (SCA) tools (e.g., Snyk, Black Duck, OWASP Dependency-Check).
• Establish policies for approved components and update cycles.
• Maintain a Software Bill of Materials (SBOM) to track third-party usage.
• Automate alerts for new CVEs affecting your software stack.

Best Practices for a Successful PCI SSS Journey

• Start early: Involve security, compliance, and development teams from the planning stage.
• Work with an assessor: A PCI SSF QSA can offer early feedback and help avoid rework.
• Automate where possible: Integrate evidence collection, testing, and documentation into your CI/CD pipeline.
• Train continuously: Keep your teams updated on secure development and compliance requirements.
• Iterate and adapt: Reassess your posture quarterly and embed SSS into your release lifecycle.

Closing Thoughts: Make PCI SSS a Catalyst, Not a Constraint

PCI SSS isn’t just about passing an audit-it’s about embedding security into your engineering culture and delivering trusted, resilient software. While it demands more than PA-DSS, it reflects modern software practices and provides a foundation for long-term product security.

When approached thoughtfully-with the right tools, mindset, and guidance-PCI SSS can be a driver of innovation, trust, and organizational maturity. Treat compliance as a foundation, not a finish line.

Need help implementing PCI SSS?

QRC Assurance provides hands-on advisory and readiness assessments tailored to your architecture, SDLC maturity, and business requirements.

connect@qrcsolutionz.com | www.qrcsolutionz.com

The latest security software standard, PCI SSF Secure Software Program v1.2, is designed to protect businesses from data breaches and cyberattacks. This program is the first of its kind, and it has been designed with the latest technology and security protocols to ensure that businesses can keep their customer’s data safe and secure. It is essential for companies to understand the new standard and how it works if they are to successfully protect their customers and their data.

Overview of the new program

The Payment Card Industry Security Standards Council (PCI SSC) has released its latest version of the Secure Software Program v1.2, which sets out updated security requirements for software that stores, processes, or transmits payment card data. This new update introduces New Security Requirements Module for Web Software and includes a number of changes aimed at strengthening the security of software used to process payments. The Web Software Module is a set of supplemental security requirements to address the most common security issues related to the use of internet-accessible payment technologies.

New High Level Requirement areas in the Web Software Module

The new PCI SSC Secure Software Program v1.2 offers a range of benefits, including:

• Documenting and tracking the use of open-source and third-party software components and APIs in payment software
• Controlling access to payment software web APIs and other critical assets
• Mitigating common web attacks
• Protecting communications between web-based payment software components

The PCI SSF is designed to provide a consistent, comprehensive set of guidelines for developing secure software, as well as a continuous improvement path to ensure the security of payment systems. The module is designed to help organizations identify and prioritize risk mitigation strategies, as well as implement software security best practices. It also includes resources such as prescriptive requirements, and informative guidance to help organizations secure their payment systems. With the Web Software Module, PCI SSC is providing the industry with an expanded framework for a stronger and more consistent approach to secure software development for the payments industry.

The new standard version 1.2 provides security guidance to software vendors and developers on how to protect software from malicious attacks, cyber threats, and other vulnerabilities. The new version includes updated recommendations on security best practices, such as secure development lifecycle processes, code review and testing, secure deployment and operations. The council has updated the document library with the revised:

• PCI Secure Software Standard v1.2
• Summary of Changes from PCI Secure Software Standard v1.1 to v1.2,
• PCI Secure Software Program Guide v1.2
• PCI Software Security Framework Qualification Requirements for Assessors v1.2
• PCI Software Security Framework Glossary v1.2
• PCI Software Security Framework Frequently Asked Questions for v1.2 Release

In conclusion, the new standard released by the PCI SSC Secure Software Program v1.2 is an important step forward in data security and a great opportunity for organizations to update their security systems and ensure the secure and efficient transmission of information. It is important to understand the changes and how they will affect your organization’s security. With the proper knowledge and implementation, you can make sure your organization is compliant and up to date with the latest data security standards.

For more details : https://www.pcisecuritystandards.org/about_us/press_releases/pci-security-standards-council-publishes-version-1-2-of-the-secure-software-standard-and-program/

The Payment Card Industry Software Security Framework, introduced by PCI SSC, is a relatively new framework that will go into effect in October 2022. The PCI SSF is a collection of various codes and tools created to safeguard payment software. It’s a framework that was created to take the position of the Payment Application Data Security Standard (PA-DSS) with more up-to-date standards that support various payment software types, technologies, and development techniques.

The recent outbreak of Corona virus has hampered the operations across the globe affecting all economies and nations alike. The lockdown has bought few industries to a standstill while others are still managing to continue their day to operations via virtual means.

But even in uncertain times like these, PCI DSS compliance is a requirement that can’t be dropped. PCI SSC council has recognized these unusual circumstances and understands situation where onsite assessments won’t be possible owing to restricted travel entry. In lieu of the individual health and safety, PCI SSC has emphasized on  remote assessments providing guidance to the assessor community

Troy Leach, Sr VP, Engagement Officer PCI SSC discussed the necessary guidelines to be followed by assessor at these times.

Remote Assessments

Since, assessors may not be able to travel to an onsite location for assessment, they are advised to conduct remote assessments that ensures any validations being performed remotely are under necessary level of assurances of implementation and that all the requirements are met before signing off their ‘in place’ clause in the report of compliance

Maintaining the Integrity of Assessment

Necessary measures are recommended to be taken by the assessor to ensure that integrity of the assessment is maintained even in remote scenarios, ascertaining that personnel and system components under examine are same as in onsite assessment.

Report on Compliance must include the mode of assessment conducted and how an equivalent level of assurance was attained during the assessment, retaining all the relevant evidence as a part of assessment paperwork.

Local Qualified Assessor resources can be engaged for assistance, in case the primary QSA is unable to travel onsite. An approved subcontractor can be engaged in accordance to the QSA program requirements. And all the measures should be taken to ensure that the results of the assessment are in line with the onsite assessment, even though certain tests are meant to be done only in person and delay in such scenarios is unavoidable.

All the necessary queries about the assessment completion and how it may impact the compliance should be addresses to the acquirer of the applicable payment brands. The general guidance for the QSAs around online and remote assessments are available in FAQ 1455. Check it out  here.

QRC requests all our community members to stay safe, we put our clients in the centre of every key decision that is made. And assure in doing our best in implementing all business continuity measures until the pandemic is contained in scale and scope.

Over the years, the payment card industry has seen an outburst of incidents in card data theft and security incidents. Reporting as such have become so common, that it has ceded to come as a surprise to the masses. While innovations in the payment solutions have grown rapidly in the recent years, concerns about the same have seen a similar fate. Adhering to this need, back in 2014, the PCI Council released a guidance document titled “Information Supplement: Best Practices for Maintaining PCI DSS Compliance”, that outlined guidance for preserving the PCI DSS Compliance.

PCI SSF: New Standards for Software Security

With growing software innovations and the growing software security incidents, the PCI Security council, adhering to this need, decided to form a framework defining guidance and regulations for secure software payment process (PCI SS) and secure software lifecycle development (PCI SLC) that catered to securing the entire software development lifecycle process

Earlier this year, the PCI Software Security Council, published two stated standards i.e.  PCI SSS  and  PCI SLC  as a part of new  PCI Software Security Framework (PCI SSF).  The new framework takes into account the multiple aspects of software development phases required for developing and maintenance of advanced paymentapplications.

The major components are stated as below, each of the components stands as a separate standard with two approach to software security:

i.  PCI Secure Software Standard v1.0  that defines the multiple security requirements and assessment procedures to ensure the integrity and confidentiality of payment transactions and data.

ii. PCI Secure SLC Standard (Secure SLC) v1.0that defines the security and assessment requirements for the software vendors to be followed and validated through the entire process of creating a payment software through its complete development life-cycle. This ensure that best practices in place in the development of the application.

A third component of the new standards, i.e. the  Validation Framework  is expected to be released in the mid-2019, and is speculated to include details for validation program for software vendors and qualification program for assessors.

Though the program for validation framework is optional, it will be highly encouraged as it puts the software vendor on the PCIL SSC’s list of SSLC Qualified Payment Software Vendors., The vendors qualified under this program can self-attest and perform delta assessments, reducing the QSAinvolvement.

Use of applications validated under PCI SSF standards, will not make an entity PCI DSS compliant or qualifies for compliance under any other PCI standard. Upon successful completion of validation under  PCI SLC,  the software vendors will be added to the List of SSLC-Qualified Payment Software Vendors on the PCI SSC website.­­­

When PA-DSS was developed, software development process followed a very traditional approach, this approach for the software development has significantly changed over the years due to availabilityof multiple development platforms and methodologies. Hence, it is vital to the development of payment solutions to follow a secure methodology and procedure to avoid any security fallout.

New PCI SSF standards, address to this need, by specifying secure key requirement of both the payment procedures as well as the entire application development lifecycle of the solution maintaining software resiliency, addressing robust security design and development practices.

Transition from PA-DSS to PCI SSF

The council had stated that all the materials related to PCI SSF standards i.e. the program guide, the assessor qualification, reporting templates are scheduled to mid-2019.

A three-year adaptation period has been specified as per the validation program, and all the applications will continue to be governed under PA-DSS until its expiration in 2022. At the end of the expiration period, all the PA-DSS applications will be moved to a Pre-Existing Deployments list., and any further updates will need to be assessed under the PCI SSF framework.

Should Vendors Continue with PA-DSS or wait until PCI-SSF
Assessments under PCI SSF will only be initiated until mid-2019, hence application vendors are encouraged to continue to submit changes to currently validated applications via the PA-DSS program.  In case, vendors have already initiated assignments under PA DSS, the council encourages them to complete it under the same.

PCI SSF that will begin in Q3 2019 will have a three-year validation period, thus bringing up the expiry of PA-DSS almost the same time. Components of PA-DSS will then be adapted into PCI SSF in future development and updates in the standard.