PCI DSS Email Requirements: A Complete Guide to Encryption Mandates, Scope Boundaries, and Policy Rules for Compliance

A customer service representative pastes a credit card number into a reply to resolve a disputed charge. In that single keystroke, an organization that has invested heavily in payment tokenization, network segmentation, and quarterly scanning has just moved cardholder data into the one channel the Payment Card Industry Data Security Standard explicitly prohibits. PCI DSS email requirements exist because that keystroke happens thousands of times a day across merchants of every size.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, internet crime drove $20.877 billion in reported losses, a 26% jump over the prior year. Email sits at the center of that figure, and it also sits at the center of the compliance exposure most merchants underestimate.

This guide covers:

• What PCI DSS email requirements mandate under Requirement 4.1 and Requirement 4.2, and how PCI DSS v4.0 tightened both;
• Why standard email fails PCI DSS email requirements at the protocol level, and which encryption approaches close the gap;
• How email pulls servers, endpoints, and cloud tenancies into the cardholder data environment;
• The written policy, compliance level, and assessment questionnaire rules that govern PCI DSS email requirements;
• How phishing, redaction, data loss prevention, and cybersecurity awareness training each change the compliance picture;
• Where generative AI and shadow IT create exposure that no email gateway detects.

Cardholder data reaches employee inboxes daily, and written policy alone never stops it. Adaptive Security trains the behaviors that keep primary account numbers out of email entirely.

Book a demo

What Are PCI DSS Email Requirements?

PCI DSS email requirements are the mandates under Requirement 4 of the Payment Card Industry Data Security Standard that govern how organizations transmit cardholder data through email and other end-user messaging technologies. They require strong cryptography for data in transit over open networks and prohibit sending unprotected primary account numbers (PANs) through email, instant messaging, SMS, and chat. These mandates split along a fault line that shapes every remediation decision: Requirement 4.1 addresses infrastructure-level transmission security, while Requirement 4.2 targets the daily messaging behaviors of individual employees.

Requirement 4.1 vs. 4.2: What Each Mandates Under PCI DSS Email Requirements

Requirement 4.1 and Requirement 4.2 share a common objective, preventing cardholder data from being intercepted during transmission, yet they operate at entirely different layers of the organization. Confusing them produces compliance gaps that Qualified Security Assessors routinely flag during audits. The distinction also determines whether a finding is fixed by an engineer or by a cybersecurity awareness training program.

Requirement 4.1 mandates that organizations implement strong cryptography and security protocols whenever cardholder data is transmitted over open, public networks. The v4.0 text requires that processes and mechanisms for protecting cardholder data during transmission are defined, documented, and implemented. In practice, this means TLS 1.2 or higher for web traffic, IPsec or TLS-based VPNs for remote access, and WPA2 or WPA3 encryption for wireless networks carrying payment data.

Requirement 4.1 is an infrastructure control owned by IT operations and network engineering teams, and it governs how servers, load balancers, APIs, and network tunnels are configured. When a payment page transmits card numbers over HTTPS, Requirement 4.1 is the control being satisfied.

Requirement 4.2 takes a different aim. Its text states that PANs must never be sent through end-user messaging technologies, naming email, instant messaging, SMS, and chat, unless the message is protected with strong cryptography such as PGP or GPG. This is a behavioral mandate governing what individual employees type, paste, forward, or attach.

An organization can hold perfect TLS configurations on every server and still fail an audit because a representative emailed an unprotected credit card number to a client. Requirement 4.2 is what makes email a recurring compliance risk under PCI DSS email requirements, because it regulates human action, which is far harder to control than machine configuration.

That distinction shapes remediation strategy directly. Requirement 4.1 violations are solved with technical controls such as upgrading protocols, rotating certificates, and disabling legacy ciphers. Requirement 4.2 violations call for cybersecurity awareness training, policy enforcement, and in many cases a redesign of business processes so employees never handle PANs in a messaging application at all.

How PCI DSS v4.0 Changed Email-Related Requirements vs. v3.2.1

PCI DSS v3.2.1, retired on March 31, 2024, already prohibited sending unprotected PANs through end-user messaging technologies under its own Requirement 4.2. The core prohibition was present, so what v4.0 changed was the rigor, specificity, and enforceability of the controls surrounding it. Understanding that shift explains why PCI DSS email requirements now generate findings that would have passed a v3.2.1 assessment.

The PCI Security Standards Council introduced 64 new requirements in v4.0, 51 of which were future dated until March 31, 2025 and are now mandatory. Under v3.2.1, Requirement 4 was a single, relatively broad objective covering encrypted transmission across open, public networks. Guidance on end-user messaging technologies existed, yet it was treated as sub-requirement detail.

In v4.0, the requirement was restructured into two explicit sub-requirements, each carrying its own defined purpose, scope, and testing procedures. That structural change forces organizations and assessors to evaluate infrastructure security and employee behavior as separate compliance dimensions with separate evidence obligations.

A second meaningful shift involves documentation and assigned responsibility. For email compliance, a policy stating that PANs are not sent unprotected is no longer enough. Organizations must also show that specific roles are assigned to enforce the policy, that relevant staff are trained on it, and that it is reviewed and updated on a recurring basis.

The scope confirmation requirement, PCI DSS v4.0 Requirement 12.5.2, tightens PCI DSS email requirements indirectly. Organizations must now perform an annual scope confirmation exercise verifying where cardholder data is present across systems. Email servers and client applications that receive, store, or forward unprotected PANs are pulled squarely into scope, expanding the cardholder data environment (CDE) beyond what many organizations historically accounted for.

Which End-User Messaging Technologies Fall Under Requirement 4.2

The v4.0 text for Requirement 4.2 names four categories: email, instant messaging, SMS, and chat. The list is intentionally broad because the underlying risk is uniform across all four. Each channel moves messages across infrastructure the sender does not fully control, often in plaintext, and leaves copies in sent folders, inboxes, browser caches, and device storage that sit outside centralized security controls.

Email is the most commonly cited offender. One unprotected PAN in a customer service reply creates copies in the sender's sent folder, the recipient's inbox, both parties' trash upon deletion, and potentially the browser cache of any device used to reach webmail. Each of those locations becomes a point of exposure.

Instant messaging platforms such as Slack, Microsoft Teams, and WhatsApp present the same problem, compounded by the informality and speed of chat that encourage employees to paste data without pausing to assess risk. SMS adds a further complication, since telecommunications infrastructure routes messages through carrier networks with no guarantee of end-to-end encryption. Standard chat applications frequently lack message-level encryption by default.

The standard does provide one narrow path for using these channels compliantly. If the PAN is protected by strong cryptography, whether PGP, GPG, or equivalent full-message encryption, before transmission, Requirement 4.2 can be satisfied. In practice this is rarely workable at scale, because the recipient must hold compatible decryption capability, key exchange must be managed securely, and workflow friction almost always drives employees toward unencrypted alternatives.

Most organizations conclude that the only sustainable path through PCI DSS email requirements is to design business processes that eliminate PANs from messaging workflows entirely. Routing payment capture through secure web forms, tokenized payment links, or dedicated portals keeps cardholder data out of employee inboxes altogether. A cybersecurity awareness training program covering PCI-specific scenarios then closes the gap between written policy and daily behavior that Requirement 4.2 was written to address.

A prohibition written into policy means nothing when an employee has never seen it applied to a live customer email. Adaptive Security turns those rules into rehearsed behavior.

Take a self-guided tour

Is Email Secure for Transmitting Credit Card Data Under PCI DSS?

No. Standard email fails PCI DSS email requirements for credit card data because it operates as an unencrypted, store-and-forward protocol in which messages traverse multiple intermediate mail servers. Each of those servers is a potential interception point a cyberattacker can exploit.

