Protect stored account data
Requirement 3 requires organizations to minimize the storage of account data and ensure that any stored Primary Account Numbers (PAN) are rendered unreadable. The core objective is to ensure that if a system is compromised, the stolen data is useless to an attacker.
What it means
The intent of this requirement is to reduce the "attack surface" by eliminating unnecessary data. PCI DSS operates on the principle that the most secure way to protect data is not to store it at all. When business or legal needs necessitate storage, strict technical controls must be applied to prevent unauthorized access.
In practice, this applies to every location where account data may reside, including production databases, backup tapes, log files, and temporary caches. There is a critical distinction between "Cardholder Data" (which can be stored if protected) and "Sensitive Authentication Data" (SAD), such as CVV codes or PINs, which generally must never be stored after authorization.
How to meet it
- Implement a formal data retention policy that defines exactly what account data is stored, where it is kept, and the business justification for doing so.
- Ensure Sensitive Authentication Data (CVV/CVC, full track data) is deleted immediately after authorization; do not store this data even if encrypted.
- Render PAN unreadable anywhere it is stored using strong cryptography with associated key management, one-way hashing of the entire PAN, or truncation.
- Deploy a robust key management system to protect cryptographic keys, ensuring they are stored securely and rotated according to a defined schedule.
- Create automated scripts or processes to identify and purge account data that has exceeded its defined retention period.
- Mask PAN when displayed (e.g., showing only the first six and last four digits) so that only users with a legitimate business need can see the full number.
Evidence an auditor asks for
- A documented Data Retention Policy including schedules for data deletion and disposal.
- Key management documentation, including records of key generation, distribution, and rotation.
- Configuration screenshots or database schemas proving PAN is encrypted, hashed, or truncated at rest.
- Proof of periodic purging (e.g., logs showing the execution of cleanup scripts).
- An inventory of all locations where account data is stored across the environment.
Common pitfalls
- Storing Sensitive Authentication Data (SAD) under the mistaken belief that encryption makes it permissible to keep after authorization.
- Overlooking "hidden" storage, such as PAN appearing in plain text within application logs, error dumps, or email notifications.
- Poor key hygiene, specifically storing decryption keys on the same server or partition as the encrypted data they protect.
- Failing to apply retention policies consistently across all backups and archive systems.