Tokenization and PCI Scope

Tokenization and PCI Scope: How Tokenized Payments Can Reduce Card Data Exposure

The most useful question about payment tokenization is not whether a merchant “uses tokens.”

It is:

Where does the primary account number appear before it becomes a token, who can turn the token back into—or otherwise gain access to—the PAN, and which systems can affect that process?

Those details determine whether tokenization materially reduces the merchant's exposure to cardholder data and potentially reduces the scope of its Payment Card Industry Data Security Standard (PCI DSS) environment.

Payment tokenization replaces a card's primary account number (PAN) with another value—a token—that can be used for a defined payment purpose without requiring the merchant to store the PAN in every downstream system. Properly designed tokenization can therefore reduce the number of systems that store, process, or transmit cardholder data. It does not, by itself, make a merchant PCI compliant or eliminate all PCI DSS responsibilities.

That distinction—reducing exposure and scope rather than assuming compliance disappears—is the central architectural question for merchants evaluating tokenized payments.

As of August 2026, PCI DSS v4.0.1 remains the currently published PCI DSS version; PCI SSC opened a stakeholder request for comments on v4.0.1 in June 2026.

What is payment tokenization?

Payment tokenization substitutes a PAN with another identifier.

Conceptually:

PAN:

4111 1111 1111 1111

↓

Tokenization service

↓

Token:

tok_8X7...

The exact format varies.

The important property is not that the token looks different from a card number. It is that the token's relationship with the underlying PAN is controlled so exposing the token does not automatically expose the original card credential.

PCI SSC describes tokenization as replacing PAN with a surrogate value and notes that storing the token instead of PAN can reduce the risk associated with unauthorized PAN disclosure.

A merchant might then use the token to:

•identify a customer's stored payment method;

•initiate later card-on-file transactions through its PSP;

•process subscription renewals;

•issue refunds through the provider;

•associate transactions with the same saved credential.

The raw PAN can remain inside a provider-controlled tokenization environment rather than appearing throughout the merchant's databases, applications, support systems, analytics infrastructure, and internal APIs.

How does tokenization work?

A basic provider-tokenization flow looks like this:

Customer enters card details

↓

PAN is securely sent to payment/tokenization provider

↓

Provider receives PAN

↓

Provider creates or maps a token

↓

PAN remains within the protected payment/token environment

↓

Merchant receives token

↓

Merchant stores token for permitted future use

The critical moment is the beginning of that flow.

Where does the PAN first appear?

If the customer's browser sends the PAN directly to a PCI DSS compliant payment provider without the merchant's systems receiving it, the merchant's exposure can be substantially different from an architecture where:

Customer

→ merchant checkout

→ merchant API

→ merchant server

→ PSP

→ token returned.

In the second architecture, tokenization happens only after the merchant has already processed and transmitted the PAN.

The fact that the merchant later stores only a token does not erase what happened earlier in the payment flow.

That is why PCI scope should be analyzed from the point of card-data capture onward, not only by looking at what is stored in the merchant's database.

Token versus PAN

A PAN is the primary account number associated with a payment card account.

A token is a substitute identifier.

But the label “token” does not automatically mean:

“Not PCI data.”

PCI SSC's tokenization guidance makes the scope question dependent on properties including whether PAN recovery is feasible, whether the system can submit de-tokenization requests, whether it can access the token vault or cryptographic material, whether it is connected to the cardholder data environment, and whether it handles cardholder data through another channel.

This distinction matters because two strings both called “tokens” can have very different security characteristics.

Tokenization is not the same as encryption

Encryption and tokenization can both protect payment information, but they work differently.

Encryption

Encryption transforms the PAN using cryptography.

An authorized party holding the appropriate cryptographic key can decrypt the ciphertext and recover the PAN.

Conceptually:

PAN

→ encryption + key

→ ciphertext

→ decryption + key

→ PAN.

PCI SSC states that encryption is an accepted method of rendering cardholder data unreadable, but encryption alone does not necessarily make the encrypted cardholder data or the systems handling it out of PCI DSS scope. Systems performing encryption, decryption, or key-management functions can remain in scope.

Tokenization

Tokenization replaces the PAN with a surrogate value.

Depending on the design, the relationship may be held in a secure token vault or implemented through another controlled mechanism.

Conceptually:

PAN

→ tokenization

