PCI DSS 4.2.2: PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies
PCI DSS v4.0.1 control 4.2.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 4.2.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks › Section 4.2
PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.
Summary
Never send a card number by email, SMS, chat or any other end-user messaging technology unless it is protected by strong cryptography.
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 | |
|---|---|
| 4.2.2.a | Examine documented policies and procedures to verify that processes are defined to secure PAN with strong cryptography whenever sent over end-user messaging technologies. |
| 4.2.2.b | Examine system configurations and vendor documentation to verify that PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies. |
In practice almost nobody can encrypt PAN to the standard required inside consumer messaging, so this control is met by not sending it at all, and by being able to show that both a rule and a mechanism exist. 4.2.2.a looks for the policy; 4.2.2.b looks for the technical control that enforces it. A policy with no enforcement leaves you relying on every employee never making a mistake.
What to prepare
- A written policy prohibiting PAN in email, SMS, chat and ticketing systems.
- Evidence of the technical control that enforces it, such as data loss prevention rules on the mail gateway.
- Evidence of what happens when the rule triggers: a blocked message, an alert, a remediation record.
- Where PAN legitimately must be sent, documentation of the mechanism used and why it qualifies as strong cryptography.
How to implement it
1. Give people a route that is easier than the wrong one. Cardholders and staff email card numbers because there is no obvious alternative. A secure upload link or a phone-based capture path removes the reason before the policy has to.
2. Enforce it at the gateway. A DLP rule matching card number patterns on outbound and inbound mail turns this from an aspiration into a control, and produces the evidence 4.2.2.b asks for.
3. Plan for the inbound case. A customer emailing you their card number is the common event, and it puts PAN into your mail system whether you asked for it or not. Decide in advance how it is detected, purged, and recorded, because that PAN is now stored data and Requirement 3 applies to it.
Where this commonly fails
- A policy that forbids sending PAN with nothing in place to detect it happening.
- Support ticket systems overlooked entirely, so card numbers sit in ticket histories indefinitely.
- Inbound customer emails containing PAN left in mailboxes and backups, which turns a transmission problem into a storage one.
Related controls
Others in section 4.2:
| Control | What it requires |
|---|---|
| 4.2.1 | Strong cryptography and security protocols… |
| 4.2.1.1 | An inventory of the entity’s trusted keys and certificates used to protect PAN during… |
| 4.2.1.2 | Wireless networks transmitting PAN or connected to the CDE use industry best practices… |
← 4.2.1.2 · All controls · 5.1.1 →
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.