Every PCI DSS assessment starts from a map of where card data lives. The map is drawn from what the business believes: payments go through the gateway, the POS system and the order database, so those systems form the cardholder data environment (CDE) and everything else is out of scope.
The map is usually wrong in the same way. A refund team exported a month of transactions to Excel to reconcile a dispute. A customer emailed their card number to support and the message is still in a shared mailbox. A developer turned on debug logging for a payment integration two years ago and the log rotated onto a file server. None of these were designed. They are simply what happens when people handle card data in their day jobs.
The PCI Security Standards Council has said this plainly. When it published its scoping guidance in 2016, its CTO said that "data breach investigation reports continue to find that companies suffering compromises were unaware that cardholder data was present on the compromised systems."
Cardholder data discovery is the work of finding those copies before an assessor or an attacker does. This guide covers what PCI DSS 4.0.1 actually asks for, where card numbers tend to hide, how a scanner decides that a string of digits is a card, and how to run a discovery scan without creating a new copy of the data in the process.
What counts as account data
PCI DSS uses three terms that are easy to blur together. The standard defines them in its applicability section:
| Term | What it covers |
|---|---|
| Cardholder data | The primary account number (PAN), plus the cardholder name, expiration date and service code |
| Sensitive authentication data (SAD) | Full track data from the magnetic stripe or chip, the card verification code, and PINs or PIN blocks |
| Account data | Cardholder data and/or sensitive authentication data |
The PAN is the anchor. In the standard's words, "the primary account number (PAN) is the defining factor for cardholder data." A name or an expiration date on its own is not cardholder data, but if those elements are stored, processed or transmitted with the PAN, they must be protected the same way.
Sensitive authentication data is different. Requirement 3.3.1 says "SAD is not stored after authorization, even if encrypted." That holds even where no PAN is present: the Council's FAQ 1533 explains that SAD stored without a PAN can still be correlated with a PAN stolen elsewhere. So a discovery exercise is looking for two things: PANs anywhere outside the systems meant to hold them, and SAD anywhere at all once a transaction has been authorized.
What PCI DSS 4.0.1 asks for
PCI DSS 4.0.1 was published in June 2024 and has been the only active version since v4.0 was retired on 31 December 2024. The requirements that were best practice until 31 March 2025 are now mandatory. Four requirements bear directly on finding card data:
| Requirement | Who it applies to | How often | What it asks |
|---|---|---|---|
| 12.5.2 | All entities | At least every 12 months, and on significant change | Confirm PCI DSS scope, including "all locations where account data is stored, processed, and transmitted", and specifically "any locations outside of the currently defined CDE" and file backups |
| 12.5.2.1 | Service providers only | At least every six months, and on significant change | The same scope confirmation, more often |
| 3.2.1 | All entities that store account data | At least every three months | Verify that "stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable" |
| A3.2.5 | Designated entities only | At least every three months, and on significant change | A data-discovery methodology that "locates all sources and locations of cleartext PAN" and addresses PAN "outside the currently defined CDE" |
Most merchants will never be assessed against A3.2.5. Appendix A3, the Designated Entities Supplemental Validation, "applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements." But 12.5.2 applies to everyone, and you cannot confirm that card data is absent from a file server you have never looked inside.
The standard does not name a tool, but the guidance printed alongside 12.5.2 points straight at one:
"A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE, for example, in an error log or memory dump file."
The same guidance suggests documenting each data store in a table: what it is for and how long data is kept, which cardholder data elements it holds, how they are secured, and how access is logged. A discovery scan tells you which stores belong in that table that nobody listed, and which card data elements each one holds.
Where card numbers hide
The locations are fairly consistent from one organization to the next, because the habits that create them are consistent.
- Spreadsheets and CSV exports. Reconciliation, chargeback and refund work all involve pulling transactions out of a payment system. Finance and customer service file shares accumulate these exports for years.
- Email. Customers send card numbers by email no matter how many times they are told not to, and staff forward them. Shared mailboxes, PST archives and exported
.mboxfiles keep every one. - Scanned paper. Mail-order forms, fax-to-email, authorization forms and photographed receipts arrive as PDFs and images. A text search never sees the numbers in them. Only OCR does.
- Logs and dumps. Payment integrations that log full requests, crash dumps, and debug output. The Council's own guidance names error logs and memory dumps.
- Database extracts and backups. A
.sqldump taken for a migration, an old Access database from before the current system, a backup copied to a NAS "temporarily". Requirement 12.5.2 names file backups explicitly. - Archives. All of the above, zipped, and then forgotten because a zip file's name says nothing about its contents.
The common thread is that these are files, on ordinary storage, outside the systems that were designed to handle card data. That is why a database-only or cloud-only discovery tool tends to miss them.
How a scanner decides that a number is a card
A naive search for "13 to 19 digits in a row" finds card numbers, and it also finds order numbers, tracking numbers, phone numbers run together, and timestamps. Card detection usually layers three checks to cut the noise.
- The Luhn checksum. A payment card number is up to 19 digits long, and its last digit is a check digit calculated with the Luhn algorithm. About one random number in ten passes, so this removes most noise but not all of it.
- The issuer prefix and length. Visa numbers start with 4, Mastercard with 51 to 55 or 2221 to 2720, American Express with 34 or 37 and is 15 digits long, and so on. A Luhn-valid number with no plausible prefix is discarded.
- Context. A number that passes both checks is far more likely to be a card if words like "card", "Visa", "expiration" or "CVV" sit near it, or if it is in a spreadsheet column headed
credit_card.
The third check is a trade-off and it is worth understanding before you scan. Requiring context keeps false positives low enough that someone will actually review the results. It also means a bare PAN with no label nearby, which is exactly what a log line looks like, can be missed. For PCI scoping the cost of a miss is higher than the cost of a false positive, so the method below adds a second, unlabelled pass over the places where unlabelled numbers live.
Expect test card numbers in your results. Numbers like 4111 1111 1111 1111 pass every check because they were built to, and they turn up in development folders, QA documentation and vendor integration guides. Mark them as false positives rather than tuning them out, so the next scan shows them as already reviewed.
A discovery method that holds up at assessment time
1. List the places to look
Start from the places the business does not consider part of the CDE: file servers and NAS shares, especially finance, accounting, customer service and IT; the laptops and desktops of staff who take payments, process refunds or handle disputes; shared mailboxes and mail archives; and backup and archive storage. Our guide to scanning shared drives and NAS devices covers building that inventory and the permissions problems that come with it.
2. Run a labelled scan of everything
Scan every location on the list for card numbers, with OCR turned on so scanned forms and images are read. This is the high-precision pass: Luhn, prefix and context all applied. It should produce a list short enough to review by hand.
3. Run an unlabelled pass where bare numbers live
Point a second scan at log directories, application data folders and database dumps, with a broader pattern that does not require context. This pass will be noisier, which is acceptable because the set of locations is small. Add patterns for magnetic stripe data at the same time. Track 1 data starts with %B followed by the PAN and a ^ separator, and track 2 data starts with ; followed by the PAN and an = separator, as defined in ISO/IEC 7813. Any track data found after authorization is a Requirement 3.3.1 problem regardless of whether a PAN is legible beside it.
4. Triage
Work through the findings and sort them into real cardholder data, test numbers, and false positives. Record the verdicts so the next scan does not ask you the same questions.
5. Decide what happens to each real finding
For each confirmed location, there are three outcomes:
- Delete it, if there is no business reason to keep it. This is the common case for old exports and emailed card numbers.
- Move it into the CDE, if the business genuinely needs it, so it is protected under Requirement 3.5.1 along with everything else.
- Bring the location into scope, if the data has to stay where it is. That is usually the most expensive choice, which is a good reason to prefer the first two.
Appendix A3 only binds designated entities, but its response steps in A3.2.5.2 are a sensible checklist for everyone: retrieve, delete or migrate the data, determine how it ended up outside the CDE, fix the leak or process gap that put it there, and identify the source. Without the last two steps the same export reappears next quarter.
6. Write it down and repeat
Keep the scan results as evidence for your 12.5.2 scope confirmation, and schedule the next run. Every 12 months is the floor for 12.5.2; the quarterly check in 3.2.1 is a natural cadence for anyone storing account data, and a significant change to the environment should trigger an extra run.
Don't create a new copy of the data while looking for it
A discovery tool has to read the card numbers in order to report them, which raises an awkward question: where do the results go?
Many data discovery products are cloud services. They read your files, or extracts of them, and send content to the vendor's infrastructure for classification. For card data, that means the PANs you were trying to locate are now also in a third party's systems, which is a conversation to have with your assessor before the scan, not after.
Even a scanner that runs entirely on your own hardware keeps its results somewhere. Its findings database and any export of findings may hold full PANs, and they are themselves a location of cleartext PAN. Treat them accordingly: run the scanner on a machine that is appropriate for that data, share masked reports rather than raw exports, and delete scan results once the findings have been remediated.
Doing this with PII Crawler
PII Crawler is a local scanner, so the method above runs without anything leaving your network. Here is how each step maps to it. The full option list is in the CLI reference.
Card detection. PII Crawler's credit card detector checks the Luhn digit, the length and the issuer prefix for Visa, Mastercard (both ranges), American Express, Discover, JCB, Diners Club and UnionPay, and reports a candidate only when a card-related term is nearby or a column header labels it. Details are on the data types page, including how spreadsheet and CSV headers are read as context.
Step 2, the labelled scan. Restrict a scan to card numbers with --only credit-card and keep the results with --save:
piicrawler scan /srv/finance /srv/support --only credit-card --save --name "PCI scope 2026 Q4"For a Windows or Samba share, the smb command does the same without mounting anything, and its results are always saved:
piicrawler smb fileserver Finance -u svc-pciscan --only credit-card --name "PCI scope 2026 Q4: Finance share"OCR is on by default, so scanned PDFs and images are read. PII Crawler also reads Outlook PST and OST files, .eml, .msg and .mbox, archives, Access and SQLite databases, and Office documents including comments and tracked changes. Mailboxes can be scanned directly over IMAP as well.
Step 3, the unlabelled pass. Add your own patterns with --regex. Matches are reported under a regex-<label> type, and the label keeps only its letters, so trackone rather than track1. These patterns do not check the Luhn digit, so expect more noise and keep the scan to logs and dumps:
piicrawler scan /var/log/payments /srv/dumps --only credit-card --save \
--regex 'trackone=%B[0-9]{12,19}\^' \
--regex 'tracktwo=;[0-9]{12,19}=[0-9]{4}' \
--regex 'barepan=\b(?:4[0-9]{15}|5[1-5][0-9]{14}|3[47][0-9]{13})\b' \
--name "PCI scope 2026 Q4: logs"Step 4, triage. Findings are reviewed in the TUI or the web UI, where you can mark false positives so they stay marked. See triaging findings.
Step 5, remediation. Action lists collect the files you confirmed and then delete them, quarantine them into a holding folder, or redact the card numbers in place, with a preview before anything is touched. Delete and quarantine work on SMB shares as well as local disks; redaction is local only.
Evidence, and cleaning up after yourself. piicrawler report <scan_id> writes a standalone HTML report in which every value is masked, which is the version to share. The local database and piicrawler export keep the full values, so treat them like the data itself. When the findings are remediated, piicrawler scans delete <scan_id> removes the scan and everything recorded for it, then compacts the database.
Free alternatives
If you want to try the method before buying anything, PANhunt is an open-source PAN scanner from Dionach, written for exactly this job of checking PCI DSS scope. It reads documents, zip files and PST files. It is a Python 2.7 script that was last updated in 2023, so plan for some work to run it on a current system. Our comparison of PII scanning tools covers other free and commercial options.
Frequently asked questions
Does PCI DSS require a card data discovery scan?
Not by name for most organizations. Requirement 12.5.2 requires you to identify every location where account data is stored, including locations outside the CDE, at least every 12 months, and the guidance for that requirement suggests a data discovery tool or methodology as the way to do it. Only Appendix A3, which applies to entities designated by a payment brand or acquirer, explicitly requires a data-discovery methodology, run at least every three months.
Is an expiration date or cardholder name on its own in scope?
The PAN is the defining element. The standard says the cardholder name, service code and expiration date must be protected when they are stored, processed or transmitted with the PAN, or are otherwise present in the CDE. Sensitive authentication data is the exception: it must not be stored after authorization even where no PAN is present.
How often should we scan?
At least every 12 months and after any significant change, to support 12.5.2. Service providers must confirm scope every six months under 12.5.2.1. If you store account data, the quarterly retention check in 3.2.1 is a natural point to rescan the places where expired data tends to linger.
What should we do with card numbers we find?
Delete them if there is no business need, move them into the CDE if there is, and only bring the location into scope if neither is possible. Then find out how they got there, so the next scan does not find the same thing in a new file.