An e-commerce platform stores card numbers to support repeat purchases. How do you reduce PCI scope?

Stop the card number reaching your systems at all

The strongest reduction is not storing cards more safely; it is never receiving them.

A hosted field or an iframe served by the payment provider captures the card in the browser, sending it directly to the provider. Your systems receive a token. The application, the database and the network they sit on drop out of scope for that flow entirely.

Repeat purchases work on the token: the provider holds the card and you hold a reference that is useless to anyone else.

Then segment whatever remains

Any system that still touches cardholder data — or can connect to one that does — must be isolated so that scope does not spread. Segmentation has to be demonstrable, and penetration testing of the boundary is what demonstrates it.

Without it, a flat network means the whole estate is connected and therefore in scope, which is how an organisation assesses hundreds of systems for a handful of transactions.

Find the routes nobody drew

Card data arrives through paths that are not on the architecture diagram: typed into a support ticket, spoken on a recorded telephone line, pasted into a chat transcript, or emailed by a customer.

Each brings the receiving system into scope. The controls are process and detection — pause-and-resume on call recording, detection patterns in the ticketing system, and staff guidance — and they need to be in the assessment rather than discovered by the assessor.

The order of work

Tokenisation first, because it removes the most scope for the least ongoing cost. Segmentation second. Detection of unintended routes third.

What to tell the business

Scope is the cost driver. Every system removed from it is removed from annual assessment, quarterly scanning and the full control set — so this is an ongoing saving rather than a one-off project, and it usually pays for itself within a cycle.