Requirement 3 addresses the core problem that PCI DSS exists to solve: what happens to cardholder data once it has been captured. An attacker who can extract stored PANs from a compromised database has achieved their primary objective. Requirement 3 makes that extraction worthless by requiring that stored PANs be rendered unreadable.
Account Data — The Hierarchy of Protection
PCI DSS distinguishes between different types of account data with different protection requirements. Understanding the hierarchy is essential.
| Data Element | Type | Storage Permitted? | If Stored, Must Be... |
|---|---|---|---|
| Primary Account Number (PAN) | Cardholder Data | Yes, if protected | Rendered unreadable (encrypted, truncated, tokenized, or hashed) |
| Cardholder Name | Cardholder Data | Yes | Protection recommended but not required |
| Service Code | Cardholder Data | Yes | Protection recommended but not required |
| Expiration Date | Cardholder Data | Yes | Protection recommended but not required |
| Full Magnetic Stripe / Track Data | Sensitive Authentication Data (SAD) | NO | Must not be stored after authorization under any circumstances |
| CAV2/CVC2/CVV2/CID (Card Verification Value) | Sensitive Authentication Data (SAD) | NO | Must not be stored after authorization under any circumstances |
| PIN / PIN Block | Sensitive Authentication Data (SAD) | NO | Must not be stored after authorization under any circumstances |
| KEY IDEA | The prohibition on storing SAD (sensitive authentication data) is absolute — there are no exceptions for any reason. This includes track data, CVV/CVC values, and PINs. The word "after authorization" is key: some issuers store SAD during the authorization process, but must delete it immediately after. Merchants and service providers must never store SAD at all. |
Rendering PANs Unreadable — The Four Methods
Strong Cryptography (Encryption)
Encrypt stored PANs using industry-accepted strong cryptography. AES-256 is the standard. The key management requirements are extensive — key generation, distribution, storage, access control, replacement, and destruction are all covered by Requirement 3. Cryptographic keys must be stored separately from the data they encrypt and must be protected by a key-encrypting key (KEK).
Truncation
Display or store only a portion of the PAN — typically the first six and last four digits. A truncated PAN (e.g., 4111 1111 XXXX 1111) has no value to an attacker. Truncation is the simplest approach and is commonly used for receipts, logs, and display purposes. Truncated PANs are not considered cardholder data for PCI DSS purposes.
Tokenization
Replace the PAN with a non-sensitive substitute (token) that can be used in internal systems without the risk of exposing the real PAN. The tokenization vault — which maps tokens back to real PANs — is itself in scope for PCI DSS, but all systems that use only tokens are typically out of scope.
One-Way Hash (with key)
Hash the PAN using a keyed cryptographic hash function (HMAC) — a one-way transformation that prevents the original PAN from being recovered. The hash must be salted and keyed; plain SHA-256 without a key is not sufficient for PANs because PANs are a known, limited namespace that can be brute-forced.
Key Management — The Critical Dependencies
Cryptographic protection of PANs is only as strong as the key management program that protects the encryption keys. PCI DSS Requirement 3 contains extensive key management requirements. Key management failures are a common finding.
| Key Management Lifecycle Stage | PCI DSS Requirement | Common Controls |
|---|---|---|
| Key Generation | Use cryptographically strong random number generation; document the method | HSM-based key generation, NIST SP 800-133 guidance |
| Key Distribution | Keys must be distributed securely and with split knowledge | Key-encrypting keys, HSM key injection, key ceremony documentation |
| Key Storage | Keys must be stored separately from data and encrypted under a KEK | HSM storage, encrypted key stores, access control |
| Key Retirement/Replacement | Cryptoperiods defined; keys rotated at least annually or on suspected compromise | Key rotation schedule, replacement procedures |
| Key Destruction | Documented procedure for secure key destruction | Key zeroization, destruction certificates |
| Access Control | Access to cryptographic keys restricted to the fewest custodians necessary | Role-based access, dual control for sensitive key operations |
| IMPORTANT | Hardware Security Modules (HSMs) are the gold standard for key management. HSMs provide tamper-resistant key storage and perform cryptographic operations without exposing keys in plaintext. For Indonesian payment organizations processing significant card volumes, HSM-based key management is increasingly expected by QSAs — and required for organizations operating as payment processors or acquiring banks. |
The PAN — Finding Where It Lives
Before you can protect stored PANs, you must find them. Many organizations have more PAN storage than they realize — in development databases, log files, backups, error logs, email bodies, spreadsheets, and third-party analytics tools. Data discovery is a prerequisite for Requirement 3 compliance.
| In every PCI DSS gap assessment we conduct, we find PANs in at least one unexpected location — most commonly in application log files where debug logging was left enabled, and in development or test databases seeded with production data. The first step of Requirement 3 compliance is always a structured data discovery exercise, not encryption implementation. |
Documenting and Evidencing Requirement 3
What QSAs look for: data retention policy covering account data, inventory of all locations where account data is stored, documentation of the rendering method used (with algorithm and key management for encryption), key management procedures, results of data discovery exercises, evidence of SAD non-storage.