PCI DSS Requirement 4.2 prohibits sending unprotected primary account numbers (PANs) through end-user messaging technologies. The mechanics of the protocol explain why that prohibition is so difficult to engineer around.

Email was built for deliverability in preference to confidentiality. A message containing a credit card number leaves a copy on the sender's device, then passes through the outgoing mail server, hops across intermediate relay servers on the public internet, and lands on the recipient's incoming mail server. It finally sits on the recipient's device, often in multiple folders, caches, and backups.

Even when Transport Layer Security (TLS) encrypts the connection between two mail servers, the protection is hop by hop. Each relay decrypts the message to read headers and determine routing, then re-encrypts it for the next leg, which leaves cardholder data readable in plaintext at each stop. One compromised device or server anywhere in that chain exposes each PAN that has passed through it.

The Four Email Vulnerability Points That Threaten Cardholder Data

Any email carrying cardholder data creates four distinct surfaces a cyberattacker can target, and understanding each explains why email and PCI DSS email requirements are fundamentally incompatible without extraordinary compensating controls. Two of those surfaces sit inside the sending organization, where controls can be enforced directly. The other two sit outside it, where no control is enforceable at all.

Sender device: Before an email leaves the organization, the cardholder data resides on the sender's computer or mobile device. Malware, a lost or stolen laptop, an unlocked screen, or an insider gives a cyberattacker direct access to the message body, any attachments containing PANs, and cached credentials. If the device syncs to cloud storage or backup services, the exposure multiplies.

Sending mail server: The outgoing SMTP server processes the message before routing it toward the recipient. If it is compromised through an unpatched vulnerability, a misconfigured access control, or a phishing attack against an administrator, every message it has processed becomes readable. That server now falls inside the cardholder data environment (CDE).

Receiving mail server: After traversing the public internet, the message lands on the recipient's incoming mail server. The sending organization has no visibility into how that server is configured, patched, monitored, or secured. It may run outdated software, store messages on unencrypted disk volumes, or operate under a provider that meets none of the standards the sender is obligated to maintain.

Recipient device: Once delivered, the email sits in the recipient's inbox, sent folder, trash folder, local search indexes, and cloud backups. Forwarding, replying with the original attached, or opening the message on an unmanaged personal device cascades the exposure further. One forwarded message can place cardholder data onto systems the originating organization will never discover.

The table below maps each vulnerability point to its specific risk and the control needed to mitigate it.

Two of the four vulnerability points sit entirely outside the sender's control. Even where an organization implements each technical and administrative safeguard on its own infrastructure, the recipient environment remains an unmanaged risk vector. That asymmetry is precisely why the PCI Security Standards Council prohibits email as a transmission channel for unprotected cardholder data.

Why Standard Email Is Inherently Non-Compliant With PCI DSS Email Requirements

The standard is explicit on this point. Requirement 4.2 states that organizations must never send unprotected PANs through end-user messaging technologies, and it names email directly. This is a hard prohibition every merchant and service provider must meet, in preference to a recommendation or a best practice.

Two structural characteristics compound the hop-by-hop decryption problem described above. The first is persistence: one email containing a credit card number creates plaintext copies in the sender's sent folder, the recipient's inbox, both trash folders, the browser cache of anyone who accessed webmail, client-side search indexes, and any backup system that captured those mailstores. Deleting the original message removes none of those copies, which violates Requirement 3 and its mandate to minimize cardholder data storage and render stored PANs unreadable.

The second is uncontrolled scope. Each server an email carrying a PAN passes through becomes part of the CDE and must satisfy the full standard, a burden examined in detail later in this guide. Bringing one additional server into scope is expensive, and bringing an unknown number of third-party mail servers into scope is operationally impossible.

Some organizations attempt workarounds using email encryption gateways, secure portals that deliver links in place of data, or end-to-end encrypted clients. These can satisfy the letter of Requirement 4.2 while introducing key management overhead, recipient friction, and the persistent risk that one employee bypasses the secure channel and pastes a PAN into a standard message. The more reliable approach is the one PCI DSS email requirements were written to enforce: keep cardholder data out of email.

What Packet Sniffing Means for Cardholder Data in Transit

Packet sniffing is the practice of capturing and inspecting data packets as they travel across a network, and it represents one of the most direct cyber threats to cardholder data in transit under PCI DSS email requirements. It is also a risk that TLS alone cannot fully neutralize. The PCI Security Standards Council identifies packet sniffing during delivery across internal and public networks as a core reason for prohibiting unprotected PAN transmission through end-user messaging.

When a cyberattacker positions a packet sniffer on any network segment between sender and recipient, every unencrypted packet becomes readable. Mail protocols without TLS enforcement transmit message headers, body content, and attachments in cleartext, so a sniffer capturing that traffic can reconstruct the full message and any PANs inside it from the raw packet stream.

TLS-encrypted connections reduce this surface without eliminating it. Where any server along the path supports downgraded encryption such as SSLv3, TLS 1.0, or weak cipher suites, an active cyberattacker can force a downgrade and decrypt traffic in transit. PCI DSS v4.0 mandates TLS 1.2 or higher, though organizations can only enforce that baseline on infrastructure they own.

The exposure extends to internal networks. A cyberattacker who gains a foothold on a corporate LAN can deploy a sniffer to capture internal mail traffic, and where internal servers communicate without TLS, a configuration still common in legacy environments, each message containing a PAN crosses the LAN in cleartext. Requirement 4 rejects the assumption that internal networks are safe, demanding strong cryptography wherever cardholder data moves outside fully trusted zones.

Packet capture tools are widely available, require minimal skill to deploy, and can run undetected for extended periods. One successful sniffer placement on any hop along a message path can silently harvest months of cardholder data before detection. The only reliable defense is removing the data from the channel entirely, which is a behavioral outcome that depends on cybersecurity awareness training as much as on network engineering.

Encryption protects the wire while cardholder data still lands in plaintext on servers and laptops nobody scoped. Adaptive Security addresses the employee decisions that put it there.

Explore the platform

Encryption Requirements for PCI-Compliant Email Communications

Encryption is central to PCI DSS email requirements, though not all encryption approaches satisfy the standard equally. The decisive distinction lies between transport-layer encryption, which protects data only while it moves between mail servers, and end-to-end encryption, which safeguards cardholder data from the moment it leaves the sender until the recipient decrypts it. Choosing the wrong approach, or deploying the right one incompletely, expands the cardholder data environment (CDE) without the security team registering the change.

TLS Transit Encryption vs. End-to-End Encryption Under PCI DSS Email Requirements

The gap between TLS and end-to-end encryption is an architectural divide in preference to a matter of degree, and it determines whether email infrastructure falls inside or outside PCI scope. TLS, including TLS 1.3, operates at the transport layer and encrypts the connection between two mail servers. The message itself sits unencrypted in the sender's sent folder and on the receiving server, which pulls each mail server in the delivery chain, along with backup systems and synchronized devices into the CDE.

End-to-end encryption (E2EE) eliminates that sprawl. The message is encrypted on the sender's device using a key only the intended recipient holds, and it remains ciphertext across all relays and intermediate systems. A 2026 Basis Theory analysis of PCI compliance and email security concluded that end-to-end encryption is the only workable way to align email containing cardholder data with the standard, because without it each traversed server enlarges the CDE and the corresponding audit burden.

Consider a practical scenario. An accounts receivable clerk emails a customer's full credit card number to resolve a disputed charge, and with TLS alone that number sits in the clerk's sent folder, on the outbound server, on the recipient's inbound server, in the recipient's inbox, and potentially on both parties' mobile devices and backup archives. Each location must then meet encryption-at-rest requirements, access controls, and monitoring, whereas end-to-end encryption confines plaintext to the two endpoint devices.

The table below maps the three primary approaches across the dimensions that matter most for PCI DSS email requirements.

