Skip to Main Content
March 25, 2025

PCI DSS Payment Card Data Retention

Written by Chris Camejo
PCI Assessment

Table of contents

The Payment Card Industry Data Security Standard (PCI DSS) applies to and has specific requirements for retention of Account Data. In general, organizations must retain as little Account Data as they can for as short a time as possible.

Account Data includes two (2) categories:

  • Cardholder Data (CHD):
    • The card number, which is referred to as Primary Account Number (PAN) within PCI DSS
    • Expiration date
    • Service code
    • Cardholder name
  • Sensitive Authentication Data (SAD):
    • CVV code
    • PIN block
    • Full magstripe data
    • Chip equivalent of full magstripe data

There are also some best practices, described below, to render parts of the CHD out of scope for PCI DSS while it is retained for a longer time period to allow the rest of the Account Data that remains in scope for PCI DSS to have a shorter retention period.

Account Data Retention Requirements

PCI DSS v4.0.1 requirement 3.2.1 is what organizations must adhere to for retention and reads as follows:

Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:

  • Coverage for all locations of stored account data.
  • Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization.
  • Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
  • Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
  • Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
  • A process for verifying, at least once every three (3) months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

The first step in meeting this requirement is to understand the required retention time as per the third bullet point above:

  • Check with the legal department to see what legal or regulatory frameworks apply to retention of Account Data and what parts of the Account Data they apply to.
  • Check with business process owners to determine how long they need to retain Account Data for whatever it is they’re doing with it and what parts of the Account Data they need to retain.

Whichever of these requires longer retention is the maximum allowable retention period. Keep in mind that legal, regulatory, and/or business requirements may require retention of some parts of the Account Data without requiring retention of other parts, which can help reduce the PCI DSS scope as described below.

Once an organization has determined its retention period, it must document the legal, regulatory, or business requirements that necessitate keeping the Account Data for the defined retention period to meet the fourth bullet point. Remember that a QSA or forensic investigator may look at these justifications if the organization requires a Report on Compliance or suffers a breach.

This requirement calls for policies and procedures, so it’s not enough to just delete the data when it’s no longer needed. Write up a policy that explicitly addresses how each of the requirement’s bullet points will be met, and then create step-by-step procedure documents that instruct personnel how to securely delete or otherwise render the data unrecoverable and how to perform the periodic verification process described in the last bullet point.

In addition to all of the above, organizations must never store SAD after a transaction is authorized, as per PCI DSS v4.0.1 requirement 3.3 and its sub-requirements. The only exception to this is for issuers and legal or regulatory requirements, but I’ve never seen any legal or regulatory requirement to retain SAD. There is no other allowable justification for storing SAD after authorization.

Data Reduction Techniques

Just because your organization needs to retain some data about a transaction for legal, regulatory, or business process reasons doesn’t mean in-scope Account Data must be kept.

Whether information is considered CHD and in scope for PCI DSS is primarily driven by the presence of the full PAN (even if encrypted) in the environment. An organization can render the remaining parts of the CHD out of scope for PCI DSS and its retention requirements if it either separates that data from the PAN or renders the PAN unrecoverable (described in detail below). Organizations should use these techniques whenever possible to minimize the number of locations in the environment where full PANs are stored, minimize the number of full PANs stored in the environment, and minimize the retention periods of stored PANs.

I’ve never come across any legal or regulatory requirement to retain a PAN. Most legal and regulatory requirements related to transactions only require retaining the date, amount, customer name, and what was purchased.

Most routine business processes don’t require keeping a PAN either. Merchants often blame recurring transactions, 'card on file', and chargebacks as reasons for retaining the PAN (and sometimes SAD), but none of these require the PAN if the initial transaction is set up correctly.

  • A card can be authorized with a ‘recurring’ flag set, which allows the authorization number to be hit for future transactions (regularly scheduled or ad hoc) without retaining the PAN.
  • Similarly, chargebacks can be conducted using just the authorization number.
  • Some processors will provide token codes rather than authorization numbers, which can be used as well.

Keep in mind that SAD must never be stored after authorization. If a business process requires retaining SAD, then there is something wrong with the business process that must be fixed to be compliant with PCI DSS.

Separating Other Account Data From PAN

Per PCI DSS scoping rules, the cardholder name, service code, and expiration date are only considered in-scope Account Data when they are in the same environment as the PAN. For example, if an organization moves the cardholder name from a payment processing system to a financial record retention system that is properly isolated from the payment processing system, then that cardholder name is no longer Account Data, is no longer in scope for PCI DSS, and is no longer subject to any PCI DSS requirements (including the retention requirement). 

If an organization needs to retain some parts of the Account Data but not the PAN, I recommend keeping the PAN in as few places as possible and moving all other data that must be retained to a separate environment to keep the PCI DSS scope small and retention requirements for PANs short while still meeting legal/regulatory requirements or business needs.

Rendering PANs Unrecoverable

Some business processes may need a way to uniquely identify a payment card or transaction but don’t need to retain the PAN itself. PCI DSS does not consider PANs that have been rendered unrecoverable to be in-scope Account Data; the main techniques to render PANs unrecoverable while still uniquely identifying them are:

  • Hashing using a strong keyed cryptographic one-way hash algorithm on the entire PAN (Note: These must be keyed cryptographic hashes as per requirement 3.5.1.1.)
  • Truncation by removing all but the Bank Identification Number (BIN), which is the first six (6) to eight (8) digits and last four (4) digits of the PAN
  • Tokenization, where another non-sensitive unique value is used to identify a specific PAN or transaction

The unrecoverable version of the PAN can be handled in other environments without imparting any PCI DSS compliance obligations on those environments, even if the unrecoverable PAN is accompanied by other elements of what would be considered CHD when associated with a PAN (e.g., cardholder name, expiration date). 

Do not store both hashed and truncated PANs because a truncated PAN can be used to easily recover the hashed PAN. Additional controls will be necessary to mitigate this threat if both hashed and truncated PANs are stored as per requirement 3.5.1.

Using an encryption algorithm that allows the data to be decrypted is considered “unreadable”, not “unrecoverable”. Encrypted account data remains in scope if the organization has access to both the encrypted data and the decryption key as per section 4 of the PCI DSS. This type of encryption is only useful for scope reduction when sending the data to a third-party that does not have access to the decryption key.

There are many ways to create tokens. Creating a token by encrypting or hashing a PAN means the tokenization process will have the same scope and compliance concerns as when using those techniques to render a PAN unrecoverable or unreadable. An alternative is to generate a new unique number that has no direct relationship to the PAN and, if necessary for later recovery, associate it with the PAN in a database.

References

For further reference on many of the concepts described above, see the following. Note that some of these may use requirement numbers from previous versions of PCI DSS that do not match the current requirement numbers: