Card numbers in tickets and chats: PCI DSS scope before an export

How card numbers end up in support tickets and chats#

Card numbers end up in support tickets and chats because customers try to pay or fix a billing problem in whatever channel is open. A customer types a card number into website chat to settle an invoice, an agent pastes it into an internal note, or someone emails a photo of the card.

Some channels collect far more than others. Billing queues, payment-failure tickets and after-hours chat tend to be the worst. Call transcripts add a second problem: card numbers spoken aloud are often transcribed as words or broken digit groups that simple patterns miss.

What PCI DSS scope means for a helpdesk archive#

PCI DSS scope covers systems that store, process or transmit cardholder data, along with systems connected to them. If full card numbers sit in Zendesk, Intercom or a shared inbox, those systems and any export taken from them can become part of that scope, whether or not anyone intended it.

The standard generally requires stored card numbers to be rendered unreadable, and its Requirement 3.3.1 does not allow sensitive authentication data, such as the card verification code, to be kept after authorization, even if encrypted. A plain-text card number in a ticket meets neither expectation. Which requirements apply to your archive, and how, is a question for your PCI program owner, your assessor and counsel.

Check which version any guidance was written against. The PCI Security Standards Council published PCI DSS v4.0 in March 2022 and the limited revision v4.0.1 in June 2024; v4.0 was retired on December 31, 2024, and its future-dated requirements became mandatory on March 31, 2025. Older articles written for earlier versions may cite different requirement numbers.

An export makes this concrete. A CSV or JSON dump of tickets is a new copy of any card data inside it, sitting in a new place. That is why the scan belongs before or during the export, inside your environment, not after the file has been copied around.

How to find card numbers in free text#

Finding card numbers in free text works best as a layered check: a pattern match for card-length digit runs, a Luhn checksum to drop impossible numbers, and context words to raise or lower confidence. Each layer removes false positives that would otherwise bury reviewers.

Off-the-shelf detectors help. Amazon Comprehend's documented PII entity types include card numbers and card security codes, and Presidio combines regular expressions, rule-based logic and checksums with context. Both still need tuning and review. The Luhn check is a single check digit, so roughly one in ten random digit strings of card length passes it by chance, which is why order numbers, equipment serial numbers and tracking numbers still produce false positives.

• 1Match digit runs of card lengths, allowing spaces, dashes and dots between groups.
• 2Run the Luhn checksum on each candidate; numbers that fail are very unlikely to be card numbers.
• 3Check issuer prefixes and nearby words such as visa, card, exp, cvv or ending in.
• 4Look for short security codes and expiry dates near any confirmed card number, including in the next message.
• 5Run OCR on images and PDF attachments before scanning them as text.
• 6Normalize spoken digits in call transcripts, such as four one one one, before matching.

Remove, truncate or tokenize: which treatment fits?#

The right treatment for a card number depends on what the record needs to show, and for a licensed dataset the answer is almost always removal. Buyers want to see that a customer paid by card or disputed a charge, not which card was used.

Clean the source system, not only the export#

Cleaning the source system matters because card numbers left in the helpdesk keep it in scope after the export is fixed. Most helpdesks offer redaction for new messages or for one ticket at a time, so older tickets usually need a separate, deliberate cleanup.

Agree the order of work with your PCI program owner. A common path is to scan the archive, redact or purge card data in the source system under change control, then take the export from the cleaned system. Where purging is not possible, scan and remove during the export pipeline and limit who can open the raw extract.

Record what you found and what you did#

Recording the scan result turns a cleanup into evidence. The record should let an assessor, a buyer or your own counsel see that card data was looked for in every channel and handled the same way each time.

Keep the log free of the values it describes. A detector report that lists every card number it found is itself a file full of cardholder data.

• 1Systems and date ranges scanned, including attachments and transcripts.
• 2Detection method: patterns, Luhn check, context rules, tool name and version.
• 3Count of confirmed hits per system, without storing the numbers themselves.
• 4Treatment applied and any exceptions.
• 5Human review of a random sample of cleaned records.
• 6Who approved the result and when.

Illustrative: an HVAC contractor's chat and ticket archive#

Illustrative: a fictional HVAC and plumbing contractor runs ServiceTitan for jobs and invoices, a website chat tool for booking and a shared helpdesk for billing questions. It plans to license customer service conversations that link requests to estimates, jobs and callbacks.

The first scan flags many card-like numbers. After the Luhn check and context rules, most turn out to be equipment serial numbers, permit numbers and invoice references. The remaining hits are real card numbers that homeowners typed into chat to pay repair invoices, plus security codes sent in follow-up messages.

The contractor's controller and outside counsel decide to purge card data in the helpdesk and chat tool first, then export. Every card number and code becomes [CARD_NUMBER] or [CARD_CODE], and the conversation still shows that the customer asked to pay by card and how the agent responded.

How SourceX treats payment card data#

SourceX treats full card numbers and security codes as excluded content in every package, so they are removed during the Preparation step of the SourceX five-step transaction rather than negotiated case by case. The supplier reviews the scan results and approves the treatment at the Approval step.

The scan method and a summary of findings go into the privacy record of the SourceX Evidence Packet, alongside provenance, licensing rights, permitted use and release authorization.