Can PGP and GPG Encryption Satisfy PCI DSS Email Requirements?

Pretty Good Privacy (PGP) and its open-source counterpart GNU Privacy Guard (GPG) are asymmetric encryption systems that use public and private key pairs to encrypt email content from sender to recipient. In theory they satisfy the transmission-protection element of PCI DSS email requirements, because the message body remains encrypted across each hop and no intermediate mail server can read it. In practice, the operational burden is substantial enough that many organizations find them unsuitable as a standalone compliance answer.

Each party generates a key pair, the sender encrypts the message with the recipient's public key, and only the recipient's passphrase-protected private key can decrypt it. That architecture maps cleanly onto the principle of rendering cardholder data unreadable during transmission. A 2025 Thoropass analysis of PCI DSS encryption requirements notes that the standard does not mandate end-to-end encryption specifically, requiring instead that PANs be rendered unreadable, a bar that properly implemented PGP or GPG can clear.

The challenges emerge at scale. Each party must install and configure compatible software, then generate, safeguard, and periodically rotate key pairs, and public keys must be exchanged and verified through a trusted channel before any encrypted exchange begins. That manual step breaks down quickly once multiple employees, departments, or external contacts are involved.

Private key compromise, passphrase loss, or key expiration renders encrypted messages inaccessible and can disrupt business operations. PCI DSS Requirement 3.6.1 demands fully documented key management processes, and governing key lifecycles across dozens or hundreds of employees introduces administrative overhead that most security teams are not staffed to absorb.

For organizations with a small, technically disciplined group who regularly exchange cardholder data and can maintain rigorous key management, PGP or GPG remains a viable component of a compliance strategy. For most mid-market and enterprise organizations, key distribution friction, user error risk, and audit documentation burden make it an incomplete answer without supplementary controls. Cybersecurity awareness training on secure data handling closes the human-layer gaps that even correctly configured encryption cannot address.

Is TLS 1.3 Alone Sufficient for PCI Compliance?

No. TLS 1.3 is the fastest and most secure version of the Transport Layer Security protocol, eliminating obsolete cipher suites, mandating forward secrecy, and reducing the handshake to a single round trip. What it cannot do is address the data-at-rest exposure that PCI DSS email requirements are built to prevent.

TLS 1.3 encrypts the pipe between mail servers, and that protection ends the moment a message lands on the receiving server, on a laptop, or in a cloud backup.

Requirement 3 obligates organizations to render stored PANs unreadable through encryption, tokenization, or one-way hashing, while Requirement 4.2 bars unprotected PANs from end-user messaging technologies. TLS 1.3 satisfies the transmission controls in Requirement 4.1 and leaves the stored copies of those messages unprotected, creating a Requirement 3 violation the moment the message arrives.

This is no criticism of the protocol itself. A 2025 Schellman analysis of TLS 1.3 and PCI DSS makes the point directly, observing that TLS 1.3 is not required for compliance but is a sound long-term move because it is faster, more secure, and strips out weak encryption methods. The protocol is superior to TLS 1.2 and belongs as the transport baseline for every organization, though it was never designed to solve the email-at-rest problem.

The practical path forward is layered. Organizations should deploy TLS 1.3 across mail infrastructure to secure the transport layer, then add end-to-end encryption or a secure file transfer mechanism whenever cardholder data must be communicated. Relying on TLS 1.3 alone leaves plaintext PANs across multiple systems, each of which an assessor will scope, examine, and flag against Requirements 3 and 4.

Deadline pressure decides whether an employee uses the secure channel or the fastest one. Adaptive Security builds the reflex that sends cardholder data through the approved path every time.

Book a demo

How Email Communications Expand PCI DSS Scope

When a primary account number (PAN) lands in an inbox, whether sent by a customer, a vendor, or an internal colleague, the cardholder data environment (CDE) expands instantly to encompass all mail servers, client applications, and cloud services that stores, processes, or transmits that message. This is the single most consequential mechanic behind PCI DSS email requirements, and it is the one most organizations discover only during an assessment. Scope expansion triggers control obligations and audit scrutiny across systems that were never designed to sit inside a regulated payment environment.

When an Email Server Becomes Part of the CDE

Under PCI DSS, the CDE covers any system component that stores, processes, or transmits cardholder data. A mail server receiving a message with a credit card number in the body or an attachment does all three, since the message is processed during delivery, transmitted across internal relays, and stored in the recipient inbox, the sender's sent folder, and often in backups, archives, and browser caches long after the transaction closed.

That single message creates a cascade of obligations. The mail server must now satisfy access restrictions under Requirement 7, logging and monitoring under Requirement 10, vulnerability management under Requirement 11, and encryption for data at rest under Requirement 3. Workstations and mobile devices that reach those inboxes fall into scope as well, because they can display, copy, or forward the cardholder data.

The practical burden is substantial. Mail servers are rarely architected with PCI compliance in mind, and they typically lack the segmentation, access controls, and audit logging granularity that a properly scoped CDE demands. Retrofitting those controls onto a production mail system is expensive and operationally disruptive, which is why many organizations discover the problem only when a Qualified Security Assessor (QSA) identifies cardholder data in email repositories and extends the audit boundary accordingly.

The Recipient Problem: How Outbound PANs Put Both Parties in Scope

Sending PANs by email creates a scope problem that runs in both directions, placing the sender's infrastructure and the recipient's infrastructure inside the CDE simultaneously. Transmitting a credit card number to a customer, partner, or service provider extends compliance accountability into systems the sending organization has never seen. This is the dimension of PCI DSS email requirements that most compliance teams fail to anticipate.

PCI DSS holds the entity that initiates the transmission responsible for keeping the cardholder data protected throughout its journey. Under Requirement 4.1, organizations must encrypt cardholder data transmitted over open, public networks, and under Requirement 4.2, PANs must never be sent through end-user messaging technologies unless rendered unreadable with strong cryptography.

Yet even where the sender encrypts the message, no mechanism guarantees the recipient decrypts and stores it under an equivalent level of protection. If the recipient opens the message on an unencrypted device, files it in an unsecured folder, or forwards it onward, the cardholder data is exposed and the originating organization carries the compliance consequences.

Assessors describe this as an unresolvable compliance gap. The sending organization cannot audit the recipient environment, enforce its access controls, mandate its encryption standards, or verify its retention and deletion practices, and it remains accountable regardless. The only reliable defense is to keep PANs out of email at the outset, replacing that workflow with a secure portal, a tokenized reference, or a dedicated payment link.

Cloud Email Services and PCI Scope Implications

Cloud platforms such as Google Workspace and Microsoft 365 make the scope expansion more consequential, because these services are not PCI DSS compliant out of the box. Microsoft's own PCI DSS documentation confirms that its certification covers OneDrive for Business, SharePoint Online, and Azure Communication Service. Exchange Online and Outlook, the services that carry email, are excluded, so a PAN moving through either platform brings the entire tenancy into scope for assessment.

The shared responsibility model adds complexity. Major providers maintain PCI DSS Level 1 Service Provider certifications covering their physical data centers, hypervisor layer, and core network fabric, which is security of the cloud. The organization remains wholly responsible for security in the cloud, meaning encryption configuration, access controls, monitoring for unauthorized PAN storage, and preventing cardholder data from spreading across collaboration tools and inboxes.

Under PCI DSS v4.0, fully mandatory since March 31, 2025, organizations must document and confirm scope at least annually, which makes continuous discovery of cardholder data in cloud repositories a standing obligation. One PAN in a user's mailbox may exist simultaneously in the cloud mailbox, the local device cache, an eDiscovery hold, a backup retention copy, and any mobile device synchronizing with that account. Each of those locations enters the CDE and must satisfy the full suite of controls.