→ token

with the PAN-token relationship isolated from ordinary merchant systems.

So:

Encryption protects card data while retaining the card data in an encrypted form. Tokenization replaces the PAN with another value and can allow many merchant systems to stop handling PAN altogether.

Both can be useful. They solve different architectural problems.

What is a token vault?

A token vault is a protected environment that maintains the association between tokens and the underlying payment credentials in tokenization designs that require such mapping.

For example:

Token

Underlying PAN

tok_A

PAN A

tok_B

PAN B

tok_C

PAN C

Ordinary merchant applications may see only the left-hand column.

The tokenization provider protects access to the mapping.

From a PCI perspective, the vault is not the part of the architecture that tokenization magically removes from scope. It is precisely where sensitive relationships are concentrated.

PCI SSC's tokenization guidance treats elements involved in token generation, de-tokenization, and PAN storage as part of the cardholder data environment. Systems that can generate a token from PAN, retrieve PAN from a token, or access those tokenization processes can also be in scope.

Tokenization therefore works partly by centralizing sensitive exposure rather than pretending the exposure no longer exists.

Provider tokens and network tokens are different

Merchants may encounter several different token types.

Provider or acquiring tokens

A PSP, acquirer, merchant, or merchant service provider can create a proprietary token after receiving a customer's payment credentials.

The merchant might store:

customer_payment_method = tok_xyz

and submit that identifier to the provider for future recurring or card-on-file transactions.

PCI SSC calls these acquiring tokens in its token taxonomy. They are provider-specific rather than based on the standardized EMV Payment Token framework.

Their PCI scope implications depend on the actual tokenization architecture.

Network payment tokens

EMV Payment Tokenisation uses payment tokens provisioned through registered Token Service Providers under the EMVCo framework. They can replace PAN in payment transactions and can be constrained through token-domain controls.

EMVCo documents merchant use cases where a Token Service Provider provisions a payment token to the merchant and manages its lifecycle.

PCI SSC gives qualifying EMV Payment Tokens a particularly important treatment: where an EMV Payment Token is defined and used according to the EMVCo specification and exists outside the Token Service Provider's token data environment, PCI SSC states that it is not considered PCI Account Data and therefore is not itself in PCI DSS scope. Systems remain in scope if they also handle Account Data or are connected to systems that do.

That treatment should not be generalized to every proprietary string described as a token.

What does PCI DSS scope actually mean?

PCI DSS scope is broader than:

“Which database contains card numbers?”

The cardholder data environment (CDE) includes the systems, people, and processes involved in storing, processing, or transmitting relevant cardholder data or sensitive authentication data.

Current PCI materials also identify systems that can impact the security of account data or the CDE as potentially relevant to scope. Examples can include ecommerce web redirection systems and security or infrastructure components affecting the CDE.

That is why scope analysis asks not merely:

Does this server store PAN?

but also:

•Does it process PAN?

•Does it transmit PAN?

•Can it retrieve PAN?

•Can it access the tokenization system?

•Is it connected to the CDE?

•Can it affect the security of the payment flow?

•Does another channel expose account data to it?

Tokenization can change the answers to many of those questions.

How can tokenization reduce PCI scope?

Imagine a merchant without tokenization.

PAN may appear in:

checkout

→ web application

→ payment API

→ payments database

→ subscription engine

→ customer-support tooling

→ refund workflow

→ analytics/export processes.

Each occurrence expands the number of places requiring card-data protection and assessment.

Now redesign the architecture:

Customer

→ provider-controlled card-data collection

→ tokenization provider / vault

→ token returned to merchant

→ merchant systems use token only.

Merchant systems might now contain:

•customer ID;

•PSP payment-method token;

•card brand;

•expiry metadata where appropriate;

•masked display information such as last four digits;

rather than full PAN.

PCI SSC's tokenization guidance says adequately segmented systems that store, process, or transmit only suitably designed tokens—and do not handle cardholder data or have access to the tokenization environment—may potentially be outside the CDE and possibly outside PCI DSS scope.

Potential beneficiaries can include some:

•business applications;

•customer databases;

•subscription systems;

•CRM platforms;

•internal analytics;

•support tooling.

But whether a particular system is actually out of scope needs to be established against the merchant's real architecture and current PCI DSS requirements.

When does tokenization not remove a system from scope?

