Cardholder data (CHD) is the payment card information PCI DSS exists to protect: the primary account number (PAN) on its own, or the PAN together with the cardholder's name, expiration date, or service code. Any system that stores, processes, or transmits it falls inside the cardholder data environment (CDE) — and inside PCI DSS scope.
What counts as cardholder data?
| Data element | Category | Storage permitted? |
|---|---|---|
| Primary account number (PAN) | CHD | ✓ if rendered unreadable (e.g. strong cryptography, truncation) |
| Cardholder name | CHD (with PAN) | ✓ with protection |
| Expiration date | CHD (with PAN) | ✓ with protection |
| Service code | CHD (with PAN) | ✓ with protection |
| Full track data (magnetic stripe / chip) | SAD | ✗ never after authorization |
| CAV2/CVC2/CVV2/CID security code | SAD | ✗ never after authorization |
| PIN / PIN block | SAD | ✗ never after authorization |
The split matters because the rules differ in kind, not degree: CHD may be stored if properly protected; sensitive authentication data (SAD) generally must not be stored after authorization at all, encrypted or not.
What is the cardholder data environment (CDE)?
The CDE is everything that stores, processes, or transmits CHD or SAD — systems, network segments, people, processes — plus any system with unrestricted connectivity to those. PCI DSS scope follows the CDE, which is why so much compliance engineering is really scope engineering: tokenization, third-party payment processors, hosted fields, and segmentation all exist to keep the PAN out of your own systems and the CDE small. The cost of PCI compliance tracks CDE size more than company size.
Where cardholder data actually leaks from websites
The classic CDE conversation is about databases and networks. The modern loss vector is the payment page itself: e-skimming scripts read the PAN and CVV from form fields in the customer's browser, before the data ever reaches your (or your processor's) servers. The card data is stolen at the only moment it exists in cleartext — while the customer types it.
This is why PCI DSS 4.0.1 pulled the browser into scope. Requirement 6.4.3 demands an authorized, justified inventory of every script on the payment page, and requirement 11.6.1 demands detection when the page the consumer's browser receives is tampered with. Both apply even when card entry happens inside a hosted iframe, because the surrounding page can overlay or manipulate it — the reason QSAs now ask for browser-layer evidence, and what cside's PCI Shield collects from real sessions.
CHD vs PII vs PHI
Cardholder data overlaps with, but is narrower than, personal data generally. A name plus email is PII but not CHD; a PAN is both. In healthcare checkouts the same form can touch CHD and health information simultaneously, stacking PCI DSS obligations on top of HIPAA's tracking rules. The common thread across all three regimes: you cannot protect data you cannot see leaving the page.
