Your CDE Has Grown. Your Scope Document Hasn't. Here's How to Reconcile the Two.

A cardholder data environment (CDE) includes the systems that store, process, or transmit cardholder data, plus any systems connected to those components or able to impact their security. The PCI DSS scope conversation hinges on which systems are in that CDE today, which is harder to answer in 2026 than it was five years ago.

The Head of Card Issuing at a Tier-1 BaaS provider asked her team a simple question last quarter: how many services touch a PAN today?

She got three answers.

The architecture diagram, last refreshed at the program's launch, said 47. The static asset inventory that the AppSec team pulled the night before said 112. The runtime trace of what was actually executing in production that week showed 237 services calling the card platform's APIs, of which only 11 actually loaded Primary Account Number (PAN) into memory.

Three different numbers. None of them is enough on its own. But only one reflects how the environment is actually behaving in production, which is where a defensible scope conversation has to begin.

That gap between the Cardholder Data Environment (CDE) you documented and the CDE you're running is the quiet story of the last five years of embedded finance. Every BaaS partner you onboarded, every white-label program, every AI-driven journey wired into the cardholder flow nudged the boundary outward by a service or two. Almost none of those changes made it back into the scope doc.

Why the CDE Grew Without You Noticing

The shape of card issuing has changed faster than the shape of compliance review.

A 2018 issuer ran a card platform behind a tokenization service and called it a day. A 2026 issuer runs the same core, but it's wrapped in fintech partner SDKs, embedded checkout flows from non-financial brands, white-label programs for neobank customers, push provisioning into wallets, AI-powered dispute and Know Your Customer (KYC) journeys, and a growing perimeter of webhooks and event buses fanning data outward.

Each of those is a perfectly good business reason. Each also extends the data path. And almost none of them trigger an update to the network diagram in your last assessment binder.

This isn't a compliance team failure. It's structural. Scope documents are written once, reviewed quarterly at best, and capture the program as someone understood it on the day they sat down with Visio. Runtime changes every deployment.

The Three Versions of Your CDE

When a Head of Card Issuing asks what's in scope, three artifacts can answer. They almost never agree.

The architectural CDE is what the scope diagram and SAQ describe. It's a model, useful for orientation, accurate on the day it was drawn, and progressively wrong from then on. A QSA will read it. They won't believe it on its own.

The inventory CDE is what static scans and Configuration Management Database (CMDB) exports produce. It's broader, often dramatically so, because it counts every service that could reach the card platform: every microservice with a network path, every container with a credential to the tokenization API, every Lambda the partner team spun up last sprint. It overstates scope because it can't see what code actually runs.

The runtime CDE view shows what is executing in production right now. It identifies which services invoke card APIs, which call paths carry PAN or sensitive authentication data, and which load balancers, queues and dependencies sit on the data path under real traffic.

It does not replace the scope document, the data-flow diagram or the QSA’s assessment. It makes them more defensible. Runtime evidence helps teams add services the diagram missed, challenge over-broad inventory assumptions, and separate systems that handle account data from systems that are merely adjacent, provided segmentation and security-impact assumptions can also be validated.

The first two are documents. The third is evidence.

How PCI DSS 4.0 and CDE Scope are Changing for Teams in 2026

The shift toward provable, current-state scope is not a Kodem opinion. It reflects where payment security assessments and financial supervision are moving: away from static documentation and toward evidence that shows how systems actually behave.

PCI DSS v4.0.1 makes scoping a recurring discipline, not a one-time diagram exercise. Organizations need to understand which system components store, process or transmit account data, and which systems can impact the security of those components. For service providers, scope also needs to be confirmed more frequently and after significant changes to the in-scope environment. In a BaaS architecture, where partner integrations, APIs, webhooks and new data flows change continuously, that makes stale scope documentation a practical risk. 

FCA Consumer Duty frames the issue differently. It does not prescribe CDE methodology, but it does require firms to act to deliver good outcomes for retail customers, use data to monitor those outcomes, and ensure boards have enough evidence to oversee customer-impacting risks. For embedded finance and card-issuing journeys, weak visibility into where customer data flows can quickly become a governance and reporting problem. 