Tokenization does not automatically reduce scope merely because the database contains tokens instead of PAN.

A system can remain in scope when it:

•receives PAN before tokenization;

•stores or transmits cardholder data through another path;

•can request de-tokenization and retrieve PAN;

•has access to the token vault;

•has access to relevant cryptographic material;

•is connected to the CDE in a way that brings it into scope;

•can materially affect the security of the cardholder data environment.

PCI SSC specifically says systems handling only tokens need additional characteristics before they can potentially be considered out of scope, including effective isolation from de-tokenization capabilities, the vault, cryptographic keys, and the CDE.

So the right question is not:

“Do we store tokens?”

It is:

“What can somebody do from the system that stores those tokens?”

A token can also remain operationally sensitive even if it cannot reveal PAN. Depending on provider design, possession of a token plus access to merchant payment APIs might enable payment actions. Tokens therefore still deserve appropriate authorization, access control, monitoring, and application security.

Checkout architecture often determines the scope benefit

Tokenization is most effective for scope reduction when raw card data is diverted away from merchant-controlled systems as early as possible.

Hosted payment page

The customer is redirected to a payment page supplied by the payment provider.

Card details go directly to that provider.

This can substantially reduce merchant exposure to PAN.

Provider-hosted iframe or hosted fields

Provider-controlled payment fields are embedded in the merchant experience while card data is sent directly from the customer's browser to the provider.

The precise implementation matters.

PCI SSC's current guidance says SAQ A eligibility for ecommerce requires all elements of the payment page involved in collecting or processing payment-card data to originate directly from PCI DSS compliant service providers, together with the other SAQ eligibility conditions. For iframe implementations, card-data capture elements need to remain within the provider-controlled iframe.

A merchant should therefore not assume:

“Hosted fields = SAQ A.”

It should confirm the exact implementation and validation criteria with its acquirer, payment provider, and assessor where appropriate.

Merchant-side API integration

If the merchant's backend receives:

PAN + expiry + security code

and then sends those details to a PSP API for tokenization, the merchant has already handled account data.

Replacing the PAN with a token afterward can reduce downstream storage exposure, but the systems receiving and transmitting the original card information remain relevant to PCI scope.

This is why two merchants using the same provider token can have radically different PCI environments.

Tokenization is particularly useful for recurring payments

Subscription and stored-payment businesses need a way to charge an established payment method later without asking the customer to re-enter PAN for every transaction.

Without tokenization, the merchant might be tempted to retain card credentials itself.

A better architecture can be:

Customer provides card once

→ provider captures/tokenizes card

→ merchant stores token

→ subscription engine stores token reference

→ merchant sends token for renewal

→ provider uses protected credential relationship to process payment.

The subscription platform, CRM, billing scheduler, and customer-service tooling can potentially operate without storing full PAN.

Network payment tokens can add further capabilities, including token lifecycle management. EMVCo documents lifecycle processes in which a Token Service Provider can manage the relationship between a merchant's stored payment token and changes to the underlying PAN.

[Internal link opportunity: Storing Customer Payment Data]

Tokenization has benefits beyond PCI scope

Scope reduction is valuable, but tokenization can also improve architecture.

It can help merchants:

•minimize persistent PAN storage;

•reduce the number of internal services receiving sensitive payment credentials;

•centralize credential protection;

•limit the impact of some database exposures;

•give developers safer identifiers for payment-method references;

•prevent PAN from spreading into logs, support tools, exports, and analytics;

•make recurring-payment systems less dependent on merchant-held raw credentials.

The security goal is not simply to pass an assessment with fewer systems.

It is to make the architecture contain less valuable payment data in the first place.

Questions to ask a tokenization or payment provider

Before assuming a provider's tokenization product will reduce PCI DSS scope, ask:

•Where does the PAN first go when the customer enters it?

•Does PAN ever pass through merchant-controlled JavaScript, servers, APIs, logs, or databases?

•Who creates the token?

•Is it a proprietary provider token or an EMV Payment Token?

•Can the merchant reverse or de-tokenize the token?

•Can merchant systems request the underlying PAN?

•Where is the token vault located and who operates it?

•Which provider services are covered by current PCI DSS validation?

•Which parts of the merchant architecture can realistically move outside the CDE?

•Which systems remain in scope because they can affect the security of the payment flow?

