You can’t lose what you don’t keep: reducing PCI scope by not storing card data

PCI DSS applies to every system that stores, processes or transmits cardholder data, and to every system that can affect their security. The larger that footprint, the more controls you have to implement, evidence and pay for. The simplest way to reduce it is also the oldest: do not keep card data you do not need.

No one can steal what you do not have. You also become a less attractive target than the organization next door that does keep it.

What you must never keep

Sensitive authentication data, such as the full contents of the magnetic stripe or chip, the card verification code and PINs, may not be retained after authorization, even if encrypted (PCI DSS requirement 3.3.1, in the PCI DSS v4.0.1 standard). Primary account numbers (PAN) may be stored only when there is a business need, for a defined retention period, and must be rendered unreadable when stored (requirements 3.2.1 and 3.5.1). Look for card numbers in places nobody designed for them: email inboxes, call recordings, spreadsheets, support tickets and log files.

Three ways to shrink your footprint

1. Let a validated provider take the payment

For e-commerce, a hosted payment page or a provider-hosted payment form means card data goes directly to a PCI DSS compliant payment provider. Your website never touches it. This is the basis for the shortest self-assessment questionnaire, SAQ A. Note that eligibility changed in 2025: merchants now confirm their site is not susceptible to attacks from scripts that could affect the payment process (Akamai summary). See which SAQ applies to you.

2. Replace card numbers with tokens

Tokenization swaps the PAN for a surrogate value that is useless to an attacker. The PCI SSC notes that “a properly implemented tokenization solution can reduce or remove the need for a merchant to retain PAN in their environment once the initial transaction has been processed” (PCI SSC Tokenization Guidelines). Recurring billing, refunds and customer profiles can usually run on tokens supplied by your payment provider.

3. Isolate what remains

If some systems must still handle card data, place them in a restricted zone, separated from the rest of the network. The Council’s scoping guidance states that “when properly implemented, network segmentation is one method that can help reduce the number of system components in scope for PCI DSS” (PCI SSC scoping guidance). Segmentation must then be proven by testing. See why scope reduction needs proof.

Traps to avoid

• Outsourcing is not delegating responsibility. You remain responsible for confirming your providers are compliant and for the parts of the flow you still control.
• Your website still matters. Even with a hosted payment page, the page that redirects to or embeds the payment form can be tampered with.
• Phone and mail orders. Card numbers written on paper or typed into a notes field bring systems back into scope.
• Old data. A migration to tokens does not delete the card numbers already sitting in last year’s database export.
• Flat networks. Without segmentation, the whole network is in scope.

Where to start

1. Map every way a card number enters your organization: web, phone, terminal, email, mail.
2. Run a discovery exercise to find stored card data you did not know about.
3. For each channel, ask whether a provider could take the card data instead of you.
4. Delete what you do not need, and tokenize what you must reference later.
5. Segment and test what remains.

Accel PCI helps merchants find the smallest valid scope and complete the right SAQ online. Ubitrak assesses larger environments and validates segmentation. See our PCI DSS overview or contact us.

Sources

• PCI SSC Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation
• PCI SSC Information Supplement: PCI DSS Tokenization Guidelines
• Akamai: PCI DSS v4.0.1, the changes you need to know to qualify for SAQ A
• PCI SSC Document Library (PCI DSS v4.0.1 and SAQs)
• PCI SSC: Just Published: PCI DSS v4.0.1