What Is Considered PCI Data: Elements, Storage, and Penalties

PCI data is any information the Payment Card Industry Data Security Standard (PCI DSS) protects, and it comes in two categories: cardholder data, which is built around the Primary Account Number (PAN) and its associated details, and sensitive authentication data, which covers the values used to verify a card during a transaction. What is considered PCI data matters because the two categories carry very different rules. Cardholder data can be stored if it is properly protected. Sensitive authentication data generally cannot be stored at all once a transaction is authorized.¹

Cardholder Data

The Primary Account Number is the trigger. Whenever the full PAN is stored, processed, or transmitted, it is cardholder data and falls under PCI DSS protection.¹ Three other elements become cardholder data when they appear alongside the PAN:

Cardholder name — the full name printed on the card or tied to the account.
Expiration date — the month and year the card expires.
Service code — the three- or four-digit value on the magnetic stripe or chip that tells the terminal what kind of transaction the card supports (international use, PIN requirements, and so on).

A name or an expiration date sitting on its own is not PCI data. Paired with a PAN in the same record, file, or system, the whole record is in scope. That is where a lot of businesses miscount: they focus on the card number and forget that a customer profile holding name, expiration date, and PAN is fully covered.

Display and Storage Rules for the PAN

When the PAN is shown on a screen, receipt, or report, it must be masked so that no more than the first six and last four digits appear. Employees with a documented business need can be given access to the full number, but those exceptions are meant to be rare.² Card brand rules often go further for point-of-sale receipts, which typically show only the last four digits.

If you store the PAN, you must render it unreadable wherever it sits. Acceptable methods include one-way cryptographic hashing, truncation (permanently removing a segment of the number), index tokenization with securely stored pads, and strong encryption with proper key management.² “Strong cryptography” under PCI DSS means an industry-tested algorithm with at least 112 bits of effective key strength; AES, RSA, and elliptic curve cryptography all qualify.¹ Password-protecting a spreadsheet does not come close.

Sensitive Authentication Data

Sensitive authentication data (SAD) is the more tightly restricted category. It covers the values that prove, during the transaction itself, that the person presenting the card is legitimate:

Full track data — everything stored on the magnetic stripe or its chip equivalent. This stream contains what is needed to clone a card.
Card verification codes — the three- or four-digit values known as CVV2, CVC2, CVN2, or CID, printed on the back of most cards and on the front for American Express.
PINs and PIN blocks — the personal identification numbers used to authorize debit and ATM transactions, plus the encrypted PIN blocks transmitted during processing.

The rule for SAD is short: you cannot store it after authorization.¹ Encryption does not change that. A narrow exception exists for card issuers and companies that directly support issuing services, and even they need documented business justification. For everyone else, a forensic scan that turns up CVVs or track data on your servers is a serious finding.

The reasoning is practical. A stolen PAN can be used for some fraud, but the damage is contained. Add SAD, and a criminal can clone physical cards, defeat card-not-present checks, and empty accounts through ATMs. Never storing SAD is the single biggest thing a merchant can do to limit breach damage.

When Non-Payment Data Becomes PCI Data

Home addresses, phone numbers, and email addresses are not PCI data on their own. Store them in the same database, file, or system as the PAN, and they sit inside the cardholder data environment and inherit PCI DSS protections.³

Take a customer table that holds names, addresses, phone numbers, and card numbers together. The whole database is in scope. Every system that connects to it, every user who can query it, and every backup that copies it must meet PCI standards. Add Social Security numbers to that same table and you have built a target that enables both payment fraud and identity theft in one breach.

The design lesson is to keep payment data separate from everything else. If your CRM does not need the PAN, do not put the PAN there. Shrinking the number of systems that touch cardholder data shrinks the cardholder data environment and simplifies everything about compliance.

Where PCI Data Actually Lives

A good chunk of PCI work is finding every place cardholder data has ended up. You cannot protect what you have not mapped. The cardholder data environment covers every person, process, and technology component that stores, processes, or transmits cardholder data, plus anything connected to those components.

Digital Systems

Obvious locations include payment databases and the servers behind checkout. Less obvious ones include log files that accidentally captured full card numbers, temporary files created during batch processing, development or staging environments loaded with production data, and cloud storage buckets holding an old customer export. Point-of-sale terminals are the first place card data enters a brick-and-mortar business and remain a common skimming target.

Cloud and Container Environments

Cloud environments that process or store cardholder data require isolation equivalent to physical network separation. In a shared, multi-tenant setup, your environment must be fully isolated from other tenants, with no shared access paths, no comingled data stores, and no hypervisor-level cross-talk. If segmentation cannot be verified, the multi-tenant environment could be pulled into scope for every customer hosted there. Providers should test segmentation between tenants at least every six months and share the results. Container-based workloads need strong network and administrative isolation, and where an orchestration platform cannot guarantee it, separate clusters are safer.⁴

