Where is your card data? Set PCI DSS scope by scanning, not guessing

Every PCI DSS assessment starts with the same question: which systems hold card data? The answer sets the scope of the assessment, how long it takes, and what it costs.

Most organizations answer it by asking their teams. The payment system is known, and everyone knows card data lives there. The problem is that card data does not stay where it is expected. When a full card number turns up in a log table, a test database, or an Excel file, that system is in scope too, and it is written up as a finding in the assessment.

In this article we look at where card data leaks, what PCI DSS asks for, and why scanning is a safer way to set scope than guessing.

Where card data leaks

Card data usually spreads through everyday work, not through an attack. These are the places it turns up most often:

• Application and error logs: a developer logs the full request to debug an issue, and the card number goes into the log with it.
• Test and development environments: a copy of the production database is moved to a test environment without masking.
• Exported files: Excel and CSV files pulled for reporting or reconciliation stay behind in shared folders.
• Free-text fields: a customer service agent types the card number into a note or comment field.
• Old tables and backups: a table nobody uses any more is never dropped and is carried in backups for years.

What these places have in common is that nobody thinks of them as “systems that hold card data”. That is why they are missing from the inventory too.

The limits of a hand-kept inventory

In many organizations, the card data inventory is kept through a survey sent to teams or an Excel sheet. This approach has three weak points:

• It only shows what is already known. Teams list the places where they know their systems hold card data. Data that ended up in a log or a note field never makes the list, because nobody knows it is there.
• It is out of date the day it is finished. Every new table, report, and integration changes the inventory. A list updated once a year misses the twelve months in between.
• It is weak evidence in an assessment. “This is what the teams reported” does not carry the same weight as “every system was scanned, and this is the result”.

The only way to know for certain where card data is, is to look inside the systems: scan the tables and files and see what they actually hold.

Finding card data with Data Discovery

Data Discovery, the discovery module of Dataskope Suite, finds card data by looking inside your systems instead of asking your teams. Scans cover both databases and files, so a card number in a table and a card number in an Excel file forgotten in a shared folder end up in the same inventory. Data Discovery is agentless: nothing needs to be installed on the servers it scans.

Findings are classified and presented to your team on a review screen. The team approves or rejects each finding, and rejected findings are recorded. The inventory becomes a record your team has reviewed, not just an automatically generated list.

AI can be used for classification, but control stays with your organization:

• Sending actual column values to AI is a separate option, and it is off by default.
• An administrator can turn this off for the whole system.
• Which columns, how many values, and which model they were sent to are written to the audit log.

For data as sensitive as card numbers, this matters to teams who want to use AI without letting their data leave uncontrolled.

The PCI DSS report

The Data Discovery PCI DSS report brings scan findings together in a single report from a PCI DSS point of view. Because scans are repeated regularly, the report gives the annual scope confirmation required by Requirement 12.5.2 a current basis, not a one-off list.

Conclusion: know your scope, then shrink it

Knowing where card data is, is the first step toward PCI DSS compliance. Card data found in an unexpected place must either be protected or deleted, and either way, it has to be found first.

An inventory built by scanning has one more advantage: it reveals systems that hold card data for no good reason. Once card data is removed from those systems, the scope shrinks. A smaller scope means fewer systems to protect, a shorter assessment, and a lower risk of a data breach.