CCD2, the recast EU Consumer Credit Directive, also does not tell firms how to map technical scope. Its relevance is broader: consumer credit journeys increasingly involve creditors, intermediaries, embedded channels and digital data flows. That makes it harder for firms to rely on outdated architecture diagrams when they need to explain which parties and systems are involved in the customer journey. 

Read together, these regimes do not mandate runtime evidence. But they do reward organizations that can prove the current state of their environment, not just describe the state they documented last year.

A Runtime View of an Embedded Issuing Stack

Here's what the runtime view shows in an anonymized real-world case.

A mid-tier embedded issuer runs a card platform consumed by 14 partner programs. The architecture diagram shows the card platform behind a tokenization service, fronted by an API gateway, with partner programs calling through. Forty-seven services in scope. Clean.

Static inventory tells a different story. The card platform's APIs are reachable, on the network, from 112 services across the broader estate: partner microservices, internal ops tools, an analytics pipeline, three generations of dispute service, two AI agents handling KYC edge cases, the data lake's ingestion workers.

The runtime trace, taken over a representative week, shows that 237 services made calls to the card platform. That number is higher than the inventory because the trace caught dynamic invocations and partner ephemera the static scan missed. Of those 237, only 11 actually loaded PAN into process memory. The other 226 called token-handling endpoints, status checks, or metadata APIs that never touched cardholder data at all.

That distinction is what the whole exercise rests on. The 226 are reachable but not on the data path. With evidence (call traces, memory inspection, data-flow proof), they can be carved out of scope without weakening the perimeter. The 11 get hardened, segmented, and audited as the true CDE.

The diagram missed services. The inventory overcounted them. Only the runtime view did both jobs at once.

We built a worksheet that walks you through this reconciliation for your own environment. Interactive, free, no demo required. Get the CDE Runtime Mapping Worksheet →

Reconciling the Three Views: A 90-Day Approach

You don't need a year-long program to close the gap. The work sequences cleanly into a quarter.

Weeks 1–3: Pick one service and instrument it. Choose a representative service on or near the card platform, ideally one whose scope status is genuinely contested internally. Capture runtime evidence: which services call it, which calls carry PAN versus tokens versus metadata, which call paths persist data.

Weeks 4–6: Reconcile against the scope document. Walk the evidence against the current diagram and the static inventory line by line. Expect three categories to emerge: confirmed in scope (matches the doc), undocumented in scope (the diagram missed it), and over-scoped (the inventory included it but runtime says it's not on the data path).

Weeks 7–9: Re-baseline tokenization and segmentation assumptions. The over-scoped category is where scope reduction lives. For each candidate, document the runtime evidence, validate the tokenization boundary, and prepare the carve-out argument you'd make to a QSA.

Weeks 10–12: Push the updated scope through change control and present at the next quarterly compliance review. Bring the evidence, not just the new diagram. The goal is to make the picture defensible, not just to redraw it.

By the end of the quarter you have one service of solid scope evidence, a method for the next, and a story to tell the board.

Calmer Compliance, Smaller Surface

The counterintuitive result of this work: scope usually shrinks.

When teams move from “everything that has ever appeared near the card platform” to a documented view of what carries account data, what is connected to it, and what can impact its security, the scope conversation becomes much more precise. Some systems will move in. Some may move out. The important point is that the decision is backed by evidence. A smaller footprint means fewer controls to evidence, a shorter list of systems in the annual assessment, and fewer change windows that trigger re-review. The audit gets calmer.

It also means the controls you do invest in land on the systems that actually need them. The eleven, not the two hundred and thirty-seven.

The scope document was never wrong on purpose. It just stopped being the answer.

Map your own CDE: Download the CDE Runtime Mapping Worksheet → Interactive, free, no demo required.

Going deeper: Watch how fintech and BaaS teams use runtime evidence to validate embedded issuing scope.

Kodem helps fintech SaaS, wealth-tech, and lending platforms produce the runtime evidence modern procurement reviews demand. This piece is part of our 2026 series on the structural shifts reshaping AppSec in regulated industries.

References

1. Kodem Security. November 4, 2025. From Reachability to Reality: Proving Vulnerable Code was Executed & Exploited in Production. Kodem Security.