Encrypted gateways and end-to-end encryption reduce exposure by rendering the message body unreadable to intermediate servers, and neither removes the cloud platform from scope. The encrypted message still transits and resides within the cloud platform, simply unreadable without the key, and PCI DSS scoping guidance holds that encrypted cardholder data does not automatically de-scope a system. Reducing email-driven scope depends on ensuring PANs never enter the environment, a discipline that rests as much on trained employees as on technical controls.

Scope discovered during an assessment is scope nobody budgeted for or hardened. Adaptive Security keeps cardholder data out of the inboxes that quietly widen the audit boundary.

Take a self-guided tour

Step-by-Step: Handling Accidental Receipt of Cardholder Data via Email

When a customer or vendor sends credit card data through unencrypted email, the response in the first few minutes determines whether the incident stays a minor procedural violation or escalates into a reportable breach. PCI DSS email requirements offer no exemption for data an organization did not ask to receive, and the receiving mailbox enters scope the moment the message arrives. The procedure that follows covers immediate handling, retention alternatives when deletion is impossible, and the documentation assessors expect to see.

1. Immediate Actions: Delete, Avoid Replying, Avoid Forwarding

The moment an employee recognizes that a message contains unprotected cardholder data, the correct response is to stop and avoid replying or forwarding. Replying with the original content intact, even to tell the sender they made a mistake, creates a second copy of the cardholder data in the sent folder and pushes it back through the mail server chain. That single reply multiplies the number of systems now in scope.

The message should be deleted from the inbox immediately, then permanently removed from the trash or deleted items folder. Where the mail client stores messages in a recoverable cache, that cache must be purged as well, and the sent folder, drafts folder, and any custom folders that may have auto-sorted the message all need checking.

For web-based clients, clearing the browser cache after deletion eliminates locally stored remnants. If the organization runs email archiving or e-discovery tooling, the IT team must remove the message from the archive too, since an archived copy remains cardholder data in storage.

Contact with the sender should happen through a completely separate channel, whether a phone call, a secure messaging platform, or a new thread that neither quotes nor references the original. That conversation explains why email is unsuitable for payment card information and directs the sender toward the approved secure payment portal or tokenized payment method, which prevents recurrence.

2. Secure Retention Options If Data Cannot Be Deleted

Sometimes the cardholder data must be retained for a legitimate business reason such as a pending transaction that cannot be reprocessed, a dispute resolution, or a legal hold. When deletion is not an option, the data must be secured in a way that satisfies PCI DSS Requirement 3.5.1, which mandates that stored PANs be rendered unreadable anywhere they are kept.

The most straightforward method is truncation, retaining only the first six and last four digits and permanently deleting the middle digits. Where full PAN retention is unavoidable, tokenization replaces the card number with a surrogate value carrying no mathematical relationship to the original, while the actual PAN sits in a token vault outside the email environment. Either approach removes the mail system from scope, because what remains in the inbox no longer qualifies as cardholder data.

The redacted or tokenized value should then move out of email entirely into a segmented, access-controlled environment that forms part of the documented CDE. If a record must remain in a message for audit trail purposes, the security team should confirm the message is encrypted at rest and that access is restricted to individuals with a documented business need.

3. Documentation and Policy Follow-Up

Every accidental receipt should be documented in line with the organization's information security policy, capturing the date and time of receipt, the sender's identity, the nature of the data exposed, the actions taken to delete or secure it, and the communication instructing the sender to stop using email for card data. That record demonstrates diligence during an assessment and reveals patterns, such as a vendor, department, or customer segment that repeatedly sends card data through email and needs a workflow change.

If the message was opened on a compromised or shared device, the incident escalates immediately to the security team. A device infected with malware or accessed by an unauthorized user may have exposed the cardholder data to a cyberattacker, so the team should conduct a forensic review, assess whether exfiltration occurred, and determine whether breach notification obligations under state law or card brand rules are triggered.

Each incident is also a cybersecurity awareness training opportunity. Employees who handle payment data need the specific handling protocol for a rule broken by a third party, and a rehearsed team is far less likely to make the costly mistake of replying or forwarding, which expands the violation across every system the message reaches.

One reply to a message containing a card number can widen a violation across systems nobody can audit. Adaptive Security rehearses the correct response before it matters.

Explore the platform

PCI DSS Email Policy Requirements and Compliance Levels

The PCI Security Standards Council's FAQ #1085 (August 2025) draws a bright line: no unprotected primary account numbers (PANs) over email, instant messaging, SMS, or chat, whether sent internally or to third parties. A written information security policy under Requirement 12 must reflect that prohibition in plain, enforceable language. Without a policy naming every prohibited channel outright, each unencrypted PAN crossing the mail system becomes a compliance finding waiting to surface during an assessment.

Policy ownership belongs to a named individual, every employee who might encounter cardholder data needs training on what the rule means in practice, and a documented procedure must govern what happens when someone violates it. Board-level attention increasingly determines whether those elements actually get funded. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of organizations report that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues.

What a Written Security Policy Must Say About Email and PANs

Requirement 4.2.2 prohibits sending unprotected PANs through any end-user messaging technology, and FAQ #1085 confirms that email, instant messaging, SMS, and chat all fall within that category. Requirement 4.2.1 adds that strong cryptography and security protocols are mandatory whenever cardholder data traverses open public networks.

A defensible policy under PCI DSS email requirements should do the following:

• Name email, SMS, instant messaging platforms, chat applications, and public forums as prohibited channels for unencrypted PANs;
• Assign responsibility for policy enforcement to a specific role with the authority to act on violations;
• Define the encrypted alternatives employees are expected to use in place of messaging;
• Outline the immediate steps required when cardholder data arrives through a prohibited channel, consistent with PCI SSC FAQ #1157 on accidental receipt;
• Specify the consequences of deliberate non-compliance.

Employee training is the mechanism that turns policy text into operational reality. Any staff member who handles customer payments, manages invoicing, or works in accounts receivable must understand that forwarding one unencrypted credit card number violates the standard and carries financial and legal consequences for the organization. A cybersecurity awareness training program mapped to PCI DSS must include realistic scenarios: a customer who emails a card number unprompted, a vendor who requests payment details over SMS, an internal colleague who pastes a PAN into a Teams chat to save time.

PCI Compliance Levels and Which SAQ Applies to an Email Assessment

The four merchant compliance levels are determined by annual transaction volume across all payment channels, as defined by the individual card brand merchant level programs. The level an organization occupies dictates the rigor of its validation and whether it completes a Self-Assessment Questionnaire (SAQ) or undergoes a full Report on Compliance (ROC) with an onsite QSA audit.

Which SAQ applies depends entirely on how cardholder data flows through the environment. SAQ A and SAQ A-EP cover merchants who fully or partially outsource payment processing, and they may apply where an organization never stores, processes, or transmits cardholder data on its own systems and email sits outside the payment flow. SAQ B, B-IP, C, and C-VT address specific terminal and virtual-terminal configurations where email is typically out of scope, while SAQ P2PE-HW applies to merchants using only validated point-to-point encryption hardware.

Where email plays any role in which PANs might appear, even inadvertently, SAQ D is the only questionnaire covering the full set of requirements including Requirement 4.2.2, and service providers are always assessed under SAQ D for Service Providers. The deciding question is simple: can a PAN ever reach an employee inbox? An affirmative answer places the mail system in scope and points to SAQ D or a full ROC.

Financial, Legal, and Reputational Consequences of Non-Compliance

Failing PCI DSS email requirements is an expensive liability in preference to an administrative oversight, because payment card brands levy fines through acquiring banks that escalate with the duration of non-compliance. A January 2026 analysis by the Johanson Group found that Level 1 merchants can face monthly non-compliance penalties ranging from $5,000 to over $100,000, while breach-related fines can reach $50 to $90 per compromised cardholder record, with total fines capped at $500,000 per incident.

