Rights and contracts
Card numbers in support tickets: PCI obligations before licensing
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
PCI data in support tickets, such as card numbers customers paste into chats or emails, has to be found and removed before a ticket archive is licensed. Card data can bring a help desk into PCI DSS scope, and security codes must not be kept after authorization. Scan every copy, including attachments, and redact at the source.
Key takeaways
- Card numbers in ticket text, chats and attachments are cardholder data, whatever system holds them.
- PCI DSS v4.0 Requirement 3.3.1 says sensitive authentication data is not retained after authorization, even if encrypted.
- Detection should layer pattern matching, checksum validation and context, followed by human review of samples.
- Attachments and screenshots need separate handling because text scanners do not read images.
- No licensed dataset should contain card data; replace every confirmed hit with a fixed placeholder token.
Why card numbers end up in tickets, and where they hide#
Card numbers end up in support tickets because customers try to be helpful. They paste a card number into chat to fix a failed payment, email a photo of the card, or read the number aloud on a call that is later transcribed. Agents sometimes copy it into an internal note to hand off to billing.
None of this was designed, which is the problem. A help desk built for support conversations can quietly accumulate cardholder data over years, and nobody notices until an export is scanned for another reason, such as a licensing review.
PCI scope for a support system follows every copy of the data. A clean help desk with an uncleaned CRM sync or an old export folder still leaves card numbers in the archive you might license.
| Location | How card data gets there | Detection approach |
|---|---|---|
| Ticket and email bodies | Customers paste numbers to update billing | Pattern match plus checksum on full text |
| Chat and messaging transcripts | Numbers typed in pieces across several messages | Scan joined conversation text, not single messages |
| Internal notes and macros | Agents copy numbers for hand-offs | Same text scan; check macro history too |
| Custom fields and web forms | Payment fields added to intake forms | Review field definitions and scan stored values |
| Attachments and screenshots | Photos of cards, invoice PDFs, billing page captures | OCR before scanning, or exclude images |
| Call transcripts | Numbers read aloud and transcribed as words or digits | Scan for spelled-out digits as well as numerals |
| Exports, backups and synced copies | Tickets copied to a CRM, warehouse or archive | Scan every copy that could feed the dataset |
What PCI DSS says about card data in a help desk#
PCI DSS is the payment card industry's security standard for organizations that store, process or transmit cardholder data, and a help desk holding card numbers in ticket text can fall within its scope. The current version is v4.0.1, published in June 2024; v4.0 was retired on December 31, 2024, and its future-dated requirements became mandatory on March 31, 2025.
One rule is especially relevant to support archives. Requirement 3.3.1 states that sensitive authentication data is not retained after authorization, even if encrypted, and its sub-requirements cover full track data, card verification codes and PINs or PIN blocks. A chat where a customer typed a card's security code is exactly the kind of record that rule addresses.
Primary account numbers are cardholder data that the standard also tightly controls. Whether your help desk is in scope, and what remediation is expected, is a question for your PCI assessor, your acquirer and counsel. For licensing, the answer is simpler: card data never goes into a dataset.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Detection and redaction checklist#
Detection works best in layers, because no single method finds everything. Open-source tools such as Presidio combine named-entity recognition, regular expressions, rule-based logic and checksums with context, and Amazon Comprehend lists credit and debit card numbers and card verification codes among the PII types it detects. Presidio's own documentation warns that automated detection cannot guarantee finding all sensitive information, so plan for review.
- Export the full history once, in a structured format, to storage your team controls.
- Join multi-message chats into single conversations before scanning, so split numbers are caught.
- Match card-length digit runs, including spaced and dashed forms, then validate candidates with a checksum.
- Look for security-code and expiry-date context near short numeric strings.
- OCR images and PDFs, or exclude attachments from scope entirely.
- Replace each confirmed hit with a fixed token such as CARD_NUMBER, never a partial number.
- Have a person review samples of hits and of clean records to tune false positives and misses.
- Clean the source system and every copy, following your incident process and your assessor's guidance.
- Record the detectors used, the scope scanned and the results in the dataset's privacy record.
Other payment data to treat the same way#
Card numbers are the obvious target, but support archives hold other payment details that a careful preparation pass removes at the same time.
| Data element | Why it matters | Handling for licensing |
|---|---|---|
| Full card number | Cardholder data under PCI DSS | Remove and replace with a token |
| Security code, PIN or track data | Sensitive authentication data, not retained after authorization | Remove; treat any find as a remediation item |
| Expiry date or cardholder name next to a number | Treated as cardholder data when stored with the number | Remove along with the number |
| Last four digits alone | Often used to identify a card in support | Remove by default; little value to a buyer |
| Bank account and routing numbers | Not PCI data, but sensitive financial data | Remove under general privacy preparation |
| Processor transaction IDs and tokens | Can link back to payment records | Replace with consistent pseudonyms if structure needs them |
Who owns the cleanup, and in what order#
The cleanup of card data in a help desk needs a named owner for each part, because licensing, security and compliance each see a different slice of the problem. In most software companies the CTO or head of engineering runs detection, a compliance or security lead talks to the assessor and acquirer, and support operations owns prevention.
Order matters. Scanning an export first tells you the size of the problem without touching production. Deleting or editing tickets before your incident process has run can destroy records your assessor or counsel wanted to see, so source cleanup comes after that review, not before. Licensing preparation runs on the scanned and tokenized export, and the source fix catches up on its own track.
The last step is prevention, so the next export is clean: payment links in place of chat collection, agent guidance and alerts on card-like strings in new tickets.
Illustrative: a billing software company cleans its chat history#
Illustrative: a fictional software company that sells scheduling and billing tools to fitness studios wants to license its support history. Studio owners often paste card details into Intercom chats when a payment fails, and agents forward some of them into Zendesk tickets for the billing team.
The CTO's team uses Intercom's data export, which sends conversations to the company's own Amazon S3 bucket in JSON, and pulls Zendesk tickets alongside. Layered scanning finds card-like numbers in chats, internal notes and a set of screenshot attachments. Confirmed numbers are replaced with a token, all image attachments are excluded, and both source systems are cleaned under the company's incident process with input from its assessor.
The licensed dataset keeps the troubleshooting conversations about failed payments, which are what a buyer values, with every card detail removed and the scan documented.
How SourceX handles payment data in support archives#
SourceX treats payment data as a hard exclusion in the Preparation step of the SourceX five-step transaction. Card numbers, security codes and bank details are removed before delivery, and attachments are excluded or processed separately.
The detectors, scope and results go into the privacy record of the SourceX Evidence Packet, and the supplier approves the prepared dataset before anything is delivered. Large exports can stay in the supplier's own storage throughout.
Frequently asked questions
Is masking all but the last four digits enough?
For a licensed dataset, remove the number entirely and use a fixed token. Partial numbers add little value for a buyer and keep a link to payment records. Whether a truncated format is acceptable inside your own systems is a separate PCI question for your assessor.
If we clean the help desk, is it out of PCI scope?
Possibly, but that is your assessor's determination, not a licensing decision. Scope depends on whether the system still stores, processes or transmits cardholder data, including through integrations, backups and new incoming tickets. Preventive controls matter as much as the cleanup.
Do we have to report card numbers we find?
Finding card data stored where it should not be can trigger duties under your incident response plan, your acquirer or card brand agreements, and possibly state law. Follow your incident process and involve counsel and your assessor before deleting or altering records.
Can we stop customers from posting card numbers?
Many teams send payment links instead of collecting numbers in chat, add widget or form rules that warn when a card-like number is typed, and train agents never to copy card data into notes. Check what your help desk supports on your plan and in its documentation.
Does this apply to support data from a payments product?
Yes, and the bar is higher. Payment companies carry additional compliance duties, and their support conversations reference transactions, disputes and account details far more often. Expect a stricter preparation standard, more fields removed and a narrower licensable scope.
Sources
- PCI DSS v4.0 Requirement 3.3.1 states that sensitive authentication data is not retained after authorization, even if encrypted, with sub-requirements covering full track data, card verification codes and PINs or PIN blocks. Source
- PCI DSS v4.0.1 was published in June 2024; v4.0 was retired on December 31, 2024, and its future-dated requirements became mandatory on March 31, 2025. Source
- Presidio is an open-source SDK for PII identification and anonymization that combines named-entity recognition, regular expressions, rule-based logic and checksums with context. Source
- Presidio's documentation warns that because it uses automated detection, there is no guarantee it will find all sensitive information, and additional protections should be employed. Source
- Amazon Comprehend's documented PII entity types include CREDIT_DEBIT_NUMBER and CREDIT_DEBIT_CVV. Source
- Intercom's Data Export feature sends Conversations data to the customer's Amazon S3 bucket in JSON or JSON Lines format. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.