PCI DSS 3.4.1: PAN is masked when displayed
PCI DSS v4.0.1 control 3.4.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 3.4.
Requirement 3: Protect Stored Account Data › Section 3.4
PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
Summary
Show at most the first six and last four digits, and only to people whose job needs more.
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.4.1.a | Examine documented policies and procedures for masking the display of PANs to verify: • A list of roles that need access to more than the BIN and last four digits of the PAN (includes full PAN) is documented, together with a legitimate business need for each role to have such access. • PAN is masked when displayed such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN. • All roles not specifically authorized to see the full PAN must only see masked PANs. |
| 3.4.1.b | Examine system configurations to verify that full PAN is only displayed for roles with a documented business need, and that PAN is masked for all other requests. |
| 3.4.1.c | Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displayed, and that only those with a legitimate business need are able to see more than the BIN and/or last four digits of the PAN. |
Distinct from 3.5.1 in a way the standard states explicitly: masking is not truncation. Masking conceals digits at display time while the full PAN is still stored, so it can be unmasked; truncation removes them. Meeting one does not meet the other. Three procedures, and the first asks for a documented list of roles that need more than the BIN and last four, each with a business need: which is the artefact most entities lack, because masking is usually implemented in the interface and never written down as an access decision.
What to prepare
- The documented list of roles permitted to see more than the BIN and last four digits, with the business need for each.
- Evidence of masking in the places PAN is displayed: screens, receipts, reports, exports.
- Evidence that roles not on the list see only masked PAN, which is what 3.4.1.c observes.
How to implement it
1. Write the role list first. It is the part an assessor examines and the part that turns masking from a UI behaviour into an access control. "Support can see full PAN" is a decision that should have a reason recorded.
2. Mask at the source, not in the template. A view or an API that returns full PAN to a client which then hides it has not masked anything; anyone with the network tab sees it.
3. Include the outputs nobody calls a screen. Printed receipts, exported CSVs, PDF reports and error messages all display PAN, and are usually built by a different team than the one that implemented masking.
4. Show only what the job needs. The requirement caps the display at BIN and last four; it does not entitle anyone to that much. A role needing only the last four should see only the last four.
Where this commonly fails
- No documented role list, so 3.4.1.a fails even where the masking is correct.
- Masking applied in the front end while the API returns the full number.
- Receipts and exports overlooked, though they are named examples.
- Masking treated as satisfying 3.5.1, when the standard says the terms are not interchangeable.
Related controls
Others in section 3.4:
| Control | What it requires |
|---|---|
| 3.4.2 | When using remote-access technologies, technical controls prevent copy and/or relocation of PAN… |
← 3.3.3 · All controls · 3.4.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.