How to find stored card data before a PCI DSS assessment.

Begin with the retention obligation.

PCI DSS Requirement 3.2.1 addresses keeping account-data storage to a minimum. Its retention and disposal process covers all stored-account-data locations, documented retention periods and business justification, secure deletion when data is no longer needed, and verification at least every three months that data beyond the defined retention period has been made unrecoverable.

PCI SSC does not prescribe a universal minimum or maximum retention period. The organisation defines what is necessary for legal, regulatory and business purposes, protects any retained data, and removes it when it is no longer required. Sensitive authentication data is subject to a separate and stricter prohibition after authorisation.

Primary sources: PCI SSC FAQ 1318 and PCI DSS SAQ D, Requirement 3.2.1.

Start by collecting the organisation's retention policy, schedule and current system inventory. The discovery exercise should test an understood policy and data-flow model, not substitute for them.

Map where payment data could travel or persist.

Requirement 12.5.2 requires the entity to document and confirm PCI DSS scope at least annually and after a significant change. Its minimum activities include identifying payment flows and acceptance channels, then identifying storage, processing and transmission locations. These include locations outside the currently defined cardholder data environment, relevant applications, system-to-system transmissions and file backups. The entity's confirmation is distinct from the assessor's scoping confirmation during the assessment.

Primary source: PCI DSS SAQ D, Requirement 12.5.2.

Use interviews, data-flow diagrams, system inventories and operational knowledge to create a candidate list. Depending on the organisation, that list might include:

• exports from ecommerce, booking, point-of-sale or finance systems;
• spreadsheets and reports created for reconciliation, disputes or customer support;
• shared drives, collaboration folders and local working directories;
• documents, PDFs, images or scanned paperwork;
• archives and backups retained beyond their intended period; and
• migration, testing or historical data left after a system change.

Define coverage before starting the scan.

Record the systems, directories and file types selected for inspection. Also record deliberate exclusions and the reason for each one. If an environment is too large for one run, divide it into named, repeatable scan units rather than relying on an informal sequence that will be difficult to reconstruct later.

Coverage should describe what actually happened. A file may be selected but not fully inspected because it is encrypted, corrupt, unreadable, unsupported or exceeds an approved safety limit. Those outcomes are not equivalent to a clean result. Preserve them so the team can decide whether to change the scan approach, inspect the file another way or document an accepted limitation.

Avoid introducing an unnecessary network path.

Payment environments are often deliberately isolated. Before introducing any discovery tool, check its provenance, installer signature, included components, update behaviour, network dependencies and handling of findings.

Where isolation is an important control, a scanner that can be activated and run locally avoids creating a new route merely to send files or findings to a hosted analysis service. This is a deployment and risk-management consideration, not a universal statement that PCI DSS requires every discovery tool to be offline. The organisation should choose and approve the transfer, installation and update process that fits its environment.

Use the card-data scanner buyer's checklist →

Separate candidates from reviewed findings.

Pattern matching and OCR identify candidates for review. They do not establish the business context of a number or decide whether it is a real PAN that needs action. Test data, false positives, legitimately retained data and data that should be removed can initially look similar.

Use a controlled review step and avoid copying complete card numbers into tickets, notes or reports. A useful review record includes a masked reference, the source location, the decision, a concise reason, an owner and any remediation action.

Confirmed

A real PAN requiring protection, retention justification or remediation.

Resolved

Action has been completed and recorded.

Not a PAN

Reviewed and determined not to be payment card data.

Test data

Recognised controlled test material that is not a customer finding.

The labels matter less than applying them consistently and retaining enough context for another reviewer to understand the decision without exposing the complete number.

Retain evidence of findings and limitations.

A useful evidence record should make the discovery work reproducible and bounded. Consider retaining:

• the date, approved operator, tool and version;
• selected locations and deliberate exclusions;
• file and content types the tool was configured to inspect;
• successfully scanned, partially scanned and unscanned outcomes;
• masked candidate findings and their review decisions;
• remediation ownership and status; and
• an explicit statement of coverage limitations and follow-up work.

This gives the PCI programme owner and QSA something more useful than a screenshot of a result count. It shows the relationship between the search plan, actual coverage, reviewed findings and resulting action. It supports the assessment conversation but does not replace assessor judgement or the other evidence required for PCI DSS.

Open the sample evidence report →

Make discovery repeatable.

Stored-data discovery should not exist only as a last-minute assessment exercise. Revisit the search plan when payment flows, applications, service providers, business processes or storage locations change. Align recurring verification with the organisation's retention process and risk decisions.

Requirement 3.2.1 specifically requires a process that verifies at least every three months that stored account data beyond the defined retention period has been securely deleted or rendered unrecoverable. That does not prescribe one scanner or mean that every environment must run the same scan every quarter. The organisation must design a process that reliably provides the required outcome.