Call Recordings

Call centers create a data-classification problem that is easy to miss. If a customer reads their card number and CVV over the phone and the call is recorded, that recording holds both cardholder data and sensitive authentication data. Storing SAD in any queryable digital audio format after authorization violates PCI DSS, encryption included. Where technology can pause recording during payment capture, it should be enabled.⁵

If the recording system cannot block audio capture, CVV data must be deleted from the recording once stored, and any PAN captured must be rendered unreadable with strong encryption. The PCI SSC also recommends against playing back recordings containing payment card data over a speakerphone.⁵

Paper Records

Paper receipts, old carbon-copy card imprints, handwritten order forms, and printed transaction logs count as cardholder data if they contain the PAN. They tend to pile up in storage rooms, filing cabinets, and desk drawers where no one is thinking about data security. Federal rules under the Fair and Accurate Credit Transactions Act require reasonable disposal of consumer information, including burning, pulverizing, or shredding so the information cannot be read or reconstructed.⁶ PCI DSS adds its own rule: keep cardholder data only as long as a legitimate business, legal, or regulatory purpose demands, and destroy it securely when that purpose ends.²

Retention and Minimization

The most effective way to reduce PCI risk is to stop storing data you do not need. PCI DSS requires a data retention and storage policy that limits both the volume of cardholder data and how long it is kept to what is genuinely required for business, legal, or regulatory purposes, with procedures for secure disposal once the retention window closes.²

In practice, that means questioning every system that touches card data. Does the customer database really need the full PAN, or would a truncated version or token do for reference? Are transaction logs kept longer than the processor requires? Do old backups still contain PANs that should have been purged? Every location eliminated from scope is one fewer place an attacker can find payment data.

Third-Party Processors Do Not Take Over the Obligation

Using Stripe, Square, or any other third-party processor does not hand off PCI compliance. The PCI SSC is direct: using a third-party service provider does not relieve you of ultimate responsibility for your own compliance or for the security of cardholder data in your environment.⁷

Outsourcing can shrink the requirements you handle directly. A fully hosted payment page where your systems never touch card data cuts the burden significantly. You still have to manage the relationship. PCI DSS requires written agreements with each service provider acknowledging their responsibility for securing cardholder data, and merchants must monitor each provider’s PCI DSS compliance status at least annually.⁷ If a provider has not validated its own compliance, its environment can be pulled into your assessment, which defeats the point of outsourcing. Map which PCI DSS requirements the provider covers and which stay with you, and put that split on paper.

What Non-Compliance Costs

PCI DSS is a contractual standard, not a federal statute. It was created and is maintained by the PCI Security Standards Council, founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa.⁸ Enforcement flows through card networks and acquiring banks, which write PCI obligations into merchant agreements. Some states have enacted laws that reference PCI DSS, and after a breach plaintiffs’ lawyers routinely cite PCI failures as evidence of negligence.

Card brands can levy fines against acquiring banks, which pass the costs to merchants. Fines can reach up to $500,000 per incident for a breach at a non-compliant merchant. A non-compliant merchant can also lose the ability to accept card payments, which for most businesses ends the business.

After a breach, exposure runs well past the initial fine. Card brands typically require the compromised merchant to hire a PCI Forensic Investigator, at the merchant’s expense.⁹ Issuing banks may seek reimbursement for reissuing compromised cards, which can run into the millions across a large breach. Class actions from affected cardholders often follow, with settlements that include long-term credit monitoring. State breach notification laws add further per-violation fines for missing required notice windows.

Low transaction volume is not the same as low risk. Small e-commerce sites make up the majority of merchants and the majority of breaches. A compromised checkout page can expose thousands of card numbers before anyone notices.

1
PCI Security Standards Council. Glossary
2
PCI Security Standards Council. PCI Data Storage Do’s and Don’ts
3
PCI Security Standards Council. At-a-Glance: PCI Security Standards Council
4
PCI Security Standards Council. PCI SSC Cloud Computing Guidelines
5
PCI Security Standards Council. Information Supplement: Protecting Telephone-based Payment Card Data
6
FTC. Disposing of Consumer Report Information? Rule Tells How
7
PCI Security Standards Council. Information Supplement: Third-Party Security Assurance
8
PCI Security Standards Council. About Us – PCI Security Standards Council – Protect Payment Data
9
PCI Security Standards Council. PCI Forensic Investigator (PFI) Program Guide