Requirement 3: Protect Stored Account Data
Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection.
This requirement is easy if you don’t store cardholder data, and difficult if you do store it. You should avoid storing cardholder data if at all possible; This will make your PCI compliance much less difficult and much less expensive. Keep in mind that if you store no more than the BIN (first 6-8 digits, per card brand) and/or last four digits of any card primary account number (PAN) then this truncated data doesn’t qualify as cardholder data, so the requirements for encryption don’t apply. Acceptable truncation varies by brand and PAN length. If you need to make recurring payments, many payment service providers offer solutions that allow you to make recurring payments using transaction IDs or payment tokens so that you don’t need to store cardholder data.
The first step of compliance with requirement 3 is to reduce your cardholder data storage as much as possible. Identify all locations in your systems where storage of cardholder data is necessary and establish a data retention and disposal policy that clearly defines exactly what cardholder data is stored (Card number, cardholder name, expiration date, etc.), where it is stored, how long it is stored, and how data exceeding the retention period is securely deleted at least quarterly. Alternatively, if you don’t store cardholder data, your data retention policy can simply be a policy stating that cardholder data storage is not permitted under any circumstances.
If you store cardholder data, it must be rendered unreadable wherever stored (Requirement 3.5.1), and key management procedures (Requirements 3.6-3.7) must be followed, including split knowledge/dual control for manual cleartext key-management operations (3.7.6). Since March 31, 2025, hashed PANs must use keyed cryptographic hashes (Requirement 3.5.1.1); a plain SHA-256 hash of a PAN no longer complies.
Unless you are a card issuer, the storage of card PINs and/or card verification numbers is not permitted after authorization. Any sensitive authentication data retained before authorization completes must be encrypted and retained no longer than necessary (Requirements 3.2.1 and 3.3.2).
Only users with a legitimate business need should be able to access or view stored cardholder data.
Truncated and hashed card numbers must not be stored together as this would give an attacker an advantage to potentially use the truncated number to more easily determine the hashed card number.
Go on to Requirement 4 - Encryption.
Go back to Requirement 2 - Vendor Defaults.