PCI DSS v4.0 requirement 12.5.2 requires you to document and confirm your PCI DSS scope at least once every 12 months and whenever there's a significant change to the in-scope environment. The confirmation has to cover data flows, every location where account data is stored, processed or transmitted, connected systems, segmentation, and third-party connections. It applies now to every v4.0 assessment.

That confirmation is only as reliable as your knowledge of where card data actually lives. Card data discovery, meaning a repeatable process for searching systems for primary account numbers (PAN), is how you find the copies nobody documented. With PCI DSS v3.2.1 retiring on March 31, 2024, many organizations are about to do their first formal 12.5.2 confirmation.

What does requirement 12.5.2 require?

Under v3.2.1, confirming scope each year was described in the introductory scoping section as something the entity should do before its assessment. PCI DSS v4.0 turned it into a requirement with defined content. At a minimum, the scoping validation includes:

  • Identifying all data flows for the various payment stages, such as authorization, capture, settlement, chargebacks and refunds, and acceptance channels, such as card-present, card-not-present and e-commerce
  • Updating all data-flow diagrams per requirement 1.2.4
  • Identifying all locations where account data is stored, processed and transmitted, including any locations outside the currently defined cardholder data environment (CDE), applications that process cardholder data, transmissions between systems and networks, and file backups
  • Identifying all system components in the CDE, connected to the CDE, or that could impact the security of the CDE
  • Identifying all segmentation controls in use and the environments the CDE is segmented from, including justification for environments being out of scope
  • Identifying all connections from third-party entities with access to the CDE
  • Confirming that all identified data flows, account data, system components, segmentation controls and third-party connections are included in scope

Notice the explicit mention of locations outside the currently defined CDE. The requirement assumes card data may have spread beyond where you think it is, and asks you to check.

Why isn't last year's scope good enough?

Scope drifts. Nobody decides to expand the CDE, but small operational decisions add up over a year.

A support team pastes card numbers into ticket notes to help a customer. A developer copies a production database into a test environment to debug an issue. Someone exports a settlement report to a spreadsheet and saves it to a shared drive. An application starts writing full request bodies to its logs after a debugging change. A backup job picks up a folder that was never meant to hold cardholder data.

Each of those creates a location that belongs in scope. If you don't know about it, your scope document is wrong, and so is every control decision built on it.

What is card data discovery?

Card data discovery is the practice of searching systems and storage for data that looks like PAN. Tools typically look for digit patterns of the right length, then filter them using the Luhn check and known card number ranges to cut false positives.

The guidance for 12.5.2 notes that a data discovery tool or methodology can be used to help identify all sources and locations of PAN. PCI DSS doesn't mandate a particular tool, but it's hard to confirm locations outside the CDE with confidence without some form of discovery.

Where card data tends to hide

Point discovery at the places where people and systems handle data informally:

  • File shares and document management systems
  • Workstations and laptops, especially in finance and customer service
  • Email stores and collaboration or ticketing platforms
  • Databases, including non-production copies
  • Cloud object storage and file-sync services
  • Application, debug and web server logs
  • Backups and archives
  • Data exports and reporting outputs

Tools versus process

Options range from data loss prevention and data classification platforms to cloud providers' built-in data classification features and scripted pattern searches. Each has gaps. Some can't read certain file formats, compressed archives or images, and some only cover one platform.

The process matters more than the tool. A good scan with poor coverage, or findings that nobody follows up, won't support your scope confirmation.

How do you run a card data discovery exercise?

A practical sequence for a small or mid-sized organization:

  1. Define coverage. Start from your system component inventory under requirement 12.5.1 and deliberately include systems outside the CDE, where unexpected data is most likely.
  2. Match methods to data types. Structured databases, unstructured files, cloud storage and endpoints often need different approaches.
  3. Run scans with the right access. Discovery that can't read a location can't find anything there. Treat scan results as sensitive, since they may themselves contain PAN.
  4. Triage the results. Separate real card numbers from test numbers and random digit strings that happen to pass validation.
  5. Respond to true findings. Securely delete the data, move it into the CDE, or extend the CDE to cover the location.
  6. Fix the cause. Find out how the data got there and change the process that put it there, or it will come back.
  7. Record the outcome. Keep what was scanned, what was found and what was done. That record feeds directly into your 12.5.2 confirmation.

