How to Reduce Your PCI DSS Scope

In PCI, a system is in scope until you can demonstrate it is not. The Council's glossary defines the cardholder data environment as "the system components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data, and system components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD," and the Council's September 2024 information supplement on scoping and segmentation for modern network architectures exists to give organisations "background knowledge, actionable guidance, and practical examples to assist in defining PCI DSS scope and applying segmentation practices in modern network architectures." Read the glossary definition twice and the second clause does the damage: connectivity counts, not just data. Scope reduction is therefore not a cost-saving trick bolted on at the end. It is the only PCI decision that changes every other number.

Four levers do the work, and they are not equal. This article ranks them by how much they actually remove, names what each one leaves behind, and ends with the back-office paths that quietly undo all four.

Key takeaways

• Systems are in scope by default. The burden is on you to demonstrate isolation, not on an assessor to prove connection.
• Scope is wider than the cardholder data environment. Requirement 12.5.2 covers components in the CDE, connected to the CDE, or able to impact its security, and the third category is the one teams forget.
• The strongest lever is not holding card data at all: a fully outsourced payment page removes the data rather than protecting it.
• Tokenization removes downstream systems from scope, but the token vault and anything that can de-tokenize stay in, and the Council says so.
• P2PE is a card-present transport control; tokenization is a storage control. Strong architectures use both, for different reasons.
• Segmentation is the lever you apply to whatever is left, and it is the one that requires ongoing proof rather than a one-time build.

Lever one: do not hold the data

The cheapest cardholder data to protect is the kind you never receive.

For e-commerce, that means the payment page belongs to the processor, not to you. A full redirect sends the customer off your site before any card number is typed. A processor-served embedded form keeps them on your page, which is lighter to build and heavier to validate, and since 2025 carries an eligibility criterion of its own; our article on the SAQ A eligibility change covers what an embedded checkout now has to confirm.

For card-present, it means terminals that your systems never talk to in the clear, which is lever three.

This is the lever with the largest effect and the shortest window in which to pull it. Choosing a checkout integration is a decision an engineer makes in an afternoon, usually years before anyone in finance says the word PCI, and reversing it later means a migration, a testing cycle and a customer-facing change. If you are choosing today and have no strong preference, choose the integration that keeps your code off the payment path. The build difference is a day. The annual difference is a different validation type. Which one you land in is the subject of our PCI SAQ decision guide, and it is not a question this article tries to answer.

What it does not remove: anything else in your business that touches a card number, which is the section on the back office below.

Lever two: tokenization, and the part the vendors skip

Tokenization replaces the primary account number with a surrogate value, which is the Council's own term for it in its tokenization guidelines. The security of the arrangement rests on the infeasibility of recovering the original account number from the surrogate alone.

Done properly, systems that only ever hold tokens are outside the cardholder data environment, because a token is not cardholder data. That is a large removal for a typical SaaS or commerce business: the CRM, the analytics warehouse, the order management system, the support tooling, the reporting stack. Those are often the majority of systems that touched card references, and the majority of the assessment effort.

Here is the part that vendor content tends to compress. The tokenization system itself is in scope and must be segmented, and the conditions for treating token-only systems as out of scope include having no access to de-tokenization, to the keys, or to the vault. So tokenization does not delete your cardholder data environment. It concentrates it into a small, hardened, well-defined piece of infrastructure, and moves everything else out. That concentration is the win, and it is worth being precise about, because a team that believes tokenization made them scopeless will design the vault carelessly.

Ask any tokenization vendor two questions: what exactly is in scope after implementation, and who can de-tokenize. A vendor that answers "nothing" to the first is selling you a misunderstanding.

Lever three: P2PE for card-present

Point-to-point encryption is a transport control. Card data is encrypted at the point of capture in the terminal and stays encrypted until it reaches a decryption environment the merchant does not operate. The systems the encrypted data passes through never hold anything usable.

Two practical notes. First, the meaningful version is a solution validated and listed by the Council, because the scope treatment follows from the validation, not from the marketing use of the phrase "end to end encryption". Second, P2PE and tokenization solve different halves of the problem: P2PE keeps usable card data out of your systems in transit, tokenization keeps it out at rest. A card-present merchant with a large estate typically wants both, capturing through a listed P2PE solution and tokenizing what has to persist afterwards.

If you have no physical terminals, this lever is not available to you and the section is safely skipped.

Lever four: segment what remains

Everything above removes data. Segmentation removes systems that never held data but could reach the ones that do, which is the clause in the glossary definition that turns a small assessment into a large one.

The principle in the Council's scoping guidance is that a properly segmented, out-of-scope system component could not affect the security of the cardholder data environment even if an attacker obtained administrative access on it. That is the bar, and it is a strong one. It is also why segmentation is the only lever on this list that requires continuous proof rather than a one-time build: firewall rules drift, a peering connection gets added for a legitimate reason, a shared identity provider or a shared jump host quietly reconnects two environments that were separated on the diagram. Where your validation includes segmentation testing, that is what the testing exists to catch, and it belongs in the same conversation as your other penetration testing scope rather than as an afterthought.

