PCI DSS card number masking, and where full card numbers hide in documents

PCI DSS v4.0.1 limits a displayed card number to its bank identification number (BIN), the first six or eight digits, and its last four, unless someone has a documented business need to see more. Wherever the full number is stored, it must be unreadable: hashed, truncated, tokenized or encrypted. Sensitive authentication data, which includes the three- or four-digit card verification code, full magnetic-stripe or chip data and PINs, can't be stored after authorization at all, even encrypted.

The rules are written with payment systems in mind. Card numbers also turn up in documents nobody thinks of as a payment system, and that's where the full number survives.

What a document may show, and keep

PCI DSS v4.0.1 splits account data into two kinds, and treats them very differently once a payment has been authorized. The first four elements below are cardholder data; the last three are sensitive authentication data.

The card number is what makes something cardholder data. Without the number, a name or expiry date isn't account data under PCI DSS; stored alongside it, it needs the same protection.

Masking is not truncation

Requirement 3.4.1 covers display. On screens, receipts, printouts and reports, a card number shows at most the BIN and last four digits, and only roles with a documented business need see more. The standard's guidance goes further: show only the digits the task needs, so if the last four are enough, show the last four.

Requirement 3.5.1 covers storage. A stored card number must be unreadable through a keyed hash of the whole number, truncation, index tokens or strong cryptography. It applies to spreadsheets, text files, backups and logs as well as databases.

The standard is blunt that the terms aren't interchangeable. A masked number is still stored in full and can be unmasked; truncated digits are gone. According to PCI SSC's FAQ 1091, the baseline for truncation is to keep at most the first six and last four digits. For 16-digit Discover, JCB, Mastercard, UnionPay and Visa numbers the most a brand allows is the first eight and any other four, and for 15-digit American Express numbers it's the first six and last four.

Sensitive authentication data: never after authorization

Requirement 3.3.1 is plain: sensitive authentication data is not stored after authorization, even if encrypted, and must be made unrecoverable once authorization completes, which is when the merchant receives an approval or decline. Card issuers with a documented business need are the only exception.

Paper is included. The guidance to Requirement 3.3.1.2 says that a card verification code written down before authorization should afterwards be cut out or covered with an opaque marker that can't be removed.

Where full card numbers hide

Requirement 3.2.1 asks for retention and disposal policies that cover every location of stored account data, and a check at least every three months that data past its retention period is gone. Documents are the locations that are easiest to leave off that list.

Scanned order and authorization forms

Mail-order forms, phone-order sheets and recurring-payment authorizations ask for the number, expiry date and security code in boxes, often handwritten: "Card 4532 0151 1283 0366, exp 09/28, CVV 219". Once the payment is authorized, the code on that scan is data that shouldn't exist.

Chargeback and dispute packets

Evidence for a dispute gathers receipts, signed slips, statements and sometimes photos of the card itself, front and back. The security code is printed on one side or the other.

Emails, chats and support tickets

Customers paste full card numbers into emails and chats to fix a declined payment, and agents copy them into ticket notes. Every archived copy is stored account data.

Call notes and spreadsheets

Agents type card numbers into free-text notes during calls, split up or run together, where a search for one 16-digit pattern misses them. Reconciliation reports exported to a spreadsheet can carry a whole column of full numbers, and the storage rule names spreadsheets explicitly.

The file itself

Document properties, comments, attachments and fillable form fields can hold the number you removed from the page, and a scanned PDF can carry a text layer behind the image.

A checklist before a document is stored or shared

• Every page has been read by OCR, including handwritten forms and photos of cards.
• No card verification code, PIN or track data remains in any document kept after authorization.
• Card numbers show at most the BIN and last four, or only the last four where that's all the reader needs.
• Numbers that were already masked are left as printed, and no other copy keeps a different set of digits.
• Spreadsheets, exports and attachments have been checked, not only the cover document.
• Redacted digits are removed, not covered, and document properties, comments and form fields are clean.
• Paper originals are cross-cut shredded, incinerated or pulped once they're no longer needed.
• The document has a defined retention period, and it's deleted when that period ends.

Where DocArmor fits

DocArmor's Financial Identifiers (PCI / GLBA) template finds primary account numbers, card security codes and related data wherever they appear, including handwritten notes on scanned forms. Context-aware detection catches a full card number and CVV pasted into a note, while it leaves an already-masked card ending 4417 as printed. Every finding goes to a reviewer, and redacted content is removed and checked on every page, with metadata, attachments and form values stripped, because a security code that can be lifted from under a box is still stored.

This post is general information about PCI DSS v4.0.1, not a compliance assessment. The payment brands and your acquirer decide what you must comply with and validate, so check with them and your assessor.