PCI PIN vs PCI DSS is a question with a clean answer, and getting it wrong is expensive in both directions. They are two separate standards from the same council, they bind different organisations, they are assessed by differently qualified people, and they run on different clocks.
If you have arrived here because a payment brand or an acquirer has asked you about PIN security and you already hold a PCI DSS attestation, the short version is this: your DSS work does not carry across, and the assumptions you have built up around DSS will actively mislead you.
What this guide covers
- PCI PIN vs PCI DSS: the short answer
- PCI PIN vs PCI DSS: the differences that matter
- Four assumptions PCI DSS gives you that break on PCI PIN
- How scope works in PCI PIN vs PCI DSS
- PCI PIN vs PCI DSS: who actually gets asked
- Where PCI PIN vs PCI DSS overlap in practice
- The cost of getting PCI PIN vs PCI DSS the wrong way round
- Which one applies to you
- Frequently asked questions
- Getting the documentation together

PCI PIN vs PCI DSS: the short answer
PCI DSS governs the protection of cardholder data in the environment that stores, processes or transmits it. PCI PIN Security governs how a PIN and the cryptographic keys that protect it are generated, conveyed, loaded, used, administered and destroyed.
PCI SSC publishes the PIN standard on its own PIN Security page, and describes its intended audience as acquiring institutions and agents responsible for PIN transaction processing on payment card industry participants’ accounts.
A merchant taking card payments is almost certainly in scope for DSS. It is probably not in scope for PIN Security, which is written for acquiring institutions and their agents — processors, key-injection facilities and certificate processors. If you are handling other people’s PIN keys, you are in PIN territory.
PCI PIN vs PCI DSS: the differences that matter
| PCI DSS | PCI PIN Security | |
|---|---|---|
| Current version | v4.0.1 | v3.1, March 2021 |
| Who it binds | Anyone storing, processing or transmitting cardholder data | Acquirers and their agents responsible for PIN transaction processing |
| Assessor | Qualified Security Assessor (QSA) | Qualified PIN Assessor (QPA) |
| Self-assessment route | Yes — SAQs for eligible entities | None |
| Cycle | Commonly annual | Listing expires two years after the assessor’s signature |
| What sets scope | The cardholder data environment | The activities the entity performs |
| Volume thresholds | Merchant levels by transaction volume | None — no threshold at all |
| Dominant test method | Configuration and evidence review | Observation of operations, plus records |
Four assumptions PCI DSS gives you that break on PCI PIN
That there is a self-assessment route. There is not. Every PCI PIN assessment is an onsite engagement by a QPA. The checklists you may see sold as “PIN SAQs” are internal readiness tools, not submissions, and treating one as a submission will waste a cycle.
That the cycle is annual. A PCI PIN listing shows as expired two years after the date the assessor signs Part 3c of the attestation — not two years from submission. PCI SSC does not prorate for a past-dated attestation, so an assessment completed early and submitted late loses the difference.
That volume determines how much applies. DSS has merchant levels. PIN Security has none. Scope is decided by which activities you perform, and if you perform one, its requirements apply in full.
That your QSA can do it. They cannot, unless they also hold the QPA qualification. It is a separate scheme with separate training.
How scope works in PCI PIN vs PCI DSS
Scope is where PCI PIN vs PCI DSS differ most in daily practice. Under DSS you draw a boundary around systems and reduce it by segmentation. Under PIN Security you declare activities, and each activity pulls in a column of requirements.
The PIN standard divides 145 sub-requirements across four columns: 96 for transaction processing operations, 85 for remote key distribution, 105 for certification and registration authority operations, and 94 for key-injection facilities. Perform two activities and you are subject to both columns in full.
Those figures overlap heavily and must not be added together. There are 145 distinct identifiers in total; an entity in two columns satisfies their union, not their sum. Our guide to PCI PIN Security Requirements works through the whole structure, and our PCI DSS scope guide covers the other side.
PCI PIN vs PCI DSS: who actually gets asked
In practice the question arrives from one of three directions, and which one it is tells you how urgent it is.
An acquirer or payment brand asks you directly. This is the common route, and it usually means someone has classified you as an agent performing PIN transaction processing. Establish which activities they think you perform before agreeing to anything, because the answer determines which requirement columns you have signed up to.
A customer asks during procurement. Increasingly, processors and key-injection facilities are asked for a PIN attestation as a condition of onboarding. If you are being asked to appear on PCI SSC’s list of PIN service providers, note that listing is optional and separate from the assessment itself.
You discover it yourself, usually while scoping something else. Injecting keys into devices for a customer is the activity most often performed without anyone realising it brings a whole normative annex with it.
Where PCI PIN vs PCI DSS overlap in practice
The overlap between PCI PIN vs PCI DSS is real but narrower than people expect, and it sits in habits rather than in artefacts. Both standards care about device inventories, about access control around cryptographic material, about logging, and about not writing sensitive values into places they should not be. If you already run a disciplined DSS programme, those habits transfer.
What does not transfer is the evidence. A DSS device inventory does not record the approval listing match that PIN Requirement 1 asks for. DSS access control records do not evidence dual control over a key ceremony. And nothing in a DSS programme produces the artefact a PIN assessor will ask for first: a key inventory that names every secret and private key, its single declared purpose, the form it is held in, and its custodians.
One genuinely shared trap is logging. Both standards care about what ends up in application logs — DSS about cardholder data, PIN about encrypted PIN blocks. If you have already been through a DSS logging clean-up, run the same sweep for PIN blocks, including debug output, database audit tables and any temporary diagnostic logging.
The cost of getting PCI PIN vs PCI DSS the wrong way round
Assuming DSS covers you when PIN applies is the more dangerous error. It leaves key ceremonies unwitnessed, custody trails unrecorded and dual control undesigned — and none of that can be reconstructed afterwards, because the records had to exist at the time. An assessor arriving to find correct procedures with no records behind them will report exactly that.
The opposite error is cheaper but still wasteful. Organisations that perform no PIN activity occasionally build a PIN programme because a customer’s questionnaire mentioned it. If you do not acquire PIN transactions, distribute keys remotely or inject keys, record that determination, have it approved, and send it to whoever asked.
Which one applies to you
To settle PCI PIN vs PCI DSS for your own organisation, work through it in this order:
- Do you store, process or transmit cardholder data? If yes, PCI DSS applies. See our PCI DSS v4.0.1 guide.
- Do you acquire or process PIN-based transactions? If yes, PIN Security’s transaction processing column applies.
- Do you inject keys into devices, for yourself or anyone else? If yes, Normative Annex B applies as well.
- Do you distribute keys remotely using asymmetric techniques, or run a certification authority for it? If yes, Normative Annex A applies as well.
Answering yes to more than one is normal in the PCI PIN vs PCI DSS split, and it means the requirement sets stack rather than replacing each other.
Frequently asked questions
Does a PCI DSS attestation cover PCI PIN?
No. They are separate assessments against separate standards, performed by differently qualified assessors, resulting in separate attestations.
Can the same assessor do both?
Only if they hold both qualifications. QSA and QPA are distinct schemes, and a QSA is not automatically qualified to assess PIN Security.
When is the PCI PIN deadline?
There is not one. PCI SSC does not set a compliance date for PIN Security — the individual payment brands do. Contact the brands you work with. The phase-in dates inside the standard for particular requirements have all now passed.
Is PCI PIN harder than PCI DSS?
Comparing PCI PIN vs PCI DSS on difficulty misses the point: PIN is narrower and deeper. Far fewer requirements apply to far fewer organisations, but the testing is observational — an assessor will want to watch a key ceremony performed normally, and records have to have been produced as the work happened rather than assembled beforehand.
Getting the documentation together
If both standards apply, you need two documentation sets, because the evidence genuinely does not overlap. Our PCI PIN Security Toolkit is 149 editable templates covering all 145 sub-requirements across all four scope columns, including both normative annexes, and structured on the standard’s own seven Control Objectives so a QPA can walk it in the order they already work in.
For the other side of the PCI PIN vs PCI DSS boundary, our PCI DSS documentation guide sets out the evidence a QSA asks for, and PCI PIN scope plus Qualified PIN Assessor cover the PIN side in detail. The two programmes share people and habits; they do not share paperwork.