Beyond fines, a breach involving unencrypted PANs transmitted by email triggers a mandatory forensic investigation by a PCI Forensic Investigator (PFI). The acquiring bank may suspend or permanently terminate the merchant account, which can be fatal for a business that depends on card payments, and class-action litigation from affected customers frequently follows.

Reputational damage compounds every other cost. Customers abandon breached businesses, transaction fees rise permanently once an organization is reclassified as high risk, and cyber insurance policies may be voided when non-compliance is discovered during a claim review.

The exposure compounds quickly. One employee who copies a card number into a message creates a violation, and multiplying that across hundreds of employees and years of operations makes the exposure systemic. Cybersecurity awareness training that teaches what the policy requires and rehearses scenarios where staff must recognize and refuse an improper PAN transmission is the operational control that keeps an organization off the penalty schedule and out of a PFI investigation.

Penalty schedules escalate for as long as non-compliance persists, and one careless message can start the clock. Adaptive Security closes the behavioral gap policy documents leave open.

Book a demo

How Phishing Attacks Compromise PCI DSS Email Compliance

When an employee falls for a phishing attack and surrenders email credentials, the cyberattacker gains access to an inbox that often sits entirely inside the cardholder data environment. Inboxes across finance, accounts receivable, and customer service routinely hold unencrypted payment card numbers, transaction receipts, and customer verification documents, all of which count as stored cardholder data under Requirement 3. That single phished password also violates Requirement 7, which restricts access to cardholder data to personnel whose job function explicitly requires it.

Most organizations do not treat email accounts as in-scope systems during assessment, and that assumption is precisely what makes phishing so dangerous to PCI DSS email requirements. It exploits the gap between what the standard demands and how payment data actually moves through daily operations.

How Phished Email Accounts Expose Stored Cardholder Data

The compliance problem begins with how payment data enters inboxes in the first place. Customers email card authorization forms, vendors send invoices with payment details attached, internal teams forward payment confirmations for reconciliation, and accounts payable staff receive supplier onboarding PDFs containing full PANs. Each message leaves a persistent copy of cardholder data sitting in the mailbox, often unencrypted and searchable, months or years after the original transaction cleared.

A cyberattacker who compromises that account inherits all of it. Using nothing more than the built-in search function, they can query terms such as "credit card," "payment," or specific card brand names and retrieve years of accumulated cardholder data within minutes, bypassing the hardened perimeter controls built around payment processing infrastructure.

Speed compounds the problem. According to the CrowdStrike 2026 Global Threat Report, average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds. Detection and response cycles measured in hours give an intruder ample room to export a mailbox before anyone notices.

The targeting dynamic makes this worse. Business email compromise campaigns impersonate executives or trusted vendors to manipulate finance and accounting staff, who are the same employees whose inboxes are most likely to contain payment data, wire instructions, and cardholder information. A phishing simulation program that includes business email compromise scenarios helps these high-risk teams recognize impersonation before credentials are surrendered.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, business email compromise accounted for $3.046 billion in losses across 24,768 incidents, averaging roughly $123,000 per case. That average is larger than the annual security budget of many mid-market merchants.

SPF, DKIM, and DMARC as PCI Email Security Controls

Email authentication protocols are widely understood as anti-spoofing mechanisms, and they also serve a specific function within PCI DSS email requirements by addressing the phishing vector directly. Requirement 4 obligates organizations to protect cardholder data during transmission over open, public networks, and Requirement 4.2 bars unencrypted PANs from end-user messaging. Payment data arrives in inboxes regardless of policy, which makes the integrity and authenticity of those messages a compliance concern.

The three protocols divide the work between them:

• SPF (Sender Policy Framework) authorizes which mail servers may send email on behalf of a domain;
• DKIM (DomainKeys Identified Mail) cryptographically signs outgoing messages so receiving servers can verify the content was not altered in transit;
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together with a policy instructing receiving servers to quarantine, reject, or flag messages that fail authentication.

Together they prevent cyberattackers from spoofing trusted domains in phishing messages aimed at employees who handle payment data. With DMARC configured at an enforcement policy of reject, a cyberattacker cannot send a message appearing to come from a finance executive's domain to the accounts payable team, because the receiving server drops it before it reaches the inbox.

Enforcement also addresses the inbound side of email integrity. When receiving servers validate incoming messages against SPF and DKIM, spoofed messages from external domains impersonating payment processors or banking partners are blocked or flagged, which protects employees from the exact impersonation pattern that leads to credential compromise and subsequent cardholder data exposure.

The scale of that pattern is worth stating plainly. The FBI Internet Crime Complaint Center's 2025 Internet Crime Report recorded 191,561 phishing and spoofing complaints, the highest volume of any reported crime type that year.

Why MFA for Email Access Is Now a PCI Compliance Imperative

PCI DSS v4.0 changed the multi-factor authentication landscape. Under Requirement 8.4.2, mandatory since March 31, 2025, MFA must be implemented for all access into the cardholder data environment. That expansion covers every user in place of administrators and remote connections alone, and it has direct consequences for email access under PCI DSS email requirements.

If an email account contains, transmits, or can reach cardholder data, that account now falls within the MFA mandate, including cloud-based mail services. A support agent who can open a ticket attachment containing a payment form must authenticate with at least two independent factors from different categories: something they know, something they have, or something they are.

For organizations that previously treated email as an out-of-scope messaging channel, this forces a reassessment. Payment data does arrive in inboxes, which places those inboxes inside the CDE and makes MFA mandatory. A phished password without MFA gives a cyberattacker everything needed to reach email remotely, whereas an enforced second factor makes a stolen credential alone insufficient.

Credential theft also creates exposure well beyond the inbox. Employees who reuse passwords across systems mean one phished email credential can unlock payment portals, merchant dashboards, and back-office systems that store or process cardholder data. MFA on email access is the first line of defense, and without it an intruder can often reach deeper into payment infrastructure using the same compromised identity.

Requirement 8.5 further mandates that MFA systems resist replay attacks, prevent user bypass, and validate all authentication factors before granting access. Those implementation details close the gaps that leave even MFA-protected accounts vulnerable when configured incorrectly, though they matter only where MFA is enabled on every inbox that touches cardholder data.

Phished credentials open a mailbox holding years of card numbers long before any alert fires. Adaptive Security trains employees to recognize the lure that starts it.

Take a self-guided tour

Email Redaction, DLP, and Technical Safeguards for PCI Compliance

Encryption alone does not resolve PCI DSS email requirements. Organizations need redaction to remove or mask cardholder data already sitting in mailboxes, data loss prevention (DLP) to stop new card data from leaving, and strict adherence to masking rules dictating exactly how much of a primary account number (PAN) may remain visible. Deployed together, these three controls shift email from an expanding liability to a manageable surface with a defensible audit trail.

How Email Redaction Works and Why It Reduces PCI Scope

Redaction automatically identifies and removes sensitive cardholder data from message bodies and attachments, replacing it with a masked identifier or placeholder. Encryption wraps data in a protective layer while leaving the underlying content intact, whereas redaction removes the sensitive value itself. That distinction matters for scope, because a full PAN inside an encrypted message keeps both the message and its host system within the cardholder data environment (CDE), while a redacted PAN takes the message out of scope.

The mechanism runs on pattern-matching engines scanning for sequences that match known issuer identification numbers (IINs) and pass a Luhn algorithm check. When a 16-digit PAN is detected, the DLP engine replaces all but the first six and last four digits with a mask character or substitutes a reference token. This runs at rest for historical messages and in transit for outbound ones.

Organizations running Microsoft 365 or Google Workspace can deploy DLP tooling that performs OCR-based PAN detection across bodies and attachments, including PDFs, screenshots, and embedded images. A card number captured in a customer screenshot and attached to a support thread is just as dangerous as one typed into the body, and modern platforms extract text from images and scanned documents before running the same detection and redaction pipeline.

