PCI DSS 3.3.1.3: The personal identification number (PIN) and the PIN block are not stored upon completion
PCI DSS v4.0.1 control 3.3.1.3: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.3.
Requirement 3: Protect Stored Account Data › Section 3.3
The personal identification number (PIN) and the PIN block are not stored upon completion of the authorization process.
Summary
PINs and PIN blocks are never kept once the authorisation is done.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 3.3.1.3 | Examine data sources, to verify that PINs and PIN blocks are not stored upon completion of the authorization process. |
The narrowest of the three in applicability and the most serious when it fails, because a PIN with a PAN is everything needed to withdraw cash. If your environment has no PIN entry it is worth confirming rather than assuming: PIN blocks can appear in message traces even where you never accept a PIN yourself, because they travel in the authorisation message and anything logging that message logs them. The control names both the PIN and the PIN block, which is the encrypted form, so encrypted is not an exemption here: the requirement is that it is not stored, not that it is protected. Where PIN handling is genuine, the surrounding controls are stricter than PCI DSS alone and PIN security standards apply as well.
What to prepare
- Confirmation of whether PIN data enters your environment at all.
- Message traces and terminal or HSM logs, if it does.
- Evidence of the search, since the procedure examines data sources.
- The applicability decision, written down either way.
How to implement it
1. Establish applicability deliberately and record it. "We do not take PINs" is a fine answer and a much better one when it has been checked against the message traces.
2. Check terminal and HSM diagnostic output. It is the place a PIN block appears without anybody deciding to store one.
3. Do not treat encryption as compliance. A stored PIN block fails this control even though it is encrypted, because the requirement is about storage.
4. Escalate any find. A stored PIN is materially more serious than the other two elements and warrants incident handling rather than cleanup.
Where this commonly fails
- Assumed not applicable without checking the authorisation message traces.
- PIN blocks in terminal debug logs, stored because they are encrypted.
- Diagnostic captures taken during an incident and never deleted.
- Treating it as equivalent in severity to the other two elements.
Related controls
Others in section 3.3:
| Control | What it requires |
|---|---|
| 3.3.1 | SAD is not stored after authorization, even if encrypted |
| 3.3.1.1 | The full contents of any track are not stored upon completion of the authorization process |
| 3.3.1.2 | The card verification code is not stored upon completion of the authorization process |
| 3.3.2 | SAD that is stored electronically prior to completion of authorization is encrypted using… |
| 3.3.3 | Issuers: Any storage of sensitive authentication data… |
← 3.3.1.2 · All controls · 3.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.