PCI DSS Requirement 3: Protect Stored Account Data
Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection. If an intruder
circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys
and is unusable to that intruder. Other effective methods of protecting stored data should also be considered as potential risk-mitigation
opportunities. For example, methods for minimizing risk include not storing account data unless necessary, truncating cardholder data if full
PAN is not needed, and not sending unprotected PANs using end-user messaging technologies such as e-mail and instant messaging.
If account data is present in non-persistent memory (for example, RAM, volatile memory), encryption of account data is not required. However,
proper controls must be in place to ensure that memory maintains a non-persistent state. Data should be removed from volatile memory once
the business purpose (for example, the associated transaction) is complete. In the case that data storage becomes persistent, all applicable PCI
DSS Requirements will apply including encryption of stored data.
Requirement 3 applies to protection of stored account data unless specifically called out in an individual requirement.
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 first six digits 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. 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 encrypted using secure methods, and key management procedures must maintain dual control access to decryption keys. For more detail, reference requirements 3.4 through 3.6 of the PCI DSS.
Unless you are a card issuer, the storage of card PINs and/or card verification numbers is not permitted after authorization.
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.