•Which SAQ or validation path may apply to the proposed integration?

•How are recurring and card-on-file payments initiated with the token?

•Are network tokens supported, and how is their lifecycle managed?

•What happens if the merchant changes payment providers?

•Can token values be exported or migrated, or are they provider-specific?

The last questions matter commercially as well as technically. Tokenizing credentials with a PSP can reduce sensitive-data exposure while simultaneously creating dependency on that provider's token namespace.

That trade-off should be understood before architecture is finalized.

Final takeaway

Tokenization can materially simplify payment-data architecture, but PCI scope reduction comes from where cardholder data stops flowing, not from the word “token.”

The strongest architecture is generally one in which:

customer enters PAN

→ trusted payment infrastructure receives it directly

→ PAN is protected inside the appropriate cardholder/token environment

→ merchant receives a limited-use token

→ ordinary merchant systems operate without raw PAN.

The systems that create tokens, store or access PAN, reverse tokenization, or otherwise remain connected to or capable of affecting the cardholder data environment can remain subject to PCI DSS requirements. Systems handling suitably designed tokens in properly isolated environments may potentially move outside the CDE, but that conclusion depends on the token and the architecture.

That is why provider-side tokenization can be valuable for merchants designing a new checkout, subscription platform, or international payment architecture. Moving raw credentials out of merchant systems early can reduce exposure and simplify the environment that needs to be protected and assessed.

It does not replace PCI DSS.

It changes the architecture to which PCI DSS applies.

The practical objective should therefore be: handle the minimum amount of raw payment data necessary, for the minimum amount of time, in the minimum number of systems—and use appropriately designed tokenization to keep it that way.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

This article has a strong technical core, but it would benefit from a more explicit information-design layer around the architecture question: where does PAN appear, where does tokenization occur, and what remains capable of affecting the cardholder data environment? That is the decision-oriented search intent the brief is aiming at.

SEO recommendations — not part of the article

Recommended SEO title:

Tokenization and PCI Scope: How Payment Tokens Reduce Card Data Exposure

Alternative:

PCI Tokenization Explained: How Tokenization Can Reduce PCI DSS Scope

Meta title:

Tokenization and PCI Scope | PCI DSS & Payment Tokens

Meta description:

Learn how payment tokenization can reduce cardholder data exposure and PCI DSS scope, including token vaults, hosted checkout, network tokens, recurring payments, and the systems that can remain in scope.

Recommended slug:

/data-protection/tokenization-pci-scope/

tokenization and PCI scope

Secondary targets:

•PCI tokenization

•tokenization PCI compliance

•payment tokenization

•reducing PCI scope

•tokenization PCI DSS

•token vault PCI

•payment token vs PAN

•network token PCI scope

•tokenization vs encryption PCI

•hosted fields PCI scope

Useful long-tail searches:

•does tokenization reduce PCI scope

•does tokenization remove PCI compliance

•are payment tokens in PCI scope

•are network tokens PCI data

•does using Stripe-like/PSP hosted fields reduce PCI scope

•tokenization vs encryption for PCI DSS

•does a token vault remain in PCI scope

•can tokenized card data be out of scope

•PCI scope hosted payment page vs API integration

•tokenization recurring payments PCI

Featured-snippet answer

I would place a concise definition immediately after the opening:

Payment tokenization can reduce PCI DSS scope by replacing card primary account numbers with tokens so fewer merchant systems store, process, or transmit cardholder data. It does not automatically eliminate PCI responsibilities: systems that receive PAN, perform tokenization or de-tokenization, access the token vault, or can affect the cardholder data environment may remain in scope.

That captures the article's entire decision logic in roughly 50 words.

Editorial recommendations

The article already follows the brief well. The biggest opportunity is to make scope analysis visual and architectural rather than purely textual.

The brief specifically asks the article to cover checkout architecture, hosted pages, hosted fields, SDKs/API integrations, recurring billing, token vaults, and why tokenization does not automatically remove PCI obligations.

I would make these refinements:

Recommendation

Why it helps

Turn “Where does PAN first appear?” into a recurring decision question

This is the clearest way to explain why two merchants using the same token provider can have different PCI scope.

Add a three-architecture comparison

Hosted page vs hosted fields vs merchant API is likely the most useful practical section for engineering and payment teams.

Promote “token ≠ automatically out of scope” into a callout

