ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
PCI PIN scope is decided by what your organisation does, not by how much of it you do. There is no transaction threshold, no merchant level, and no light-touch tier — if you perform an in-scope activity, the requirements attached to that activity apply to you in full.
That single sentence is the difference between a PIN programme that is correctly sized and one that either misses a whole normative annex or builds documentation nobody needed. This guide sets out how PCI PIN scope is determined, what the four requirement columns contain, and the arithmetic error that turns 145 requirements into 380.
The standard divides its requirements between three activities: transaction processing operations in the main body, symmetric key distribution using asymmetric techniques in Normative Annex A, and key-injection facilities in Normative Annex B. Annex A itself splits into two sub-annexes, one for remote key distribution operations and one for certification and registration authority operations.
Organisations may be engaged in one or more of these, and are subject to the requirements for every activity in which they engage. PCI PIN scope is therefore additive: performing two activities does not average the two requirement sets, it combines them.
The standard’s applicability appendix maps all 145 sub-requirement identifiers against four columns. Here is what each contains:
| Column | Applies to | Sub-requirements |
|---|---|---|
| Transaction Processing Operations | Acquiring and processing PIN-based transactions | 96 |
| Annex A1 — remote key distribution | Distributing symmetric keys using asymmetric techniques | 85 |
| Annex A2 — certification and registration authority | Operating a CA or RA for that purpose | 105 |
| Annex B — key-injection facilities | Injecting keys into devices | 94 |
Those four figures overlap heavily and must never be added together. Add them and you get 380, a number that does not exist anywhere in the standard.
The standard contains 145 distinct sub-requirement identifiers. 86 of the 145 appear in more than one column, because most of what the standard asks — dual control, split knowledge, key strength, destruction, chain of custody — is asked of everyone who handles keys, regardless of why they handle them. An entity subject to two columns satisfies their union, not their sum.
This matters when you are sizing a programme or briefing a board. An acquirer that also runs a key-injection facility is not facing 190 requirements. It is facing the 145, of which the ones unique to each activity are a small minority: 11 identifiers are scoped to Annex B alone, and 38 to Annex A alone.
Answer four questions, and record the answers rather than holding them in someone’s head:
Question four is the one most often answered wrongly, because key injection is frequently performed as an incidental part of terminal deployment without anyone recognising that it brings an entire normative annex with it.
The Attestation of Compliance asks separately which services were included in the assessment and which were excluded, using five named categories plus an open “other”:
PCI SSC notes that these categories are provided for assistance and are not intended to limit or predetermine what may be in scope. Where a service does not fit one, describe it under “other” rather than forcing it into the nearest box, and confirm the treatment with the applicable payment brand.
Excluded services need a reason. “Not applicable” without an explanation is the sort of gap an assessor opens the conversation with.
Because most identifiers apply everywhere, it is worth knowing what the annex-only ones are — those are the requirements a wrongly answered scoping question makes you miss entirely.
The eleven identifiers unique to Normative Annex B are concentrated in the physical and operational realities of a key-injection facility: injecting only on conforming secure cryptographic devices, documenting the facility architecture and key-management flows, dual control and split knowledge over device loading, the additional controls where a platform exposes clear-text material in ordinary memory, protection against key substitution, separate base derivation keys per terminal type, mutually authenticated channels between distributed facility components, reconciliation against a pre-authorised device inventory, and the physically secure room for injection.
The thirty-eight unique to Normative Annex A are dominated by certification authority operations — the certificate policy and certification practice statement, separation of duties over critical authority functions, hardening of any authority system that is not exclusively offline, audit trail contents and log integrity, authentication management, clock synchronisation, and the three tiers of physical barrier around the authority facility.
None of that appears in the main body. An organisation that runs a certification authority for remote key distribution and never answers question three has not partially complied — it has left an entire requirement set unexamined.
Recording a negative determination is worth as much as recording a positive one, and it is frequently skipped. If you do not distribute keys remotely and do not run an authority, write that down, have it approved, and keep the reasoning.
Assessors ask why a section is absent. A recorded decision answers that in a sentence; a missing folder starts an investigation. The same applies to the excluded services on the attestation, which ask for a brief explanation rather than a blank.
Using a third party moves the work, not the requirement. If a key-injection facility injects your devices, that activity is still within your PCI PIN scope; what changes is that some of the evidence lives with them.
Record which requirements are met by which party and how that is evidenced. Two distinctions matter when you review what they send you. First, is their attestation scoped to the service they actually perform for you, or is it a general assurance? Second, does your contract give you the right to obtain evidence, or only the right to be told everything is fine?
Every site at which an in-scope activity happens is in scope, including sites operated by a third party on your behalf. The attestation asks for the types of facility reviewed and the locations included, so a PCI PIN scope statement that names activities but not places is only half done.
This is also where scope changes creep in unnoticed. Opening a site, closing one, moving an activity to or from a supplier, or taking on a new payment brand relationship all change the answer, which is why the scope statement is worth reviewing on a fixed cadence rather than only before an assessment.
Under PCI DSS you draw a boundary around systems and shrink it through segmentation. Under PCI PIN there is nothing to segment: you declare activities, and each one pulls in its column whole. Our guide to PCI PIN vs PCI DSS covers the wider differences, and PCI DSS scope covers the other model. For the full requirement structure, see PCI PIN Security Requirements.
Where the answer to question three or four is yes, the annex guides set out what you have taken on: remote key distribution for Annex A and key injection facilities for Annex B. Qualified PIN Assessor covers how scope is confirmed on the day.
No. Unlike the merchant levels used with PCI DSS, the PIN standard sets no thresholds. Performing the activity is what brings the requirements.
No — that is the most common PCI PIN scope error. The columns overlap; there are 145 distinct identifiers in total, and an entity in several columns satisfies their union.
No. The activity remains within your scope; the evidence for it moves to your provider, and you need the contractual right to obtain that evidence.
At the back of PCI PIN Security Requirements and Testing Procedures v3.1, free to download from PCI SSC’s document library after accepting their licence agreement.
A defensible PCI PIN scope position is two artefacts: a scope statement that records the activities, the locations and the third parties, and an applicability matrix that turns those answers into the filtered list of requirements you are actually subject to.
Our PCI PIN Security Toolkit ships both. The applicability matrix is seeded with all 145 sub-requirements against all four columns, so you filter rather than guess, and the pack’s 149 templates cover every one of them — including both normative annexes in full.
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026