A modern wrinkle worth naming: in cloud and container estates the segment boundary is frequently an identity boundary rather than a network boundary. A role that can assume its way into the cardholder data environment is connectivity, whatever the VPC diagram says.

The paths that quietly undo all four

This is where most scope reduction projects actually fail, and none of it is architecture.

Phone payments taken by a support agent. Call recordings that captured the numbers read aloud. A finance spreadsheet of card details kept for chargebacks. A customer who emailed a photo of their card into a shared inbox, which is now in the mail archive and the backup of the mail archive. A screen-sharing tool used during a support session. A test environment seeded with a copy of production.

Every one of those puts cardholder data on systems that were never in the diagram, and each one individually can reinstate the scope that four expensive levers just removed. The remedy is not technical. It is drawing the flow from how the business actually behaves rather than from how the architecture was designed, and then closing the paths by policy and tooling: a pause-and-resume arrangement on call recording, a hard rule against card numbers in chat and email with a filter that enforces it, and a documented alternative for the finance team so they stop needing the spreadsheet.

When scope reduction is not worth doing

The honest caveat, and it cuts against our own interest twice.

If your environment is already tiny and your validation is already the lightest available, there is nothing left to reduce and a scope project is a solution looking for a problem. Read your questionnaire, close what it surfaces, and spend the money on something that improves your security rather than your paperwork.

If you are three weeks from a booked assessment, do not start re-architecting. A half-migrated tokenization project is worse at assessment time than a clearly documented environment you have not changed, because the assessor now has two states to examine and you have evidence for neither. Finish this cycle, then do the work with a year of runway.

And if the reason you want a smaller scope is that the assessment quote shocked you, read what PCI DSS compliance actually costs first. The published ranges disagree with each other by more than 2x, and a second quote may cost you nothing.

Where Top Floor fits

Scope is the part of PCI where an adviser with no assessment to sell is worth the most, because we have no interest in the environment being large. Under our PCI DSS practice the work is drawing the real data flow, arguing the boundary down, designing the tokenization or segmentation change, and producing the evidence that the boundary holds. Where PCI runs alongside SOC 2, ISO 27001 or HIPAA, Compliance as a Service treats the segmentation and access work as one control set rather than four. We are not a Qualified Security Assessor and cannot validate the result; that independence is the point.

How to decide this week

Draw the card data flow on one page from the business inwards, not from the architecture outwards. Interview support, finance and sales, not just engineering. Mark every path, including the embarrassing ones.

Circle every system on that drawing that holds a real card number, and every system that can reach one without restriction. That circle is your cardholder data environment today.

Then draw a second circle around it, because your scope is wider than your cardholder data environment. Requirement 12.5.2 asks you to identify all system components "in the CDE, connected to the CDE, or that could impact security of the CDE", and it is the third category that gets left off the drawing. Those are the systems that hold no card data and have no unrestricted path to any, but whose compromise would undermine the controls protecting the ones that do: the shared identity provider, the shared jump host, the logging and monitoring stack, the hypervisor or orchestration layer underneath, the administrator's workstation. Add them. The second circle is what you will be assessed on.

Then ask one question per circled system: could this hold a token instead, sit behind a validated encryption solution, or be separated so that administrative access on it could not affect the rest. The systems where the answer is yes are your project, in that order. The ones where the answer is no are the environment you are going to be assessed on.

Frequently asked questions

What does reducing PCI DSS scope actually mean?

It means reducing the set of system components, people and processes that fall inside the cardholder data environment. The Council defines that environment as the components that store, process or transmit cardholder data, plus components that do not but have unrestricted connectivity to those that do. Scope reduction therefore has two halves: removing the data from systems that do not need it, and removing unrestricted connectivity from systems that never held it. Anything left outside the boundary does not need to be assessed, scanned, hardened or evidenced.

Does tokenization remove us from PCI DSS scope entirely?

No. Systems that only handle tokens can be treated as out of scope, because a token is not cardholder data, but the tokenization system itself is in scope and must be segmented, and the conditions for excluding token-only systems include having no access to de-tokenization, to the keys, or to the vault. Tokenization concentrates your cardholder data environment into a small, hardened component rather than eliminating it. Ask any vendor precisely what remains in scope after implementation and who is able to de-tokenize.

What is the difference between P2PE and tokenization?

P2PE is a transport control and tokenization is a storage control. Point-to-point encryption encrypts card data at the point of capture in the terminal and keeps it encrypted until it reaches a decryption environment you do not operate, so the systems in between never hold usable data. Tokenization replaces the account number with a surrogate value so downstream systems never store the original. Card-present merchants commonly use both: P2PE for the capture path and tokenization for whatever must persist afterwards.

How do we prove a system is out of scope?

By demonstrating isolation, not by asserting it. The standard set by the Council's scoping guidance is that a properly segmented out-of-scope component could not affect the security of the cardholder data environment even if an attacker gained administrative access on it. In practice that means documented network and identity boundaries, evidence that the boundaries are enforced rather than intended, and, where your validation type includes it, testing that attempts to cross them. Segmentation is the one lever that has to be re-proved continuously, because connectivity drifts back.