Corrects the article's most dangerous misconception.

Make tokenization vs encryption a compact visual rather than longer prose

Easier for technical readers to retain.

Separate provider tokens and network tokens visually

Prevents readers assuming all tokens receive the same PCI treatment.

Add a “what can this system do?” scope test

More operationally useful than asking only what data a system stores.

Add a pre-integration provider checklist

Strong fit with decision-oriented search intent.

Keep GDPR/data localization discussion minimal

Prevents cannibalization with neighboring articles in the cluster.

The article should continue to own one narrow question:

How does tokenization change card-data exposure and PCI scope?

It should not become the site's complete PCI implementation guide, because that belongs under PCI DSS Compliance for Merchants.

Recommended visual assets

•“Where Does the PAN Go?” architecture diagram

This should be the primary visual.

Architecture A — Merchant handles raw card data

CUSTOMER

↓

MERCHANT CHECKOUT

↓ PAN

MERCHANT SERVER

↓ PAN

PSP

↓

TOKEN CREATED

↓

TOKEN RETURNED

Result: tokenization reduces downstream storage exposure, but merchant systems have already handled PAN.

Architecture B — Provider-hosted card capture

CUSTOMER

↓

PROVIDER-HOSTED PAYMENT FIELD

↓ PAN

PSP / TOKENIZATION ENVIRONMENT

↓

TOKEN

↓

MERCHANT SYSTEMS

Result: merchant systems can avoid directly receiving PAN, subject to the actual integration and PCI scope analysis.

Main annotation:

The earlier PAN leaves the merchant-controlled environment, the greater the potential scope-reduction benefit.

Suggested alt text:

Comparison of payment architectures showing PAN passing through merchant systems versus direct provider tokenization before merchant systems receive a token.

•Tokenization vs encryption

A clean side-by-side visual:

Tokenization

Encryption

Replaces PAN with another value

Transforms PAN cryptographically

Merchant may stop handling PAN downstream

PAN still exists in encrypted form

Token/PAN relationship controlled elsewhere

Original PAN recovered with appropriate key

Can reduce PAN exposure across applications

Protects confidentiality of stored/transmitted PAN

PCI impact depends on architecture

Encryption alone does not automatically remove scope

Bottom line:

Both protect payment data. They change the architecture in different ways.

This directly reinforces one of the conceptual distinctions required by the brief.

•PCI scope before and after tokenization

Before

CHECKOUT

↓

WEB SERVER

↓

PAYMENT SERVICE

↓

PAYMENTS DATABASE

↓

SUBSCRIPTION ENGINE

↓

CRM

↓

SUPPORT

↓

ANALYTICS

PAN may propagate across several systems

After well-designed provider tokenization

CUSTOMER

↓

TOKENIZATION PROVIDER

↓

┌─ PAN / VAULT ENVIRONMENT

│

└─ TOKEN

↓

MERCHANT SYSTEMS

├─ Billing

├─ CRM

├─ Support

└─ Analytics

Headline:

Tokenization reduces scope by reducing where cardholder data flows—not by renaming the data.

This could become the article's strongest shareable visual.

•“Is this token really out of scope?” decision tree

SYSTEM STORES TOKEN

↓

DOES IT ALSO RECEIVE PAN?

↙ ↘

YES NO

↓ ↓

Likely CAN IT RETRIEVE /

relevant DE-TOKENIZE PAN?

to scope ↙ ↘

YES NO

↓ ↓

Relevant CONNECTED TO /

to scope CAN AFFECT CDE?

↙ ↘

YES NO

↓ ↓

May remain Potential

in scope scope reduction

Footer:

Final scope depends on the real architecture and applicable PCI DSS requirements.

This is a particularly good visual because it converts the abstract concept of PCI scope into a technical assessment process.

•Provider token vs network token

Provider token

Network payment token

Issued by

PSP/acquirer/service provider

EMV payment-token ecosystem / Token Service Provider

Typically portable?

Often provider-dependent

Designed for standardized network-token use

PAN substitute?

Yes

Yes

Lifecycle management

Provider-specific

Network-token lifecycle mechanisms

PCI treatment

Depends on token/architecture

Qualifying EMV Payment Tokens receive specific PCI SSC treatment

Merchant question

Can it be reversed/exported/migrated?

How is provisioning and lifecycle managed?

