PCI DSS FAQ Chronicles: To Store or Not to Store Cardholder Data-A Shakespearean Dilemma
Author: Kamran Nagiyev
External Link
storing cardholder data
May 8, 2024
Introduction
The storage of cardholder data stands as a pivotal concern for organizations striving to uphold PCI DSS compliance.
Despite guidelines, due to the complexity and wide variety of business models, cardholder data storage can often be fraught with uncertainty.
To shed light on this critical aspect of compliance, we delve into common questions surrounding cardholder data storage using insights gleaned from PCI SSC FAQs.
Cardholder Data and PCI DSS
Cardholder data refers to sensitive information associated with a credit or debit card. It's crucial for processing payments but needs robust security measures due to its sensitive nature. The Payment Card Industry Data Security Standard (PCI DSS) v4 dictates how organizations must handle this data.
In my previous article, you will find detailed information on CHD and its storage requirements as per PCI DSS v.4:
To summarise PCI DSS v.4 storage rules:
PAN and Additional Data:
- Secure Storage: The data must be stored on secure systems with encryption at rest and in transit (using strong cryptography, e.g., AES 256).
- Limited Access: Only authorized personnel with a business need should have access to the data.
- Regular Monitoring: Implement measures to detect and prevent unauthorized access to cardholder data.
Sensitive Authentication Data (SAD): PCI DSS v4 has stricter rules for SAD compared to PAN and additional data.
Examples of SAD:
- Card Verification Value (CVV) or Card Security Code (CSC)
- Personal Identification Number (PIN)
- Magnetic stripe data (for cards with magnetic stripes)
PCI DSS v4 prohibits storing SAD after authorization. This means you cannot keep the CVV, PIN, or magnetic stripe data on your systems once the transaction is approved.
As an issuer, handling the storage of Sensitive Authentication Data (SAD) is a distinct topic that requires meticulous attention to compliance and security measures.
FAQ 1533
Myth: Storing SAD after authorization, even without PANs, is safe.
Answer: PCI DSS prohibits SAD storage post-authorization regardless of PAN presence. Retaining SAD like CVVs or PINs increases risk and compromises transaction integrity. Even environments without PANs must not store SAD.
FAQ 1280
Myth: Storing CVCs for recurring transactions is permitted with customer consent.
Answer: PCI DSS Requirement 3 prohibits CVC storage post-authorization under any circumstance. Customer consent does not override this prohibition.
FAQ 1574
Myth: Organizations offering software on devices can store CVCs.
Answer: PCI DSS forbids CVC storage even by software on smartphones or laptops. The rule applies regardless of transaction status or user consent.
FAQ 1318
Myth: There's a defined maximum duration for storing cardholder data.
Answer: PCI DSS requires a data retention policy but does not specify a maximum period. SAD must never be stored post-authorization.
FAQ 1042
Myth: Cardholder data must be encrypted in memory.
Answer: PCI DSS does not require encryption in RAM. However, data must be removed promptly after business use and memory should not persist data beyond its use.
FAQ 1210
Myth: Audio recordings are exempt from SAD rules.
Answer: Audio recordings containing SAD (e.g., CVV) must be securely deleted post-authorization. If not feasible, compensating controls must be validated annually.
FAQ 1139
Myth: Faxing payment card data is always PCI DSS compliant.
Answer: PCI DSS permits faxing over PSTN without encryption, but systems must protect the data, especially if stored or processed digitally. Internet-based faxes require encryption and secure storage practices.
Conclusion
While the storage of cardholder data remains a complex terrain to traverse, clarity can be attained through diligent adherence to PCI DSS guidelines and leveraging insights from PCI SSC FAQs. As organizations strive to safeguard sensitive cardholder information, proactive measures guided by industry standards and best practices will be instrumental in achieving robust data security frameworks.