In a previous article, we discussed why the card data inventory that nearly every organization presents during an audit rarely matches what actually exists within its systems, and why building that inventory by simply "asking around" is the root cause of this gap. Building on that premise, we will explore how to implement a data discovery process that enables organizations to maintain control over their inventory, remains sustainable over time, and helps answer the following questions: why is this gap both a security and compliance issue? And how can a discovery process be executed in practice to identify and maintain control over cardholder data in a sustainable way?
An attacker who has compromised a system seeks the path of least resistance to valuable data. That path rarely leads through a well-defended CDE (Cardholder Data Environment). Instead, it tends to pass through forgotten copies of the same data that exist outside the CDE: unencrypted, unsegmented, and with no one reviewing access logs.
Examples of poorly protected scenarios are unfortunately encountered every day: a staging database dump on an unprotected server, a log file readable by any process on the host, a mailbox repository containing years of attachments, or a screenshot uploaded as evidence in a support ticket.
None of these locations are protected by perimeter data loss prevention measures. A DLP (Data Loss Prevention) solution cannot prevent the leakage of data that it does not know exists. Monitoring systems do not generate alerts for files that no one has classified as sensitive. What has not been discovered cannot be protected, and an exfiltration path that is unknown cannot be monitored.
This stage reverses the burden of proof. Everything that has not been explicitly confirmed as out of scope must be considered in scope until proven otherwise. This has a significant practical consequence. For repositories with uncertain scope, discovery is no longer based on sampling; it becomes a full-coverage exercise. The standard is to inspect everything rather than relying on statistical samples.
With this requirement for full coverage, and with the technical depth necessary to identify where PAN data may actually be located, validation is performed simultaneously across three areas:
▪️System components: previously inventoried assets validated through technical inspection
rather than documentation alone.
▪️Corporate network: segments outside the CDE that may maintain uncontrolled connectivity to
it, verified through actual segmentation testing rather than firewall rule reviews alone.
▪️Third parties and service providers: validated both contractually and technically. Contract
clauses are not sufficient. Verification must include evidence such as transfer logs and
payload specifications. It is not uncommon to discover a vendor that supposedly receives
"metrics only," while the complete payload actually contains PAN data without anyone
realizing it.
Operationalizing this process requires defining four key elements, ideally through a formal procedure:
▪️Criticality-Based Frequency
▫️High criticality (CDE databases, active integrations): monthly or quarterly reviews.
▫️Medium criticality (file shares, support environments): semi-annual reviews.
▫️Low probability but plausible sources (development environments, historical backups):
annual reviews.
▪️Event-Based Triggers: Infrastructure changes, new integrations, or security incidents should
trigger immediate reviews without waiting for the next scheduled cycle.
▪️Responsibilities: who performs the scans, who reviews the findings, who approves remediation
and closure.
1. Spoken During a Recorded Call: Call centers routinely capture card information through voice interactions. Many of these calls are recorded for quality assurance or compliance reasons and retained for years. A card number spoken to an agent or entered through an IVR system remains stored either as audio or DTMF tones. Traditional file-search techniques cannot detect this. Identification requires audio-content analysis or DTMF masking at capture time before those tones are translated into text within logs.
2. Hidden Within Nested Containers: An attachment inside an email, stored within a mailbox container, archived inside a backup. A text file inside a ZIP archive, embedded within an office document that itself is a compressed container, stored inside another archive. Every layer adds another barrier to superficial searches. A tool that inspects only the first level sees a compressed file and moves on. The PAN is waiting three layers deeper.
3. Embedded Within an Image: A scanned PDF of a payment form, a screenshot of a point-of-sale terminal, or a photograph of a credit card sent by a customer "to confirm payment." For text-based discovery tools, these files are opaque. They contain pixels rather than characters. The card number may be perfectly readable to a human while remaining completely invisible to system utilities such as grep on Linux or Unix. Only a solution capable of performing Optical Character Recognition (OCR) can identify the information contained within these images.
4. Data Believed to Be Deleted: A file containing card numbers that was "deleted" months ago may still exist intact within unallocated disk space. To tools that only inspect the active file system, that information no longer exists. To a free-space analysis, however, it remains fully recoverable. And if it is recoverable for investigators, it is equally recoverable for attackers.
Grep cannot see inside images or listen to audio files. DLP solutions do not inspect unallocated disk space. Homegrown scripts rarely perform recursive analysis through nested containers. Each blind spot ultimately reflects a missing capability. For any organization handling cardholder data, the question is not whether uncontrolled PANs exist outside managed environments. They almost certainly do. The question is whether the organization has the capability to find them before an auditor does, or before someone with malicious intent does.
CardExpose Scanner is part of a suite that includes a centralized management console capable of orchestrating scans through distributed agents deployed across enterprise infrastructure. Supported platforms include: Windows Desktop, Linux Desktop, macOS, Windows Server, Linux Server, Solaris Intel/SPARC, AIX, IBM iSeries (AS/400), Linux s390x for IBM Z. The full feature set is available across desktop, server, midrange, and mainframe environments.
Executive summary of a CardExpose scanning cycle.
That executive summary is what transforms Stage 3 from an intention into a real operational process. It provides responsible stakeholders with a tangible artifact to review during every cycle and allows them to compare results over time, determining whether the organization's actual exposure surface is growing or shrinking, which is ultimately the only metric that matters once the inventory has been properly validated.
Why This Is Not Just About Compliance, It Is About Defense
We have discussed data discovery as an inventory challenge, but it is important to note that the cost of orphaned data is not merely a compliance issue. The real cost is exposure. To understand why, the problem must be viewed from the attacker's perspective.An attacker who has compromised a system seeks the path of least resistance to valuable data. That path rarely leads through a well-defended CDE (Cardholder Data Environment). Instead, it tends to pass through forgotten copies of the same data that exist outside the CDE: unencrypted, unsegmented, and with no one reviewing access logs.
Examples of poorly protected scenarios are unfortunately encountered every day: a staging database dump on an unprotected server, a log file readable by any process on the host, a mailbox repository containing years of attachments, or a screenshot uploaded as evidence in a support ticket.
None of these locations are protected by perimeter data loss prevention measures. A DLP (Data Loss Prevention) solution cannot prevent the leakage of data that it does not know exists. Monitoring systems do not generate alerts for files that no one has classified as sensitive. What has not been discovered cannot be protected, and an exfiltration path that is unknown cannot be monitored.
The Methodology: How to Perform Effective Data Discover
The discovery process is not a one-time exercise. It is a continuous cycle consisting of three interconnected stages. The first establishes the foundation, the second validates it without compromise, and the third maintains that level of hygiene over time because environments are constantly changing.Stage 1: Grounding Discovery Through Gap Analysis
This is the initial snapshot that defines everything that follows. If it is done incorrectly, every subsequent step inherits that error. In fact, most compliance gaps originate precisely here, in an incomplete scope definition.
Doing it properly means identifying every flow where Cardholder Data (CHD) or Sensitive Authentication Data (SAD) is transmitted, processed, or stored, not just the obvious ones. Identifying the primary payment platform is straightforward. The real value comes from uncovering secondary flows such as ERP integrations, refund modules, customer complaint handling processes, and similar examples.
The most common methodological mistake is asking the IT department, "Which systems store card data?" That question always yields an incomplete answer because IT understands its inventory, but not necessarily every business process.
The recommended approach is to conduct structured interviews based on processes rather than systems. For every process or channel, document who captures the data, how it travels, where it resides even temporarily, and who can access it.
Simple questions often reveal hidden data flows:
▪️"Have you ever exported payment information to Excel in order to resolve a payment issue?"
▪️"What does the team do when a customer disputes a charge or requests card details via email or chat?"
Targeted technical scanning complements these interviews using PAN (Primary Account Number) patterns, card-brand-specific regular expressions, and validation through the Luhn algorithm as a secondary filter. Any sixteen-digit number beginning with four may match a Visa pattern, even if it is actually an internal invoice number, so relying solely on regular expressions is insufficient.
Stage 1 typically concludes with:
▪️An inventory of repositories, each marked as either "confirmed" or "discarded."
▪️A data flow diagram.
▪️A justified inventory of connected systems.
▪️A preliminary CDE definition ready for validation.
Stage 2: Validate Scope and Reverse the Burden of Proof
In this phase, the guiding principle changes. Stage 1 is business-hypothesis-driven discovery. Interviews are conducted, maps are drawn, and a theory is built regarding where data resides. Stage 2 is the exhaustive and independent verification of that theory, including locations that the business did not mention, does not know about, or simply does not remember.This stage reverses the burden of proof. Everything that has not been explicitly confirmed as out of scope must be considered in scope until proven otherwise. This has a significant practical consequence. For repositories with uncertain scope, discovery is no longer based on sampling; it becomes a full-coverage exercise. The standard is to inspect everything rather than relying on statistical samples.
With this requirement for full coverage, and with the technical depth necessary to identify where PAN data may actually be located, validation is performed simultaneously across three areas:
▪️System components: previously inventoried assets validated through technical inspection
rather than documentation alone.
▪️Corporate network: segments outside the CDE that may maintain uncontrolled connectivity to
it, verified through actual segmentation testing rather than firewall rule reviews alone.
▪️Third parties and service providers: validated both contractually and technically. Contract
clauses are not sufficient. Verification must include evidence such as transfer logs and
payload specifications. It is not uncommon to discover a vendor that supposedly receives
"metrics only," while the complete payload actually contains PAN data without anyone
realizing it.
Stage 3: Operationalize Periodic Validation (BAU)
Certification is not the goal. It is the starting point for continuous monitoring. Once certified, risk does not disappear. It changes in nature. New business processes appear. Configurations gradually revert. Logs may start capturing complete payloads again after software updates. New personnel may unintentionally reintroduce risky practices because they are unaware of previous findings. Without an active process after certification, organizations can end up in exactly the same situation twelve months later.Operationalizing this process requires defining four key elements, ideally through a formal procedure:
▪️Criticality-Based Frequency
▫️High criticality (CDE databases, active integrations): monthly or quarterly reviews.
▫️Medium criticality (file shares, support environments): semi-annual reviews.
▫️Low probability but plausible sources (development environments, historical backups):
annual reviews.
▪️Event-Based Triggers: Infrastructure changes, new integrations, or security incidents should
trigger immediate reviews without waiting for the next scheduled cycle.
▪️Responsibilities: who performs the scans, who reviews the findings, who approves remediation
and closure.
Blind Spots Where PAN Data Survives Unnoticed
Card numbers often "hide" within the complexity of real-world systems, typically in formats that conventional discovery methods cannot interpret. We have already examined the reasons (compliance and defense) and the process (the three stages). What remains is identifying the exact locations where PAN data continues to exist unnoticed by the tools most organizations rely upon.1. Spoken During a Recorded Call: Call centers routinely capture card information through voice interactions. Many of these calls are recorded for quality assurance or compliance reasons and retained for years. A card number spoken to an agent or entered through an IVR system remains stored either as audio or DTMF tones. Traditional file-search techniques cannot detect this. Identification requires audio-content analysis or DTMF masking at capture time before those tones are translated into text within logs.
2. Hidden Within Nested Containers: An attachment inside an email, stored within a mailbox container, archived inside a backup. A text file inside a ZIP archive, embedded within an office document that itself is a compressed container, stored inside another archive. Every layer adds another barrier to superficial searches. A tool that inspects only the first level sees a compressed file and moves on. The PAN is waiting three layers deeper.
3. Embedded Within an Image: A scanned PDF of a payment form, a screenshot of a point-of-sale terminal, or a photograph of a credit card sent by a customer "to confirm payment." For text-based discovery tools, these files are opaque. They contain pixels rather than characters. The card number may be perfectly readable to a human while remaining completely invisible to system utilities such as grep on Linux or Unix. Only a solution capable of performing Optical Character Recognition (OCR) can identify the information contained within these images.
4. Data Believed to Be Deleted: A file containing card numbers that was "deleted" months ago may still exist intact within unallocated disk space. To tools that only inspect the active file system, that information no longer exists. To a free-space analysis, however, it remains fully recoverable. And if it is recoverable for investigators, it is equally recoverable for attackers.
Grep cannot see inside images or listen to audio files. DLP solutions do not inspect unallocated disk space. Homegrown scripts rarely perform recursive analysis through nested containers. Each blind spot ultimately reflects a missing capability. For any organization handling cardholder data, the question is not whether uncontrolled PANs exist outside managed environments. They almost certainly do. The question is whether the organization has the capability to find them before an auditor does, or before someone with malicious intent does.
What This Looks Like in Practice
Stage 3, periodic monitoring rather than a one-time assessment, is the step that most organizations skip because it does not produce a single deliverable that can simply be shown during an audit. At Internet Security Auditors, we use and recommend CardExpose Scanner to achieve this objective. Each scanning cycle concludes with an executive summary that quantifies findings, analyzed files, severity levels, and distribution by card brand and file type. It also differentiates known test card numbers from actual exposure, preventing teams from wasting time investigating known false positives.CardExpose Scanner is part of a suite that includes a centralized management console capable of orchestrating scans through distributed agents deployed across enterprise infrastructure. Supported platforms include: Windows Desktop, Linux Desktop, macOS, Windows Server, Linux Server, Solaris Intel/SPARC, AIX, IBM iSeries (AS/400), Linux s390x for IBM Z. The full feature set is available across desktop, server, midrange, and mainframe environments.
Executive summary of a CardExpose scanning cycle.
That executive summary is what transforms Stage 3 from an intention into a real operational process. It provides responsible stakeholders with a tangible artifact to review during every cycle and allows them to compare results over time, determining whether the organization's actual exposure surface is growing or shrinking, which is ultimately the only metric that matters once the inventory has been properly validated.
