Does Tokenization Remove Data From PCI DSS Scope?

It can. If the token cannot be reversed to the original PAN without the token vault, the token itself is not account data, and systems handling only that token can fall outside Requirement 3's scope.

Does Requirement 3 Apply to Backup Data?

Yes. Stored PAN in backups, logs, and archives must be minimized, masked, and rendered unreadable using the same controls as production data.

Can You Store the Card Verification Code If It Is Encrypted?

No. Sensitive authentication data, including the card verification code, cannot be retained after authorization under any circumstances, encrypted or not.

PCI DSS Requirement 3 Explained: How to Protect Stored Cardholder Data

TL;DR

PCI DSS Requirement 3 governs stored account data: minimize what you keep, never retain sensitive authentication data after authorization, and render stored PAN unreadable through hashing, truncation, tokenization, or strong cryptography.
Full disk or partition-level encryption alone does not satisfy Requirement 3 for non-removable media under PCI DSS v4.0.1. Pair it with another approved method or reserve it for removable media.
Every key protecting stored cardholder data needs documented generation, distribution, storage, and retirement procedures under Requirements 3.6 and 3.7.

PCI DSS Requirement 3 governs how organizations protect stored account data: the primary account number, cardholder name, expiration date, and sensitive authentication data tied to a payment card. It matters because stored data is the highest-value target in a breach. If an attacker cannot read or use stored PAN, a successful intrusion produces nothing they can monetize.

Requirement 3 sits inside the second control objective, protect account data, alongside Requirement 4, which covers data in transit. It breaks down into several themes: minimizing what you store, never retaining sensitive authentication data after authorization, masking PAN on display, rendering PAN unreadable in storage, and protecting the keys behind that last control. A PCI QSA tests every one of these areas during an assessment.

What Cardholder Data Can You Store, and For How Long?

You can only store cardholder data that serves a defined legal, regulatory, or business need, and only for as long as that need exists. Requirement 3.2.1 requires a documented retention and disposal policy limiting storage to that minimum.

In practice, that means running a formal process, automated or manual, to identify and securely delete PAN that has exceeded its retention period, verified at least every three months. Paper records should be physically destroyed, and electronic records purged using secure deletion methods rather than a standard file delete. Governance leaders building this policy should involve legal and finance early, since retention needs often come from outside the security team.

Why Can You Never Store Sensitive Authentication Data After Authorization?

PCI DSS prohibits storing sensitive authentication data, including full magnetic stripe or chip-equivalent data, the card verification code, and the PIN or PIN block, after authorization completes, even if that data is encrypted.

This rule is strict because sensitive authentication data is exactly what an attacker needs to create counterfeit cards or authorize fraudulent transactions. Requirement 3.3.1 requires that any such data captured for authorization is rendered unrecoverable once authorization finishes. Issuers and companies supporting issuing services are the narrow exception, and even then storage must be limited to a legitimate business need. Organizations running PCI PIN programs will recognize this control, since PIN data faces the same rule.

How Should You Mask and Display the Primary Account Number?

PAN must be masked when displayed, showing no more than the BIN and the last four digits by default, under Requirement 3.4.1. Anyone who needs to see more must have a documented, legitimate business need.

This applies everywhere PAN might appear on a screen, from customer service tools to internal dashboards and printed receipts. Requirement 3.4.2 adds a related control: when personnel use remote-access technologies, technical controls must prevent copying or relocating PAN to local drives or removable media, unless explicitly authorized for a defined business reason.

What Are the Approved Methods for Rendering Stored PAN Unreadable?

Requirement 3.5.1 allows four approaches: one-way hashes based on strong cryptography covering the entire PAN, truncation, index tokens, or strong cryptography with associated key management. Older v3.2.1 language paired index tokens with securely stored pads; v4.0.1 simplified this to index tokens alone.

If your organization uses hashing, PCI DSS v4.0.1 clarified that it must be a keyed cryptographic hash rather than a simple hash, with the key managed under Requirements 3.6 and 3.7. Full requirement language is available through PCI SSC’s PCI DSS standard page and its Document Library. Tokenization works differently: it replaces PAN with a surrogate value with no mathematical relationship to the original number. Where that token cannot be reversed without the token vault, it is not considered account data, which can remove systems that handle only the token from PCI DSS scope.

Why Isn’t Full Disk Encryption Enough on Its Own?

Disk-level or partition-level encryption only satisfies Requirement 3.5.1 on its own for removable electronic media. For non-removable media, like the database server above, it must be combined with another approved method, such as file, column, or field-level encryption.

The reason is access control. If the same credentials that log into the operating system also unlock the encrypted volume, anyone with system access can read the PAN in plaintext, defeating the purpose of encryption. Requirement 3.5.1.3 requires that logical access to disk-encrypted data be managed independently of native operating system authentication, such as not relying on local user account databases.

How Should You Manage the Encryption Keys That Protect Cardholder Data?

Every key used to protect stored account data needs documented procedures covering its entire lifecycle: generation, secure distribution, storage, periodic rotation, and retirement, under Requirements 3.6 and 3.7.

Keys should be stored in as few locations as possible, restricted to the fewest necessary custodians, and protected through methods such as encryption under a stronger key-encrypting key, storage inside a secure cryptographic device like an HSM, or splitting the key into components under dual control. Organizations running PCI P2PE programs will recognize these controls, since key management is exactly where those standards, and the newer PCI KMO standard, overlap with Requirement 3.

Requirement 3 works best as an ongoing discipline rather than a one-time encryption project, since data minimization and key management both require continuous upkeep. Structured PCI DSS compliance support can help turn these controls into a year-round program instead of a rebuild before every audit.

Not sure where cardholder data lives across your environment? Talk to Ampcus Cyber’s PCI compliance team.