What should you do when you find card data where it shouldn't be?

PCI DSS v4.0 adds requirement 12.10.7, which is best practice until March 31, 2025. It calls for incident response procedures that start when stored PAN is detected anywhere it isn't expected. Those procedures cover:

  • Deciding what to do with the PAN: retrieval, secure deletion or migration into the currently defined CDE
  • Identifying whether sensitive authentication data is stored with the PAN
  • Determining where the data came from and how it ended up where it wasn't expected
  • Remediating the data leaks or process gaps that caused it

Building these procedures now means your discovery program has a defined path for every finding, instead of an ad hoc scramble.

How often should you run data discovery?

At a minimum, run it before each annual scope confirmation and after significant changes. Examples include a new payment channel, a new data center or cloud platform, a network redesign, an acquisition, or a new third party with access to the CDE.

More frequent discovery narrows the window in which unexpected data can sit unnoticed. Designated entities, covered below, must do it every three months.

What is different for service providers?

Service providers have two additional scoping requirements, both best practice until March 31, 2025. Here's how they compare with 12.5.2:

Requirement Applies to What it requires Mandatory from
12.5.2 All entities Scope documented and confirmed at least every 12 months and upon significant change Now, for v4.0 assessments
12.5.2.1 Service providers Same scope confirmation at least once every six months and upon significant change March 31, 2025
12.5.3 Service providers Significant changes to organizational structure trigger a documented internal review of the impact on scope and control applicability, with results communicated to executive management March 31, 2025

Organizational changes such as mergers, restructures or a new outsourcing arrangement often shift who owns which systems. Requirement 12.5.3 makes sure that shift gets a scope review.

What does DESV require for data discovery?

Appendix A3, the Designated Entities Supplemental Validation (DESV), applies only to entities that a payment brand or acquirer designates. For those entities, it sets a more demanding standard for discovery:

  • A3.2.5 requires a data discovery methodology that confirms PCI DSS scope, locates all sources and locations of cleartext PAN at least once every three months and upon significant changes, and addresses the possibility of cleartext PAN on systems and networks outside the currently defined CDE.
  • A3.2.5.1 requires the methods to be tested for effectiveness, able to find cleartext PAN on all types of system components and file formats in use, and confirmed at least once every 12 months.
  • A3.2.5.2 requires response procedures when cleartext PAN is found outside the CDE, including identifying the source of the data and whether any track data is stored with it.

Even if DESV doesn't apply to you, it is a useful model. It spells out what a mature discovery program looks like.

Frequently asked questions

Is requirement 12.5.2 future-dated?

No. Requirement 12.5.2 is effective immediately for PCI DSS v4.0 assessments. Only the service provider requirements 12.5.2.1 and 12.5.3 are future-dated to March 31, 2025.

Does data discovery need to cover systems outside the CDE?

Yes. Finding PAN outside the currently defined CDE is the main reason to run discovery. Scanning only the systems you already know hold card data confirms very little.

Who is responsible for defining scope, us or our assessor?

You are. The entity defines and confirms its scope, and a Qualified Security Assessor validates it during the assessment. Arriving with a documented, evidence-backed scope confirmation makes that validation faster and reduces surprises.

What if discovery finds card data in a system we considered out of scope?

Treat it as a finding that needs a decision. Either remove the data and fix the process that created it, or bring the system into scope with the controls that entails. Document the outcome either way.

Next steps

  • Schedule your 12.5.2 scope confirmation and assign an owner.
  • Update your data-flow diagrams and system component inventory first.
  • Run card data discovery across in-scope and out-of-scope systems, and document coverage and results.
  • Write response procedures for unexpected PAN now, ahead of 12.10.7 becoming mandatory.
  • Service providers should plan for six-monthly confirmations before March 31, 2025.