PCI DSS 4.2.2: Never send a card number by email, SMS, chat or any other end-user messaging technology unless it is protected by strong cryptography.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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. |
Where you cannot show that a messaging channel protects PAN with strong cryptography, the simplest way to meet this control is not to send PAN that way. The guidance says to use messaging for PAN only where there is a defined business need, controlled through the acceptable use policies in 12.2.1. 4.2.2.a looks for the policy; 4.2.2.b examines system configurations and vendor documentation to verify that PAN is protected with strong cryptography whenever it is sent. A policy with no enforcement leaves you relying on every employee never making a mistake.
What to prepare
- A written policy saying whether PAN may be sent by email, SMS, chat or ticketing systems and, where it may, how it is secured with strong cryptography.
- 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 gives you evidence that the rule is enforced.
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 what you will do. The standard gives two choices: bring the channel into CDE scope and secure it, or delete the data and put measures in place that stop the channel being used for card data. The requirement also applies when a customer asks you to send PAN to them this way. PAN a customer emails you is 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.