Requirement 3 of PCI DSS asks you to protect any card data you store, and to store as little as you can. If you keep full card numbers, they must be unreadable wherever they are stored, using strong encryption, index tokens, truncation, or keyed hashing, and the encryption keys must be carefully managed. Sensitive authentication data, such as the security code on the back of the card, PINs, and full magnetic stripe or chip data, must never be kept after a payment is authorized. The easiest way to meet Requirement 3 is to not store card numbers at all.
What is the difference between cardholder data and sensitive authentication data?
Cardholder data is the card number (the primary account number, or PAN), plus the cardholder name, expiration date, and service code when they are stored with it. Sensitive authentication data is what proves the card is present or authorizes a payment: the full track data from the magnetic stripe or chip, the card verification code (the three or four digits printed on the card), and PINs or PIN blocks. Requirement 3.3.1 says it must not be kept after authorization, even if it is encrypted. Card issuers and companies that support issuing services are the only exception, under Requirement 3.3.3.
How do I avoid storing card numbers at all?
Let your payment provider hold them. Most providers offer tokens: you store a reference to the card instead of the card number, and send the token back to the provider when you need to charge the card again. Hosted payment pages and payment iframes go further, because the card number never touches your systems at all. If you go this way, look for the places card numbers sneak in anyway: support emails, call recordings, notes fields, spreadsheets, and old database backups. Your data retention policy can then simply say that storing card data is not allowed.
What does a data retention policy need to cover?
Requirement 3.2.1 says that if you keep any account data, you keep only what you need, under a retention policy that defines what is kept, where, for how long, and the legal, regulatory, or business reason for keeping it. At least once every three months, you must find any stored card data past its retention period and confirm it was securely deleted or made unrecoverable. Since 31 March 2025, this also covers sensitive authentication data held before a payment is authorized, and Requirement 3.3.2 says that data must be encrypted with strong cryptography if it is stored electronically.
Is masking the same as truncation?
No. Masking hides digits on the screen, but the full number is still stored. Requirement 3.4.1 says only people with a legitimate business need may see more than the BIN (the first six or eight digits) and the last four. Truncation permanently removes digits from the stored number. The card brands set how many digits may remain, and it is never more than the BIN and the last four. Properly truncated numbers are not treated as full card numbers, so the encryption rules don't apply to them. Since 31 March 2025, Requirement 3.4.2 also says staff using remote access tools must be technically prevented from copying or moving card numbers, unless they are explicitly authorized to.
How must stored card numbers be protected?
Requirement 3.5.1 says a stored card number must be unreadable anywhere it is stored, including backups and logs. The accepted methods are a one-way hash of the whole number based on strong cryptography, truncation, index tokens, or strong encryption with proper key management. Since 31 March 2025, Requirement 3.5.1.1 says those hashes must be keyed cryptographic hashes, such as HMAC with a secret key, so a plain SHA-256 hash of a card number no longer complies. Card numbers are short and predictable enough that an unkeyed hash can be guessed. If you keep both a hashed and a truncated version of the same number, you also need controls so the two can't be matched up. And since the same date, Requirement 3.5.1.2 says disk or partition encryption on its own is only enough for removable media. On a server's fixed disks, card numbers need another method from 3.5.1 as well.
What does key management involve?
Encryption is only as strong as the protection on its keys. Requirements 3.6 and 3.7 ask you to restrict access to keys to the fewest people necessary, store them in protected form and in as few places as possible, and document the full key lifecycle. That covers generating strong keys, distributing and storing them securely, changing them at the end of their set lifetime (the cryptoperiod), retiring or replacing them if one may have been compromised, and preventing unauthorized substitution. Where anyone handles cleartext key parts by hand, Requirement 3.7.6 asks for split knowledge and dual control, so no single person knows the whole key.
How does an ASV scan relate to Requirement 3?
An ASV scan doesn't look inside your databases, so it can't tell you whether stored card numbers are encrypted. What it does check is the internet-facing systems standing in front of that data, looking for the unpatched software and exposed services an attacker would use to reach it. ServerScan is a PCI Approved Scanning Vendor, and our quarterly external scans meet Requirement 11.3.2. The pricing page shows what a plan includes. Requirement 4 covers card data while it travels.
Go on to Requirement 4 - Encryption.
Go back to Requirement 2 - Vendor Defaults.