What is and is not PCI DSS: SSF, P2PE, 3DS, PIN — and where PA-DSS went

PCI DSS is one standard among more than a dozen the PCI Security Standards Council publishes, and it is the only one in the set that assesses your organisation. Everything else — the Software Security Framework, P2PE, PTS, 3DS, PIN Security, card production — governs a thing rather than a company: a piece of software, an encryption solution, a device, a component of the authentication flow. You buy those off a published list. You are assessed against PCI DSS.

PA-DSS was the product standard for payment applications, and it is gone. PCI DSS v4.0.1 says so in a note most readers skip:

“PA-DSS and the related program were retired in October 2022. Refer to the PCI SSC List of Validated Payment Applications for expiry dates for PA-DSS validated applications. Since the expiry date, applications are listed as ‘Acceptable only for Pre-Existing Deployments.’”

So “PA-DSS vs PCI DSS” no longer has a live answer. The question that does is which standard governs which party.

The dividing line is who gets assessed

Only two rows describe something an entity undergoes: PCI DSS and PCI PIN Security. The rest are validations performed on a product by whoever built it, and they reach you as a listing you check rather than an assessment you sit. It is also why a supplier saying “we are PCI certified” is frequently describing a listing rather than an assessment of its own environment.

Where PA-DSS went

Its replacement is the Software Security Framework, which v4.0.1 defines as consisting of “the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard”. One validates the software; the other validates the vendor that builds it. Both produce a PCI SSC listing.

Existing PA-DSS listings did not vanish on retirement — they ran to their expiry dates, after which the application is shown as “Acceptable only for Pre-Existing Deployments”. Whether you may keep using one is, in the standard’s own words, “at the discretion of organizations that manage compliance programs (such as payment brands and acquirers)”.

Which is why PA-DSS is still in circulation. Mastercard’s Security Rules and Procedures — Merchant Edition, dated 6 August 2024, still requires Level 1, 2 and 3 merchants using third-party payment applications to validate that each is listed as compliant with “either the Payment Card Industry Payment Application Data Security Standard (PCI PA-DSS) or the PCI Secure Software Standard, as applicable”. If your acquirer’s onboarding pack still asks for a PA-DSS listing, that is the reason. Check the listing’s expiry date, not merely that a listing exists.

What a listing buys you inside a PCI DSS assessment

Less than the sales deck implies, and the standard is blunt about it: “the use of such software does not by itself make an entity PCI DSS compliant.”

What it does buy is precise. Appendix F of v4.0.1 sets out exactly how far an SSF validation carries into Requirement 6: Requirement 6.2.4 can be considered in place for software developed and maintained in accordance with the Secure Software Standard, and Requirement 6.2 can be considered in place for software developed under the Secure SLC Standard. Requirements 6.3, 6.4 and 6.5 “apply as usual”. The appendix then closes the obvious loophole: this support “applies only to software that is specifically developed and maintained in accordance with the Secure Software Standard or the Secure SLC Standard; it does not extend to other software or system components in scope for Requirement 6”.

Read the other way round, that is the rule for everyone who writes their own code: Requirement 6 “fully applies to bespoke and custom software that has not been developed and maintained in accordance with one of PCI SSC’s Software Security Framework standards” — which puts most Indian merchants and fintechs inside Requirement 6.2 and 6.3.1 in full. And customising listed software hands some of that back: v4.0.1 warns that “a more in-depth review will be required… because the software may no longer be representative of the version that was originally validated”.

P2PE is the largest scope lever on the list and still not a switch. The standard: “A PCI-listed P2PE solution can significantly reduce the number of PCI DSS requirements applicable to a merchant’s cardholder data environment. However, it does not completely remove the applicability of PCI DSS in the merchant environment.” The reduction is conditional, too — SAQ P2PE eligibility requires the merchant to have “implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider”. A listed solution deployed against no PIM is a listed solution you cannot claim. Nor is a listing permanent: solutions on the expired list “are no longer considered ‘validated’ per the P2PE Program Guide”, which changes which SAQ you are eligible for overnight.

3DS answers a different question

Search the whole of PCI DSS v4.0.1 for “3-D Secure” and there are no results. The two standards never meet textually because they govern different components: PCI 3DS Core covers the Access Control Server, Directory Server and 3DS Server; PCI DSS covers wherever account data is stored, processed or transmitted. Under Mastercard’s rules, 3DS Core compliance is required of any service provider performing 3DS functions and strongly recommended for merchants performing them, with a separate standard for the SDKs.

So implementing 3DS changes your authentication and liability position. It does not take a system out of your cardholder data environment and it does not move you to a shorter SAQ. Scope is decided by data flow, not by the authentication protocol in front of it.

PIN and the hardware standards

PTS enters a PCI DSS assessment as an input rather than an obligation. Requirement 3.6.1.2 permits secret and private keys to be stored “within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device”, and 3.7.6 repeats the phrasing. SAQ B-IP and SAQ SPoC eligibility both turn on the device being PCI-listed. You check the Approved PTS Devices list; the manufacturer holds the approval.

PCI PIN Security is the other entity-level standard and it is genuinely separate — PIN encipherment and PIN processing by the parties performing them, assessed under its own programme with its own assessor qualification. Mastercard’s rules refer to an attestation “from a PCI SSC-approved Qualified PIN Assessor (QPA)”. An entity in scope for both is running two programmes on two clocks, not one.

What none of it moves

Buying from a PCI SSC list narrows the questionnaire. It never answers it. Whatever you deploy, these stay with you:

• Scope — decided by your payment flows, not your suppliers’ listings.
• Requirement 6 in full for anything bespoke not built under the SSF.
• Requirement 11.3.2 — external vulnerability scanning at least once every three months by an ASV, where it applies to you.
• Requirement 11.4 — penetration testing against Requirement 11.4: 11.4.2 internal and 11.4.3 external, at least once every 12 months and after any significant infrastructure or application change. No product listing discharges it.
• Requirement 11.4.5 — testing the segmentation your reduced scope depends on; 11.4.6 six-monthly for service providers.
• Requirement 12.8 — managing the third parties whose listings you are relying on.

A listing records what someone else validated, on a date, against a version. Your assessment is about what you did with it. For which document governs what, see the PCI SSC document and version reference.