Back to agent
Constraintconstraint.pci-dss-scope-payment-card-data

PCI DSS 4.0.1 — Payment Card Data Scope

Organizations that store, process, or transmit payment card cardholder data (CHD) — or whose systems could impact the security of CHD — enter the PCI DSS scope and must meet 12 requirements (PCI DSS 4.0.1). CDPs and CDWs that receive raw PANs, CVVs, or cardholder data are in-scope. Scope-reduction mechanisms (tokenization, P2PE, hosted payment pages, network segmentation) can remove the CDP/CDW from PCI scope by ensuring CHD never reaches them.

confidence 88%v1reviewed May 8, 2026pci-dss, payment-card, compliance, scope, tokenization, p2pe, pos, ecommerce, regulatory

The Payment Card Industry Data Security Standard (PCI DSS), maintained by the PCI Security Standards Council, applies to any organization that stores, processes, or transmits cardholder data (CHD) — or whose systems can affect the security of cardholder data. PCI DSS 4.0.1 (effective March 2022; supersedes v3.2.1) defines 12 high-level requirements spanning network security, access control, monitoring, vulnerability management, and incident response.

What constitutes CHD. The Primary Account Number (PAN) is the defining element. Any data that contains or is combined with a PAN — cardholder name, service code, expiration date — is CHD. Sensitive Authentication Data (SAD) — full magnetic stripe contents, CVV/CVC, PINs — must never be stored post-authorization even by compliant entities.

When the CDP/CDW enters PCI scope. If raw payment card data (PANs, expiration dates, cardholder names as authorization-context data) flows through the CDP event stream or the CDW, those systems enter PCI scope. A CDP that receives raw POS transaction events including the PAN is in-scope and must meet PCI DSS 4.0.1 in full — a substantial compliance and audit burden that most CDP implementations are not designed to bear.

Scope-reduction for CDP architectures. The recommended architectural pattern is to remove CHD from the CDP/CDW pipeline entirely:

Composable vs. packaged CDP implications. In composable stacks, the CDW is the center of data gravity — if raw POS events (including PANs) are ingested into the CDW for loyalty matching or product affinity analysis, the CDW enters PCI scope. The correct architecture is to tokenize at the POS before CDW ingestion and use the token as the linkage key. In packaged CDPs, the vendor's PCI DSS compliance certification covers the vendor environment — but the organization must verify that CHD sent to the vendor CDP activates the vendor's BAA-equivalent PCI compliance agreement. Most vendor CDP contracts do not include PCI scope by default.

Agent behavior. For any recommendation involving modality.pos or e-commerce payment events, ask: "Does your CDP event stream receive raw PANs or full cardholder data? If so, you are in PCI scope. The standard architectural mitigation is to tokenize at the POS before any data reaches the CDP pipeline."

Sources

Related

← Referenced by

  • governed-bymodality.posPOS transactions are the primary source of payment cardholder data. Any CDP workflow ingesting raw POS transaction data is subject to PCI DSS scope unless CHD is removed before CDP ingestion via tokenization, P2PE, or hosted payment pages.
  • governed-byconcept.modality-complexityModality complexity for multi-channel architectures including POS must account for PCI DSS scope as a first-class governance regime — concept.modality-complexity body explicitly notes 'POS has its own PCI considerations'.