Historical scanning addresses a vulnerability most organizations overlook: years of accumulated messages containing PANs that employees or customers sent before any DLP policy existed. One forgotten card number in a three-year-old invoice attachment still counts as stored cardholder data. Retroactive scanning flags each instance across the mail corpus and applies redaction or deletion automatically, shrinking the CDE footprint without manual intervention.

DLP Capabilities Required for PCI-Compliant Email

Not every DLP deployment satisfies PCI DSS email requirements. An effective configuration needs five specific capabilities working in sequence, from detection through to the evidence a QSA will ask for. Deployments that stop at alerting rather than acting tend to fail on the evidence dimension, because an alert log demonstrates awareness of violations without demonstrating remediation of them.

• PAN pattern detection that goes beyond simple regex, validating candidate numbers against the Luhn algorithm and recognizing issuer-specific BIN ranges to distinguish real card numbers from 16-digit order IDs;
• OCR-based scanning for attachments and embedded images, since card data rarely arrives exclusively in plaintext;
• Automated redaction that replaces detected PANs with masked values on detection, with no manual review step and no alert-only workflow;
• Real-time outbound blocking that prevents any message containing unmasked cardholder data from leaving, with immediate user notification explaining the hold;
• Comprehensive logging of every detection and remediation action, producing audit trails that demonstrate compliance during assessments.

The PCI Security Standards Council's guidance on data storage reinforces that sensitive authentication data must never be stored after authorization. A DLP policy that catches and blocks outbound card verification codes or full track data before they reach a sent-items folder enforces that rule at the technical control layer.

PCI DSS Requirement 3.4.1 and Email Retention: What Must Be Masked

PCI DSS draws a hard line between what can be retained in email and what cannot. PANs stored in any form, including mail archives, must be rendered unreadable through masking, truncation, or encryption. When PANs are displayed, the standard permits showing only the first six and last four digits under Requirement 3.4.1, and even that limited display must be restricted to personnel with a documented business need.

Each digit between the BIN and the final four must be replaced with a masking character such as X or an asterisk, with no exceptions or convenience-based overrides. The interaction between this rule and email retention is direct: an organization retaining customer service messages containing full, unmasked PANs in the body or in attached order confirmations is non-compliant, and the obligation applies whether the PAN sits in a database, a log file, a PDF, or an archived mail thread.

Organizations that never scan and redact historical mail stores are maintaining an undocumented, unsecured PAN repository that assessors will find. Sensitive authentication data carries an even stricter prohibition, since card verification values are classified as sensitive authentication data and Requirement 3.3.1 prohibits storing them after authorization, even in encrypted form.

A customer service message containing a verification code that a representative typed into a form field and forwarded internally creates a violation the moment authorization completes. DLP policies must therefore detect verification code patterns, which typically appear as three digits near a PAN or in a dedicated security-code field, and block or redact them before they persist anywhere in the mail system. Retaining that data in an encrypted archive attached to a message satisfies neither the letter nor the intent of the standard.

Historical mail archives quietly hold card numbers no policy ever scoped or scanned. Adaptive Security stops employees from adding more while technical controls clear the backlog.

Explore the platform

How Cybersecurity Awareness Training Supports PCI DSS Email Requirements

Organizations spend heavily on encryption gateways, DLP rules, and transport-layer security, yet one employee who forwards a spreadsheet of primary account numbers to a personal inbox can undo each of those safeguards. The PCI Security Standards Council explicitly mandates that security awareness training under Requirement 12.6 be an ongoing activity for every person with access to the cardholder data environment. Under PCI DSS v4.0, cybersecurity awareness training stopped being a compliance checkbox and became the control that makes every other technical safeguard enforceable.

Why Technical Controls Alone Cannot Prevent Every PCI Email Violation

Encryption and DLP tools operate on rule-based logic, detecting a 16-digit card number pattern and blocking the message. What they cannot detect is the employee who, confused by a payment processing exception, types a request asking the customer to resend the card number because the secure link failed. That reply creates a new request for unprotected cardholder data, and no DLP rule flags it because the outbound message contains no PAN at all.

The scope problem compounds when an employee replies to a thread containing cardholder data buried three messages deep, because the entire thread travels with the reply. Most employees never consider that a three-word response has just retransmitted protected data outside the encrypted channel, which is the most common and least understood failure mode under PCI DSS email requirements.

A dotSec analysis of PCI DSS compliance failures documented a case where an accounting team, untrained on the standard, received card numbers and PINs by email from customers and stored them in shared cloud storage. The team violated Requirements 3, 4, 7, and 8 simultaneously through a complete absence of awareness that email is an unapproved channel for cardholder data, with no malice or negligence involved.

Email is inherently conversational, and employees treat it like a telephone: quick, informal, and threaded. Each gateway, policy, and transport-layer protection rests on the assumption that employees will send approved data through approved channels, and that assumption breaks whenever nobody has taught them what the rules actually are.

What Employees Must Know About Email and Cardholder Data

Training for email compliance must address four competencies that generic awareness programs rarely cover. Each maps to a specific failure mode assessors encounter during interviews, and each is learned through practice in preference to explanation. A cybersecurity awareness training program built on scenarios employees actually face produces the behavioral evidence a QSA can verify.

• Recognizing a PAN in context: A card number is not always labeled as one, appearing instead in a forwarded invoice, a screenshot of a terminal receipt, a spreadsheet attachment, or a support ticket thread, so training should include visual examples across document formats.
• Understanding that replies perpetuate violations: The original sender may have used an encrypted channel, and the reply reintroduces the data into an unprotected stream, which is why role-based scenarios that simulate exactly this situation matter.
• Executing a rehearsed accidental-receipt procedure: Without a practiced routine, employees improvise, and improvisation in a compliance context usually means a violation, so the procedure must be simple enough to complete in under a minute.
• Using the encryption tools the organization provides: Employees need hands-on practice with a secure file transfer portal or encrypted client before a payment deadline pushes them back to email.

Connecting PCI DSS Requirement 12.6 to Email Compliance

Requirement 12.6 is a mandatory control with sub-requirements that became enforceable on March 31, 2025 alongside the full v4.x transition. Requirement 12.6.1 demands a formal security awareness program making all personnel aware of their role in protecting cardholder data, and Requirement 12.6.3 requires training upon hire and at least once every 12 months. Requirement 12.6.2 adds that programs be reviewed annually and updated to address new cyber threats, which in 2026 includes AI-generated spear phishing that weaponizes public employee information to request cardholder data through convincingly forged executive messages.

Requirement 12.6.3.1 mandates that organizations train employees to detect and respond to phishing and social engineering, both of which arrive through email and target the very payment data the standard was written to protect. Requirement 12.6.3.2 extends training to acceptable use of end-user technologies, with email explicitly in scope, so employees must understand that unprotected email is an unacceptable channel for cardholder data regardless of convenience or deadline pressure.

QSAs now review evidence that goes well beyond completion certificates. They examine whether the curriculum addresses actual payment-security risks, whether personnel rosters include contractors and third-party support staff, and whether employees can articulate what to do when a suspicious message requests cardholder data. The most common gap across assessments is an organization presenting generic annual awareness videos with no content on phishing, social engineering, or acceptable use of the technologies employees rely on daily.

According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed incidents involve a human element. That figure is the reason Requirement 12.6 carries the same weight as the technical requirements surrounding it, since no encryption control addresses the decision that precedes the keystroke.

From Annual Training to Continuous Behavioral Change

Annual compliance training that employees complete once and quickly forget does not satisfy the intent of Requirement 12.6, which frames awareness as an ongoing activity. The standard requires program review at least once every 12 months and updates whenever new cyber threats or vulnerabilities emerge, language that rejects a one-time approach outright.

