Cardholder data protection is the heart of PCI DSS. The standard was created precisely to define how cardholder data must be protected throughout the entire lifecycle: collection, transmission, storage and deletion. Knowing exactly which data falls within the perimeter, which can be stored and with what requirements, is the first step to building a sustainable compliance programme over time.
What cardholder data is: PAN, CVV and sensitive authentication data
PCI DSS distinguishes between cardholder data and sensitive authentication data (SAD). Cardholder data includes the PAN (Primary Account Number), the cardholder's name, expiry date and service code. This data can be stored provided it is protected with strong encryption, truncation, hashing or tokenization and that storage is justified by a documented business requirement.
Sensitive authentication data is a distinct category with much more restrictive requirements: the CVV/CVC (the three or four digit code on the back of the card), complete magnetic stripe data, EMV chip data and PINs. This data can never be stored after authorisation is complete, regardless of the form it is in, encrypted or not. Violation of this rule is one of the most frequent causes of security incidents in payments.
PCI DSS obligations for those storing cardholder data
Anyone who decides to store cardholder data automatically enters the cardholder data environment perimeter and must comply with all Objective 3 requirements of PCI DSS: documented retention policy, encryption of PANs at rest with approved algorithms (AES-256 is the standard), secure management of cryptographic keys and procedures for secure deletion of data when no longer needed. The PAN must never be stored in cleartext in system logs, temporary files, database dumps or other unprotected repositories.
Encrypted card storage is not sufficient alone: encryption is effective only if key management is equally secure. The standard requires separation of roles between those managing data and those managing keys, periodic key rotation, key escrow procedures and complete audit trails of every cryptographic operation. Building and maintaining this system internally has significant costs both technically and organisationally.
How tokenization eliminates the problem at the root
Tokenization resolves the problem structurally: if the PAN is never stored in your infrastructure, there is no perimeter to protect for that component. The token returned by PCI Proxy EU is an opaque reference with no cryptographic value derivable from the real PAN. Systems that only see tokens do not fall within the CDE for the data storage part and can be managed with normal IT security controls.
This does not mean that tokenization eliminates all PCI obligations: systems that send the PAN to the vault before tokenization, those that receive the PAN for authorisation and access control components to the vault remain in scope. But the overall surface is drastically reduced, applicable requirements are less onerous and the path to compliance becomes manageable even for organisations without a dedicated security team.
Frequently asked questions
Can the CVV be stored after a purchase?
No, never. The CVV (and any SAD data) cannot be stored after authorisation is complete. This is one of the few PCI DSS rules without exceptions: there are no compensating measures that allow keeping the CVV in encrypted form. If found in backups or logs, it constitutes an immediate violation. The only solution is not to collect it persistently.
Is the cardholder's name considered sensitive PCI data?
The cardholder's name falls within cardholder data but not sensitive authentication data. It can be stored, but only if associated with a protected PAN and with appropriate security measures. If stored independently, without the associated PAN, its compliance impact is very limited. However, it is not good practice to keep it beyond what is necessary for documented business purposes.
What should I do if I find PANs in my backups?
Finding PANs in cleartext in backups is a security incident requiring immediate response. The steps are: isolate the affected backups, notify your acquirer and security manager, conduct an exposure risk assessment and proceed with secure deletion. If data has potentially been exposed, notification obligations to schemes and, in Europe, to the Data Protection Authority may be triggered. Better to prevent with periodic PAN discovery in systems.
Zero cardholder data in your environment: the simplest solution is not to store it. Discover PCI Proxy EU.