How to store credit card information under PCI rules

What you may keep, and what you may never keep

PCI DSS has a name for everything on a card. Account data is cardholder data and/or sensitive authentication data. PAN is the “primary account number,” the card number that identifies the issuer and the cardholder account. The Council's glossary says cardholder data “consists of the full PAN,” and may also carry the cardholder name, expiry date and service code. Sensitive authentication data is the rest: “Security-related information used to authenticate cardholders and/or authorize payment card transactions,” including card verification codes, full track data, PINs and PIN blocks.

Cardholder data may be stored when the business needs it, and then it is protected. On the card number, name, expiry and service code, the standard says they “may need to be retained” and adds: “To minimize risk, store securely only these data elements as needed for business.” Sensitive authentication data has no such door. 3.3.1: “SAD is not stored after authorization, even if encrypted.” Sensitive authentication data covers the card verification code, full track data, PINs and PIN blocks.

The security code: take it, use it once, let it go

The card verification code is “the three- or four-digit value printed on the front or back of a payment card” (also called CVV2, CVC2, CID and other brand names). It slips into storage easily: a box on a signed form, a line in an order note.

Asking for it is fine. The Council's FAQ 1280 says “PCI DSS does not prohibit the collection of card verification codes prior to authorization” of a specific purchase. Keeping it for later is not: card verification codes “are not needed for card-on-file or recurring transactions,” the FAQ's example being a recurring gym membership, and the same ban covers concierge-style services that hold a card to book restaurants or theatre tickets for a customer. A customer's written permission changes nothing: it “has no validity for PCI DSS.”

If an order sits on a computer before it is charged, Requirement 3.3.2 says “SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography,” and whether you may hold it at all “is determined by the organizations that manage compliance programs (for example, payment brands and acquirers).” Phone lines are covered too. The Council's telephone guidance says: “If SAD is received and recorded, the entity MUST render all data unrecoverable upon completion of the authorization process.” That includes a call recording that caught a customer reading out the code.

Paper, phone notes and inboxes are storage too

Storage is not only a database. Asked whether PCI DSS covers paper, the Council's FAQ 1069 answers “Yes”: the requirements apply “if a Primary Account Number (PAN) is stored, processed, or transmitted on or by any media, including paper records,” and Requirement 9 covers “the safeguarding of physical media, including paper records.” The phone is no exception.

Paper you keep follows Requirement 9. “All media with cardholder data is physically secured” (9.4.1), and 9.4.6: paper with cardholder data is “cross-cut shredded, incinerated, or pulped” when no longer needed, and kept in secure storage containers until then. A drawer of signed forms is in scope for as long as the card numbers on it are readable.

Email and text spread further: a copy can sit on every device and server the message touched. Requirement 4.2.2 says “PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies,” and the Council's phone guidance says plainly: “Never send CHD over an unencrypted, end-user messaging medium such as chat, social media, SMS (short message service)/text, or e-mail, or other non-encrypted communication channel.”

Find the card numbers you already hold

Card data piles up without anyone deciding to keep it: in an order pad, a voicemail box, a sent-mail folder, the memo field of an invoice. Tick every place yours has landed and the receipt lists the fix and the rule for each. If your books live in QuickBooks, the sweep for card numbers in QuickBooks memos, notes and attachments covers the places accounting software adds.

Once the list is clean, confirm what is still in scope with the PCI scope checker, then let the SAQ type finder tell you which questionnaire your channels now point to.

If you keep card numbers yourself

Some businesses still hold card numbers on purpose: old billing software, a customer file for phone orders. PCI DSS allows it, with conditions. The first is to keep less. Requirement 3.2.1 opens: “Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes” that cover every place it is stored.

The second is that what you keep cannot be read. 3.5.1: “PAN is rendered unreadable anywhere it is stored” by one-way hashes of the full PAN, truncation, index tokens, or strong cryptography with key management. “Anywhere” is meant literally: the requirement's note names “flat files such as text files spreadsheets” and non-primary storage such as “backup, audit logs, exception, or troubleshooting logs.”

Source: PCI SSC Glossary: Masking, Truncation, read on 2026-10-22

On masking, the standard is precise. 3.4.1: when PAN is displayed, “the BIN and last four digits are the maximum number of digits to be displayed” unless a person has a legitimate business need to see more. And the questionnaire changes with the storage. SAQ D for Merchants: “All merchants not included in descriptions for the above SAQ types.” Examples include “E-commerce merchants that accept account data on their website” and “Merchants with electronic storage of account data.”

Encrypting the file is allowed, and it brings key-management duties of its own; the tokenization vs encryption guide lays out what each does to your scope. The shorter road is to stop holding the number.

The better way: your processor keeps the card, you keep a token

“Tokenization is a process by which the primary account number (PAN) is replaced with a surrogate value called a ‘token.’ De-tokenization is the reverse process of redeeming a token for its associated PAN value.” When your processor does the tokenizing, the vault and the de-tokenizing sit on its side, and what lands in your customer records is a value you can charge but cannot read.

Tokens can shrink PCI scope, but “Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance.” A system holding only tokens is out of scope only if the PAN cannot be recovered from those tokens and the system cannot affect cardholder data security. What stays yours is where the card is typed:

So the choice of payment page still decides your questionnaire. SAQ A is for “Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties. No electronic storage, processing, or transmission of account data on their systems or premises.” And the provider's status is not yours: “The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.” (Requirement 12.8.1, applicability notes.)

The card brands still treat a saved token as a saved card. Visa defines a stored credential as information “(including, but not limited to, an account number or payment token)” stored to process future purchases, and before storing one the merchant “must establish an agreement with the cardholder.” The recurring version of our card authorization form generator prints the lines Visa lists, with only the last four digits on the page you keep.

Quick reference: card storage on one receipt