Measurement is where most programs fall short. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics do not tell the whole story and fail to measure whether a program produces sustained change in employee attitudes and behaviors. Completion rates satisfy an auditor's checklist while revealing nothing about whether a finance team member would refuse an improper PAN transmission.

Continuous, behavior-triggered training closes that gap. When an employee clicks a simulated phishing message designed to harvest payment credentials, that moment becomes the teaching opportunity, delivered immediately in place of a scheduled refresher six months later.

Phishing simulation testing replicates PCI-relevant scenarios such as business email compromise aimed at finance departments and vendor impersonation requesting cardholder data, building recognition skills that static modules cannot replicate. Role-specific content ensures a support agent handling payment calls learns different email protocols than an administrator managing the CDE. These approaches align with the control objectives around personnel awareness more precisely than one-size-fits-all annual training, because they prove through behavioral data that employees can apply what they learned.

How Training Reduces the Human Errors Technical Controls Cannot Prevent

DLP tools scan outbound mail for patterns matching card numbers, and they generate false positives that desensitize security teams while missing cleverly formatted or image-based PANs. Encryption gateways enforce Transport Layer Security, and they cannot stop an employee from copying cardholder data into a personal webmail account to finish a task from home. These are human decisions made under time pressure, and only trained judgment intercepts them.

Employees who understand scope implications are far less likely to email PANs, because they recognize that the act extends the cardholder data environment into unprotected systems and personal inboxes. Training also teaches when and how to activate available encryption tools, turning a technical capability into an operational behavior.

Reporting velocity matters just as much. An employee who accidentally sends an unprotected attachment containing cardholder data and reports it within minutes gives the security team a chance to contain the exposure before it becomes a notifiable breach. That instinct comes from a cybersecurity awareness training program that treats mistakes as learning events in place of punishable offenses, which reinforces the message that silence carries the real risk.

Completion certificates prove attendance while assessors now ask for evidence of changed behavior. Adaptive Security produces that evidence through phishing simulation data and role-specific modules.

Book a demo

Industry-Specific PCI DSS Email Requirements in Hospitality

PCI DSS email requirements look different depending on the industry an organization operates in. In hospitality, where email routinely carries reservation changes, folios, and card authorization forms between guests, staff, and third parties, the gap between operational habit and regulatory obligation is where cardholder data exposure actually happens. PCI DSS v4.0.1 Requirement 3.2.1 mandates that organizations store account data only as long as a documented business justification exists and securely delete it afterward, and generic IT policies rarely address the workflows that make that standard hard to meet.

Reservation Emails, Folios, and Authorization Forms

Hospitality payment workflows generate email-borne cardholder data in predictable patterns. A guest replies to a confirmation message with a full credit card number to modify a reservation, a group sales manager forwards a scanned authorization form to accounting, and a front desk agent attaches a folio PDF to an internal ticket for a billing dispute. Each action creates a new copy of the primary account number (PAN) living in sent items, inboxes, and shared folders.

Card authorization forms represent the highest-risk workflow of the group. When a travel arranger or corporate client emails a completed form containing the card number, expiration date, and cardholder name, the receiving mailbox instantly joins the cardholder data environment. Since PCI DSS prohibits retaining sensitive authentication data after authorization, any verification code transmitted in a message or attached form must be purged from every thread, archive, and backup where it persists.

For hotels processing hundreds of authorization forms monthly, that creates a discovery and deletion challenge most mail systems were never designed to handle. The structural fix is hosted payment pages and secure portals for all reservation modifications and authorization form collection in place of email as the default transport. Where cardholder data appears inadvertently, DLP rules should detect PAN patterns in bodies and attachments, quarantine the message, and trigger guided remediation before it travels further.

Shared Mailboxes, Auto-Forwarding, and Multi-Property Policy Enforcement

Shared mailboxes are operational necessities in hospitality, and they undermine the principle of least privilege that PCI DSS email requirements depend on. When a dozen staff across three shifts access one mailbox holding authorization forms, folio PDFs, and reservation change requests, no one can determine who viewed what, enforce role-based restrictions, or contain a breach to a single account.

Auto-forwarding compounds the risk. Staff forward payment-related threads to personal accounts for after-hours coverage, to outside vendors for event coordination, or to property management for billing resolution, and each forward creates a copy of cardholder data outside the controlled environment. Multi-property and franchise organizations face a harder version of the same problem, since one non-compliant forwarding rule at a single property propagates PANs across the entire mail ecosystem.

Enforcing consistent policy across distributed properties requires centralized control over mailbox configuration. Auto-forwarding should be disabled or tightly restricted at the tenant level, forwarding rule creation should raise an alert, and shared mailbox access should be audited quarterly to remove departed staff and seasonal workers. Franchise and multi-property operators need one standard set of DLP rules, retention policies, and access controls applied uniformly regardless of ownership model, because consistency is what makes audit scope defensible.

Third-Party Vendors and Email Archiving Compliance

Hospitality operations depend on an extensive network of third parties including payment processors, booking platforms, event planners, travel management companies, and managed service providers. Any vendor receiving a message containing cardholder data expands PCI scope beyond direct control. Formal partner agreements must define each party's responsibility for protecting cardholder data, restrict further redistribution, and require incident notification within contractually specified timeframes, since without them a vendor's compromised mailbox becomes the merchant's breach with no clear chain of accountability.

Archiving introduces a parallel challenge. Under Requirement 3.2.1, organizations must implement secure deletion processes that render account data unrecoverable and verify at least quarterly that stored data exceeding the retention period has been purged. For archives containing cardholder data, retention policies cannot be driven by default mailbox behavior or generic e-discovery needs.

Archives must therefore be searchable so PAN-bearing messages can be identified and selectively purged, access to archived mail must be role-restricted and logged, and the deletion process must be documented and verifiable. Preventing cardholder data from entering email at the outset remains the most effective approach, and for the exceptions that slip through, a defensible retention and deletion plan separates a manageable audit finding from a compliance failure. Getting there requires employees who recognize cardholder data in transit and act before it propagates, which makes security awareness training mapped to PCI DSS as essential as any technical control.

Shared mailboxes and forwarding rules scatter card data across properties nobody audits. Adaptive Security trains the front line that handles authorization forms every shift.

Take a self-guided tour

AI Tools, Shadow IT, and Emerging Risks to PCI DSS Email Requirements

When an accounts receivable clerk receives a customer's credit card number by email and pastes it into a generative AI assistant to draft a payment confirmation, cardholder data has just moved to a third-party platform sitting entirely outside the cardholder data environment. It is a direct violation of PCI DSS email requirements, and no email security gateway can detect it. The PCI Security Standards Council has published explicit guidance stating that AI systems should not be trusted with high-impact secrets or unprotected sensitive data, and most organizations lack the controls to enforce that principle at the browser layer where these violations occur.

When Employees Paste PANs Into AI Tools: A New PCI Compliance Vector

The scenario is more common than most compliance officers realize. A customer service agent opens a support message containing a full primary account number (PAN), copies it into a chat assistant to summarize the dispute, and sends the prompt. At that moment, cardholder data has left the CDE and entered a platform where it may be retained for model training, logged in conversation history, or exposed through a future credential compromise.

Industry incident analysis consistently finds employees copying card data from email into AI tools for summarization or response drafting, creating compliance gaps that traditional DLP and cloud access security broker tooling was never designed to detect. The PCI SSC's 2025 AI Principles warn that AI data processing may not be fully contained or constrained within an entity's control, which makes the paste-into-AI workflow a vector most security teams have not yet instrumented.

For organizations subject to PCI DSS, the implications are immediate. Cardholder data transmitted to an unapproved third party constitutes a reportable incident under Requirement 12.10, while the absence of policy controls over AI tool usage creates a gap under Requirement 12.6 and its mandate for personnel awareness training.

