PCI DSS v4 and Marketing Data: Keeping Cardholder Data Out of Your Customer Data Platform (CDP)

PCI DSS marketing data rules reduce to one design principle: keep primary account numbers (PAN) and sensitive authentication data out of your customer data platform (CDP), CRM and marketing database. Store card brand, last four digits and processor tokens instead, segment anything touching the payment flow, and treat payment-page scripts and vendors as in scope. PCI DSS v4.0.1 is the active version, and its future-dated requirements became mandatory on 31 March 2025 24.

Who this is for: security, payment and marketing operations teams that connect payment events to marketing. You get a data-handling table, a scope-reduction comparison, the requirements that matter to martech and a checklist. See also the regulation hub.

PCI DSS v4.0.1 status in 2026

The PCI Security Standards Council (PCI SSC) published v4.0.1 on 11 June 2024 as a limited revision of v4.0: formatting fixes and clarifications, with no additional or deleted requirements 2. v4.0 retired on 31 December 2024, leaving v4.0.1 as the only active version, and the 31 March 2025 effective date for future-dated requirements did not change 2. The Council's library still features v4.0.1 as the standard 1. A request for comments on "the next iteration" of PCI DSS ran from 3 June to 20 July 2026, with no specific changes described in the public post 16, and we found no new version in the Council's blog posts through 15 October 2026 17.

What counts as cardholder data, and what must never reach marketing

PCI SSC defines cardholder data as, at a minimum, the full PAN, which may also come with cardholder name, expiration date or service code. Sensitive authentication data (SAD) is security information used to authenticate cardholders or authorise transactions, such as card verification codes, full track data and PINs or PIN blocks. Account data is cardholder data and/or SAD 12. The cardholder data environment (CDE) is the systems, people and processes that store, process or transmit them, plus components with unrestricted connectivity to those systems 12.

Do not use PAN-derived values as identity-resolution keys; see our notes on identity resolution. Encryption is not an escape hatch: encrypted cardholder data stays in scope if it sits with the key or is accessible to someone with key access 1113.

How card data leaks into customer-data systems

Typical paths: free-text fields (support tickets, CRM notes, chat transcripts); form-field capture by session-replay and tag-manager scripts on checkout; URLs and query strings in event payloads; webhooks and reverse-ETL exports that carry whole payment objects; receipts; and call recordings with spoken card numbers. Controls that work:

• Define an event schema with an allow-list of fields; reject unknown ones.
• Scan at ingestion for PAN-like digit strings (pattern plus Luhn check) and quarantine, redact or reject.
• Keep session replay and ad pixels off payment pages.
• If a PAN lands anyway, treat it as an incident: purge it, find copies in backups, logs and warehouses, and tell your acquirer or assessor.

Scope reduction: tokenisation, truncation and segmentation

PCI SSC's tokenization supplement (version 2.0, August 2011, so it predates v4 and does not replace the standard) sets the principles 14. Components that tokenize or redeem tokens, and anything with access to them, are in scope. Systems storing only tokens may be out of scope when: PAN cannot be recovered from a token; they are segmented from de-tokenization, the vault and keys; they are not in or connected to the CDE; they receive no cardholder data or SAD through other channels; and earlier traces of cardholder data were deleted 14. The Council recommends limiting PAN to the capture point and the vault, removing it from source systems after tokenization, choosing a design where the merchant cannot exchange a token for PAN, separating duties and reviewing token use in the annual scope validation 14.

The Council's September 2024 scoping and segmentation supplement addresses zero trust, micro-segmentation, multi-cloud and asset inventory for ephemeral workloads, and does not supersede the standard 15. A self-hosted or private-cloud platform means the segmentation boundary is yours to draw and prove in your own network, and a single-tenant system such as PrivyCDP can be designed to hold only tokens and truncated values. No customer data platform is "PCI certified" merely by being one: scope follows data and connectivity. See reference architectures and the architecture explainer.

Marketing-stack requirements: scripts, change detection and third parties

Payment-page scripts. The Council's March 2025 supplement says requirements 6.4.3 and 11.6.1 aim to reduce e-skimming through authorising scripts, checking their integrity and monitoring pages for tampering; it does not add or supersede requirements 5. FAQ 1588 says a merchant embedding a provider's payment form must confirm its site is not susceptible to script attacks, either with techniques such as 6.4.3 and 11.6.1 or by getting the provider's confirmation. A provider of non-payment scripts is not a TPSP for SAQ A if the scripts cannot affect cardholder data or SAD 6. Marketing tags on checkout therefore need a justification, an owner and monitoring, or removal.

Vendors. The Council urges ensuring TPSPs support your v4.x transition and using compliant providers to reduce supply-chain risk 3. Treat a martech vendor as a TPSP if it can affect the security of cardholder data (a tag manager on a payment page, a support tool receiving card numbers). If it never touches such data and cannot affect it, document why. FAQ 1601 (November 2025) says evidence an assessor already reviewed stays valid for that assessment, and questions about accepting a provider's Attestation of Compliance go to acquirers or payment brands 18. See also the bank architecture guide.

Scope confirmation. The annual scope exercise (12.5.2) is the moment to list every feed from payment systems into the CDP 3.

PCI DSS marketing data checklist

• Map every flow from payment systems into the CDP, CRM, warehouse and activation tools.
• Confirm no full PAN, card verification code, PIN or track data is stored anywhere in marketing systems.
• Replace card numbers with a processor token, brand and last four (one truncation format).
• Drop PAN-derived hashes and fingerprints as identity keys.
• Enforce an event schema allow-list and a PAN scanner at ingestion.
• Remove session replay and ad pixels from payment pages; justify, own and monitor any script that remains.
• Confirm your SAQ A or other validation path with your acquirer, including scans.
• Segment the CDE from the CDP; validate the segmentation each year.
• Keep a TPSP list with responsibilities and current Attestations of Compliance.
• Re-confirm scope annually and after each new feed.
• Write an incident procedure for PAN found in a marketing system.

To check which of your customer-data flows touch card data and how a customer-owned deployment would be segmented, request a review on the security page; the regulation hub and deadline tracker cover related obligations. Self-hosting is not always the right answer; our self-hosting guide says when it is not.

Confirm validation requirements with your acquirer or a Qualified Security Assessor.