How Long You May Keep a Payment Record, and Why Forever Is a Liability

That absence of a fixed rule is the point: organizations must build their own schedules, justify every period, and accept that holding data longer than required transforms a compliance asset into a liability.

Retention Pulls in Two Directions at Once

Payment data retention lives in tension. PCI DSS Requirement 3.2.1 obliges merchants to document why they keep what they keep, while the same standard's guidance warns that unnecessary stored data should be purged at least quarterly. The UK Information Commissioner's Office adds a parallel rule for anyone holding this data under UK data-protection law: information must be kept for the length of time defined in the schedule unless there is a legal requirement to destroy it sooner. No single statute sets the schedule. Where no legally defined retention period exists, the relevant information asset owner must determine an appropriate period and defend it. The result is a policy that must simultaneously satisfy retention mandates and deletion obligations, with the merchant caught in the middle.

What Payment Data May Survive—and What Must Vanish

Not all payment data carries equal risk. Under PCI DSS guidance, the cardholder's name, PAN, expiration date, and service code may be stored if required for business purposes and protected in accordance with PCI DSS requirements. A CUNY PCI compliance policy provides a concrete inventory of what survives after authorization: the payment cardholder name, last four digits of the card number, card expiration date, transaction authorization number, transaction date, and transaction dollar amount.

The prohibited list is absolute. PCI DSS Requirement 3.3.1 bans storage of sensitive authentication data after authorization, including full track data, card verification codes or values, and PIN block data. The council's data-storage guidance repeats that card-validation codes or values must never be stored. CUNY's policy mirrors this: CVC/CVV codes and PINs must never be retained. Merchants who treat these elements as retrievable for customer convenience or fraud review are in violation regardless of their encryption or access controls.

What a Retention Schedule Contains

A retention schedule is an operating document, not a compliance memo. A public data-retention policy framework specifies ten fields that define how data lives and dies: information category, system or storage location, owner, business purpose, classification level, retention period or trigger, disposal method, approval requirement, and exception or legal-hold handling. Stanford University's PCI data-retention policy insists that retention requirements must be tied to why cardholder data needs to be held—meaning explicit business justification, not inherited habit. When no external rule sets the period, the ICO requires the asset owner to determine it. Every entry in the schedule must carry a reason attached to the period; a date without justification fails audit and fails in court.

Where Data Outlives the Schedule

The schedule governs production systems, but data escapes. PCI DSS quick-reference guidance recommends purging unnecessary stored data at least quarterly. CUNY's policy mandates a quarterly process for identifying and securely deleting stored cardholder data at the end of its retention period. The requirement to securely delete when no longer needed applies across all locations where cardholder data resides. Backups, analytics exports, and support ticket attachments represent common leak points that organizations often address through separate policies or fail to address at all. The regulator has not published specific operational instructions for immutable backup systems or aggregated analytics datasets, leaving merchants to apply the general principle: data kept beyond its stated purpose becomes a liability regardless of its container.

A First Schedule for Teams Starting from Nothing

Organizations without an existing schedule can begin with the framework fields, applied to payment data specifically. Each entry requires: the data category (cardholder name, last four PAN digits, transaction amount), the system location (production database, backup vault, analytics warehouse), the named owner responsible for the decision, the business purpose (chargeback defense, tax audit, customer service), the retention period tied to that purpose, the disposal method (cryptographic erasure, physical destruction), the approval level for exceptions, and the legal-hold trigger. Stanford's language of "legal, regulatory, or business reasons" provides the justification template. The ICO's rule on owner-determined periods covers gaps where no statute speaks. PCI DSS provides the boundary: limit storage amount and retention time to what is required, and delete when that requirement ends.

The Operational Consequence

A retention schedule only protects the organization when every retained category carries a stated reason, a stated period, and a stated disposal path. Data held without these three elements becomes ungovernable—unavailable for legitimate use, indefensible in audit, and exposed in breach. The liability of "forever" is not theoretical: storage without purpose violates the core PCI DSS requirement that cardholder data be limited to what is necessary, and it compounds the damage when systems are compromised. Merchants who complete their schedules must still execute them, with quarterly review cycles and secure deletion procedures that match the documentation.