Do not label one “better.” The purpose is architectural clarity.

•Recurring payment token flow

INITIAL PURCHASE

Customer enters card

↓

Provider receives PAN

↓

Token created

↓

Merchant stores token

RENEWAL

Billing system

↓

Stored token

↓

PSP / token service

↓

Payment credential used

↓

Authorization

Main benefit callout:

The billing platform can reference the payment method without storing the PAN itself.

This would be particularly useful for SaaS/subscription readers.

Strong reader-facing checklist

I would add a boxed Tokenization & PCI Scope Review toward the end.

Before selecting a tokenization architecture, ask:

•Where is card data first entered?

•Does PAN ever reach merchant-controlled JavaScript?

•Does PAN reach merchant servers?

•Does PAN appear in logs, queues, monitoring, or backups?

•Who creates the token?

•What type of token is it?

•Can merchant systems retrieve or de-tokenize the PAN?

•Who operates the token vault?

•Which systems can access the vault?

•Which systems can affect the security of the payment page?

•Which systems need the token for recurring payments?

•Can the token be used outside the provider?

•What happens if the merchant switches PSP?

•Which provider services have current PCI validation?

•What PCI validation path does the resulting merchant architecture support?

That is more actionable than a generic “make sure your provider is PCI compliant” recommendation.

A useful “scope test” callout

I would prominently use this four-question framework:

For every system, ask:

Does it store PAN?

Does it process or transmit PAN?

Can it recover or gain access to PAN?

Can it affect the security of the CDE or payment-data capture?

That gives engineering, Security, and Compliance teams a common vocabulary.

Internal-link strategy

The brief gives three priority links: PCI DSS Explained, PCI DSS Compliance for Merchants, and Storing Customer Payment Data.

Suggested anchors:

•what PCI DSS covers and who it applies to → PCI DSS Explained

•how merchants determine and validate PCI scope → PCI DSS Compliance for Merchants

•when merchants should avoid storing raw card credentials → Storing Customer Payment Data

One additional link could be useful if available:

•pre-launch payment security controls → Payment Security Compliance Checklist

I would avoid forcing links to GDPR, residency, or localization unless the paragraph specifically discusses those concepts.

FAQ opportunities

A visible FAQ section could answer:

Does tokenization reduce PCI DSS scope?

It can, because fewer merchant systems may store, process, or transmit PAN. The actual scope depends on the tokenization design and broader environment.

Does tokenization make a merchant PCI compliant?

No. Tokenization can reduce exposure and potentially scope, but it does not itself establish PCI DSS compliance.

Are tokens considered cardholder data?

It depends on the token. Some properly implemented tokens may be outside the CDE, while systems retaining access to PAN, de-tokenization, token vaults, or the CDE may remain in scope.

What is the difference between tokenization and encryption?

Encryption cryptographically transforms card data but retains it as encrypted card data. Tokenization replaces the PAN with a substitute value whose mapping is controlled separately.

Does a hosted payment page reduce PCI scope?

It can materially reduce direct card-data handling, but the exact integration and applicable PCI validation criteria still matter.

Are network tokens different from PSP tokens?

Yes. Network payment tokens use the EMV payment-token framework, whereas PSP/provider tokens may be proprietary to the provider.

Can tokenization help with recurring payments?

Yes. A merchant can retain a token representing a stored payment method rather than storing the underlying PAN in its own billing systems.

Does an API payment integration have more PCI scope than hosted fields?

Potentially. If merchant servers receive PAN before sending it to the PSP, those systems have handled cardholder data even if the PSP subsequently tokenizes it.

Schema recommendation

Use:

•Article

•BreadcrumbList

•FAQPage only when the FAQ is visibly published

There is no need for unusual technical schema. The article's strongest search advantage should come from clear architecture diagrams, precise terminology, and extractable comparisons.

Strongest editorial framework

I would give this article a simple reusable framework:

Capture → Tokenize → Store → Retrieve → Affect

For every merchant system, ask:

•Capture: Does PAN enter it?

•Tokenize: Where does substitution occur?

•Store: What does the system retain?

•Retrieve: Can it regain access to PAN?

•Affect: Can it affect the security of the CDE?

That framework turns “tokenization and PCI scope” from an abstract compliance subject into an architecture review that a Payments, Engineering, Security, or Compliance team can actually perform.