Most organizations comply with the cardholder data inventory required by PCI DSS on paper—or based on their confidence that they do. The problem begins when someone checks whether that paper corresponds to reality.
There is a PCI DSS v4.0 requirement that generates less debate than it should: 12.5.2, which requires maintaining an up-to-date inventory of all locations where cardholder data resides. On paper, it is simple. In practice, it is where one of the most common gaps we find during audits is concentrated.
The reason is almost always the same. The inventory is built by asking. The people responsible for each system are gathered and asked where they store cardholder data. Each one answers based on what they know, the responses are consolidated into a document, and that document is presented as the scope inventory. The problem is that the question “Where do you store cardholder data?” only captures the places where someone consciously decided to store cardholder data. And those are not, unfortunately, all the places where the data ends up.
The cardholder data environment that an organization declares is the one it designed: the transaction database, the payment system, the components that handle PAN data by design. The real CDE includes all of that, plus a long list of places where the data ended up without ever appearing on any architecture diagram.
Some of the most common examples are:
▪️Application logs that record complete requests, including the transaction body with the PAN in clear text, because someone enabled debug logging and never disabled it.
▪️Staging or pre-production databases containing copies of production tables, without masking, created for a specific project and later forgotten.
▪️Email attachments: a spreadsheet containing card numbers that one department sent to another, now residing in multiple mailboxes and their backups.
▪️All kinds of current files, but also files forgotten in disk spaces, file servers, and shared cloud storage.
▪️Compressed archives created by users and/or applications, using uncommon compression formats, sometimes used only by those applications.
▪️Temporary files, manual exports, incident dumps generated during troubleshooting activities and never removed.
None of these locations appear when you ask. Not because anyone wants to hide them, but because nobody remembers them—or never knew they existed. The debug log was enabled by a developer two years ago. The staging copy was created by a team that is no longer there. The attachment was sent by someone who considered it the most practical option at the time.
Screenshot 1: CardExpose Advanced Search Configuration
An inventory built by asking only captures what the organization remembers. Cardholder data does not reside where it is remembered—it resides where it ends up.
The capability that truly closes the gap is the one that looks where the data may have ended up, not where it is supposed to be: one that recursively enters compressed archives and nested containers, applies optical character recognition to images, connects to database engines, and traverses email containers. And it validates every finding rigorously—using the Luhn algorithm, issuer range validation, contextual analysis, and criticality classification of findings to facilitate the identification of false positives—so that the result is actionable and not an avalanche of false positives that the team eventually ignores.
Screenshot 3: CardExpose Findings Management