The training gap behind that exposure is measurable. According to the National Cybersecurity Alliance's 2025-2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported receiving no training on the security or privacy risks of AI tools, despite 65% now using AI and 43% admitting to sharing sensitive work information with those tools. That gap concentrates risk precisely where visibility is lowest.

How Shadow IT Multiplies Email-Based Cardholder Data Leakage

The AI tool problem is one part of a broader shadow IT exposure. Employees who find corporate email too restrictive for sharing payment data may forward it to personal accounts, upload it to unapproved file-sharing platforms, or paste it into unsanctioned SaaS applications. All of these channels bypass the CDE and leave cardholder data in environments with unknown security postures.

According to IBM's Cost of a Data Breach Report 2025, one in five organizations suffered a breach linked to shadow AI, with those incidents adding as much as $670,000 to breach costs. The same research found that only 37% of organizations have policies to manage or detect shadow AI.

When those organizations also process cardholder data through email, the two risks compound: email becomes the entry point for cardholder data, and shadow IT becomes the path out of the controlled environment. A finance team member who receives a vendor's banking details and PAN by email, then uploads the attachment to a personal cloud storage account for easier access, has created a violation that surfaces only when a breach investigation traces the data path backward.

Browser-level visibility offers a response framework that network-layer tooling was not architected to deliver. Where traditional controls treat AI tools as generic web traffic, browser instrumentation can detect when an employee pastes a 16-digit PAN into a prompt field, signs into an unauthorized SaaS application with corporate credentials, or downloads a mail attachment and uploads it to personal cloud storage. That granularity matters because PCI scoping depends on knowing exactly where cardholder data travels.

Closing the AI Governance Gap for PCI Compliance

This gap exists because awareness programs treat AI tools as a productivity question in place of a data security control. Requirement 12.6 mandates a formal security awareness program making all personnel aware of the importance of cardholder data security, and most programs never teach employees that pasting a PAN into a chat assistant is functionally equivalent to emailing it to an unknown third party.

Technical controls have to close what policy alone cannot. Monitoring that detects sensitive data pasted into AI tools, blocks uploads of cardholder data to unauthorized platforms, and routes risky behavior signals into a cybersecurity awareness training platform creates a closed loop that assessors can verify, satisfying the detection obligation under Requirement 10 and the training obligation under Requirement 12.6 in a single workflow.

The remaining gap sits between what organizations assume their controls cover and what employees actually do in the browser each day. According to IBM's Cost of a Data Breach Report 2025, 97% of organizations that experienced an AI-related breach lacked proper AI access controls, and 63% lacked an AI governance policy altogether. Closing the gap requires visibility at the layer where the violations occur.

Card numbers pasted into a chat assistant leave no trace in any mail log. Adaptive Security surfaces that behavior in the browser and coaches employees at the moment of risk.

Explore the platform

How Adaptive Security Closes the Human Gaps in PCI DSS Email Requirements

Encryption gateways, DLP rules, and masking policies all fail at the same point: the moment an employee decides to paste a card number into a reply, forward a thread containing a folio, or drop an authorization form into a chat assistant. Adaptive Security is built around that moment. The outcome organizations buy is a measurable reduction in the behaviors that pull mail servers, endpoints, and cloud tenancies into the cardholder data environment, evidenced by phishing simulation results and per-employee risk scores in place of completion logs.

That outcome is produced by four capabilities working as one system. Compliance Training delivers pre-built, fully editable PCI DSS modules localized across 39 languages, with HRIS-synced enrollment on day one and audit-ready reporting exportable by framework, employee, or date range. Phishing simulations rehearse the business email compromise and vendor impersonation scenarios that target finance teams, while Cloud Email Security detects and removes AI-generated phishing before it reaches an inbox, connecting via API with no MX record changes.

AI Governance extends the same visibility into the browser, surfacing every AI and SaaS tool in use, flagging personal accounts, and coaching or blocking employees in the moment sensitive data enters a prompt. Because each signal feeds one risk score, a detected phishing attempt, a failed phishing simulation, and a policy violation in the browser all resolve into a single view of where cardholder data is most likely to leak next. That is the evidence a Qualified Security Assessor asks for under Requirement 12.6, produced continuously in place of annually.

Requirement 12.6 now demands proof that behavior changed, and no encryption control can supply it. Adaptive Security generates that evidence across training, phishing simulations, email, and the browser.

Book a demo

Frequently Asked Questions About PCI DSS Email Requirements

Does PCI DSS Apply to Credit Card Data Sent or Received via Email?

Yes. Requirement 4.2 prohibits transmitting unprotected primary account numbers (PANs) through end-user messaging technologies, a category that includes email, instant messaging, SMS, and chat. Standard email is an insecure store-and-forward protocol where messages travel through multiple intermediate servers without guaranteed end-to-end encryption, and even TLS-encrypted connections between mail servers protect data only between hops rather than at rest on either endpoint. Sending or receiving unencrypted PANs by email therefore constitutes a violation and expands the cardholder data environment to include every mail server in the transmission chain. The PCI Security Standards Council classifies all end-user messaging technologies as non-compliant channels for unprotected cardholder data transmission.

What Are the Typical PCI DSS Violation Fines per Incident?

Fines can reach up to $500,000 per incident when merchants are found non-compliant following a security breach, according to the Johanson Group analysis cited earlier in this guide, which also documents escalating monthly penalties for ongoing compliance failures and per-record fines tied to breach volume. Merchants additionally face increased transaction fees, mandatory forensic investigation costs, and potential termination of card processing privileges. Fines are assessed per incident, so multiple violations compound quickly, and the acquiring bank determines the specific penalty structure applied. All major card brands enforce their own escalating schedules for sustained non-compliance.

Can Employees Pasting Cardholder Data Into AI Tools Create PCI Compliance Risks?

Yes. When employees paste primary account numbers or other cardholder data into a cloud-based generative AI tool, that data is transmitted to and stored on third-party servers outside the organization's cardholder data environment. This creates an immediate violation because the AI platform becomes an unauthorized recipient of protected data, and it expands PCI scope to a system the organization cannot assess, audit, or control. Employees frequently copy card data directly from email into AI tools for summarization or response drafting, creating gaps that traditional DLP and cloud access security broker tooling was never built to detect. The behavior violates Requirements 4.2, 7, and 12.6 simultaneously.

How Does PCI DSS v4.0 Change Email-Related Requirements Compared to v3.2.1?

PCI DSS v4.0 carries forward the core prohibition on sending unprotected PANs by email under Requirement 4.2 while introducing broader controls that strengthen email security indirectly. The PCI Security Standards Council introduced 64 new requirements in v4.0, with 51 future-dated requirements becoming mandatory on March 31, 2025. The most significant email-adjacent changes include expanded multi-factor authentication mandates for all access to the cardholder data environment, strengthened access control logging, and broader scope validation obligations. Requirement 12.6 now demands that awareness training address phishing and social engineering specifically, a direct acknowledgment that human behavior around email represents a material compliance risk.

Should a Written Information Security Policy Explicitly Prohibit Sending Unencrypted Cardholder Data via Email?

Yes. Requirement 12.1 mandates that every organization maintain a comprehensive information security policy, and Requirement 4.2 requires that the policy explicitly prohibit sending unprotected primary account numbers through email, instant messaging, SMS, chat, and other end-user messaging technologies. A compliant policy must define acceptable use of encryption tools, outline the procedure for handling accidental receipt of cardholder data by email, and specify consequences for violations. The policy must be reviewed annually and acknowledged by all personnel who handle cardholder data. Without that explicit prohibition, an organization cannot demonstrate compliance during an assessment even where technical controls are fully deployed.

A written prohibition satisfies an auditor only when employees can act on it under pressure. Adaptive Security turns PCI DSS policy language into rehearsed, measurable behavior.

Take a self-guided tour