An online retailer collects card numbers in a form on its own checkout page and posts them to a payment provider. 240 engineers can deploy the checkout service and the annual PCI DSS assessment is consuming three months of engineering time. Which single change most reduces the assessed scope?

The deciding property

Scope follows the data. A system is in the cardholder data environment if it stores, processes or transmits the primary account number, or can affect the security of a system that does. Every control you add to an in-scope system leaves it in scope; only removing the PAN from the system removes the system.

With hosted fields or a full redirect, the card number goes from the customer's browser to the provider's domain. Your servers receive a token and a status. The checkout service, its hosts, its logs, its backups and the 240 engineers who can deploy it stop being assessed systems. That is why this is the biggest single move available: it takes the largest population out, not the highest risk.

Why the other options fail

Encrypting the stored PAN. You still store, process and transmit it, so you remain fully in scope and you have added key management requirements — key custodians, rotation, split knowledge — on top. This is the right answer only when you must hold the PAN, for example if you are the processor.

Network segmentation. Genuinely useful and often the second move: it stops the rest of the estate being dragged in. But the checkout service itself still handles the PAN, so the CDE shrinks to that segment rather than disappearing. You have reduced how much is in scope, not whether the hard part is.

Network tokens after the first payment. This removes stored card data and is the right pattern for repeat payments — Razorpay, an RBI-authorised payment aggregator, publishes PCI DSS Level 1 compliance and offers card-on-file network tokenisation to Indian merchants, who have been unable to store raw card data themselves since the RBI rules took effect in October 2022. The gap is that the first transaction still crosses your servers, which keeps the checkout path in scope. Combine it with hosted fields rather than substituting it for them.

What stays in scope anyway

Outsourcing card entry does not make the page that loads it someone else's problem. PCI DSS v4 added two requirements that became mandatory on 31 March 2025 and land squarely on the merchant: 6.4.3, an inventory and authorisation for every script running on the payment page, and 11.6.1, a mechanism that detects unauthorised changes to the payment page and its security-impacting HTTP headers as received by the browser, checked at least every seven days. For fully outsourced merchants the Council reworked the SAQ A eligibility criteria around this point rather than dropping it. A skimming script injected into your page steals cards regardless of whose iframe renders the field.

You also inherit the provider's assurance: collect their attestation of compliance annually, and record which of their requirements you are relying on.

When this is the wrong answer

When the PAN is your product. A processor, an acquirer or a fraud engine scoring raw card data cannot outsource the thing it does. Scope reduction also moves risk rather than removing it — the provider now holds your customers' cards, and their outage is your checkout outage with no fallback. If card entry is a differentiating part of the experience, or if you need the PAN for routing across acquirers, accept the scope and invest in segmentation instead.