You shrank the CDE. Tokenized at the gateway. Got the ROC signed.

Now show me the evidence that no cardholder data lives outside that boundary.

Not the data-flow diagram. Not the notes from the annual scope review meeting. Scan results, file paths, timestamps, match counts, pulled from the systems you declared out of scope.

Most organizations can’t produce that. And they’re still compliant. That’s the part worth sitting with.

What 12.5.2 Actually Asks For

Requirement 12.5.2 is short, and people quote the first sentence as though it were the whole thing:

“PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.”

Annual. Documented. Fine. Everybody has a calendar reminder for that.

The part that gets skipped is four bullets down, in the list of what the scoping validation has to include at minimum:

“Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.”

Read that again with your own environment in mind. The standard is not asking you to confirm the boundary you drew. It’s asking you to go looking on the other side of it.

A diagram of your CDE cannot do that. By construction, a diagram contains what you already know about. The requirement is about what you don’t.

The Testing Procedure Is the Loophole

Here’s where it gets uncomfortable, and where I’d push back on my own framing from a minute ago.

The testing procedures for 12.5.2 are 12.5.2.a and 12.5.2.b. Together they tell the assessor to:

“Examine documented results of scope reviews and interview personnel to verify that the reviews are performed… Examine documented results of scope reviews performed by the entity to verify that PCI DSS scoping confirmation activity includes all elements specified in this requirement.”

Examine documents. Interview personnel.

So the diagram and the interview notes do count. They satisfy the test exactly as written. A QSA who reviews your scope memo, confirms it has all seven bullets addressed, and interviews the team that produced it has done their job correctly and completely.

Which means an ROC can be entirely accurate and entirely blind at the same time. Those aren’t in tension. Nobody in that room was ever required to look for a PAN.

The standard does name the technique, but only in the guidance column, where it’s a suggestion, not a control:

“A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE.”

Can be used. That’s the entire mandate for actually searching. The one activity that would catch the thing 12.5.2 exists to catch is optional.

The Retailer

A retailer I won’t name had a genuinely good setup. Tight segmentation. Tokenization at the gateway, so the CDE held tokens and almost nothing else. A satisfied QSA and a clean report, year over year.

The corporate file shares were out of scope by definition. They’d never been in an assessment, so nobody had ever pointed a scanner at them.

Then someone did.

Finance had been exporting chargeback disputes from the payment portal to a spreadsheet. Once a month. Full PAN in every row. For years. The file sat in a folder called “Disputes,” a few rows down from the vacation calendar.

That spreadsheet was the scope.

Everything the ROC said about segmentation was true. It was just true about the wrong boundary.

Nobody missed anything. Nobody had looked.

And note what the export wasn’t. No rogue admin, no shadow IT tool. A finance analyst doing her job through the only workflow anybody had given her. The dispute process required the data. The out-of-scope share was where the team’s files lived. Both of those decisions were reasonable in isolation.

That’s the pattern in almost every one of these I’ve seen. The PAN doesn’t escape. Somebody carries it out, for a reason that made sense at the time, into a place nobody is chartered to inspect.

Why Nobody Runs the Scan

There’s a reason this gap persists, and it isn’t laziness.

Discovery is the only control in PCI DSS that punishes you for working.

Every other control gets easier when it succeeds. A clean vulnerability scan, a passing config review, a closed finding, all of those make your assessment shorter. Find PAN on a corporate file share and you’ve just expanded your own scope, possibly weeks before your assessment window, with a finding you now have to remediate and document.

Say that out loud in a QBR and watch what happens. The team that just did the most responsible thing in the building is now the reason the program slipped.

So the scan doesn’t get scheduled. Not because anyone decided against it, because nothing ever forces the decision, and the incentives quietly point the other way.

Two smaller things compound it:

Per-gigabyte pricing. If your discovery tool bills by volume, the corporate file share is the most expensive place you could point it and the least likely to be in scope. The pricing model itself argues for not looking. Anybody who has priced a full sweep of an unstructured file estate against a per-GB rate has had this exact conversation with their own budget.

The assessor-did-it assumption. This one the standard closes explicitly. Read the applicability note on 12.5.2:

“This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the annual assessment.”

Your QSA’s scoping work is not your 12.5.2 confirmation. If the only scope validation in your program happened during the assessment, you have a gap in 12.5.2 regardless of what the ROC says.

What Evidence Looks Like

The distinction that matters isn’t diagram versus scan. It’s assertion versus artifact.

The zero-finding results are the ones people skip, and they’re the most valuable thing in the folder. “We scanned the corporate shares and found nothing” is evidence. “The corporate shares are out of scope” is a claim. Only one of those survives a forensic investigation.

If you want a shortlist of where to point the scanner first, it’s not exotic:

• The finance team’s working folders, wherever disputes, chargebacks, and refunds get worked by hand
• Shared mailboxes and the attachments in them, especially anything a customer can email into
• The reporting share where somebody exports “just to check the format” and never deletes
• Call center recordings and screen captures, if you capture either
• Backup sets and the restore staging area, which is usually flatter than the environment it came from
• Developer laptops and test fixtures, where production extracts go to be “sanitized”

Every one of those sits outside a well-drawn CDE. Every one of them is named or implied by 12.5.2’s bullet list.

Making It Routine Instead of Heroic

A few things that make this survivable rather than a special project:

Run it early. Point discovery at the out-of-scope estate before your assessment window, not during it. You want time to remediate a finding rather than negotiate it. If you’re a service provider, 12.5.2.1 already has you confirming scope every six months: that stopped being a best practice and became a requirement on 31 March 2025, so build the cadence around that.

Decouple cost from volume. As long as thoroughness carries a per-gigabyte price, someone will scope the sweep down to what the budget tolerates, and the forgotten share will keep being forgotten. Flat-rate discovery exists partly so that the answer to “should we also scan that 40TB of old file shares” can be yes without a budget conversation. We built Risk Finder to run as a container inside your own network, on your own file shares, so pointing it at a system you’ve declared out of scope costs you an afternoon instead of an approval. That’s the whole reason the pricing works the way it does.

Keep the negative results. File them with the scope memo. Two years of dated sweeps showing nothing outside the CDE is a far stronger position than a current-year diagram, both with your QSA and with whoever shows up after an incident.

Tie it to 3.2.1. That requirement already obliges you to verify at least once every three months that stored account data past its retention period has been securely deleted, with “coverage for all locations of stored account data.” Same locations. Same scan. Different requirement to satisfy with it.

Write down the exclusions. What you didn’t scan, and why. An honest exclusions list is a defensible artifact. A silent exclusion is the thing that gets read back to you in a deposition.

Descoping is still the right strategy. Segmentation isn’t even a PCI DSS requirement, the standard recommends it because it genuinely shrinks your risk, your cost, and the number of places cardholder data can go. None of that is wrong.

But the boundary is a hypothesis. Twelve months of business change, one new dispute workflow, one analyst with a deadline, and it’s a hypothesis that nobody has retested.

If you never searched outside the line you drew, the ROC didn’t confirm your scope. It confirmed your confidence.

→ Related reading: what a full sensitive-data sweep actually costs when you price it per gigabyte, and why that number decides how much of your environment gets looked at.

All PCI DSS requirement text quoted from Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1, June 2024 (PCI Security Standards Council). Requirements 3.2.1, 12.5.1, 12.5.2, and 12.5.2.1. v4.0.1 is the current revision of the standard; requirement numbering is unchanged from v4.0. Requirement 12.5.2.1 applies to service providers only and became mandatory on 31 March 2025.