Retail and e-commerce compliance: payment scope, skimming and the peak-season freeze

Retail has an unusual compliance profile: a single dominant standard, a threat that targets the checkout page specifically, and an operating calendar that forbids change during the months attackers most exploit. Programmes that succeed here are built around those three facts rather than around a generic control framework.

Payment data defines the scope

PCI DSS applies to anyone storing, processing or transmitting cardholder data, and the effort is driven almost entirely by how much of your estate touches it. The strategic decision is therefore scope reduction rather than control implementation:

• Do not store card data. Tokenisation replaces the card number with a token useless to an attacker, and removes the largest category of obligation outright.
• Point-to-point encryption at the terminal so in-store systems never see readable card data, taking the store network largely out of scope.
• Hosted or embedded payment fields online, so card details go directly to the payment provider rather than through your server.
• Segment whatever remains in scope so it does not extend to the whole corporate network.

Validation effort scales with transaction volume and channel, so establish your merchant level and the correct validation route before designing anything - the difference between a self-assessment questionnaire and a full on-site assessment is substantial, and the right SAQ type depends on exactly how payments are captured.

Digital skimming: the threat aimed at you

Client-side attacks - variously called Magecart, formjacking or digital skimming - compromise a script running on your checkout page and copy card details as customers type them. The stolen data never touches your servers, so server-side controls and log review do not detect it. Breaches have run for months.

The compromise usually enters through a third party: an analytics tag, a chat widget, an A/B testing tool, a marketing pixel, or a JavaScript dependency. Any of these can be modified upstream and your page loads the change automatically.

PCI DSS v4 responded with explicit requirements around managing and monitoring scripts on payment pages. Treat them as a security control set rather than a marketing convenience: inventory every script, justify each one, and detect unauthorised change.

What works: a strict Content Security Policy on payment pages, subresource integrity where feasible, an inventory of every third-party script with a named owner, monitoring for unauthorised changes, and moving payment capture into an iframe hosted by the provider so your page scripts cannot reach the fields at all.

The data beyond payments

Card data attracts the standard; loyalty and marketing data attracts the regulator. Retailers typically hold purchase history, preferences, location data from apps, and increasingly in-store analytics - a rich behavioural profile under privacy law even without a card number.

The recurring failures: consent for marketing collected once and treated as permanent, loyalty programmes with no retention limit, third-party data sharing that customers were never clearly told about, and personalisation built on inferences the customer would find intrusive if described plainly. Cookie and tracking compliance on the storefront is also enforced far more actively than most other privacy obligations, precisely because it is visible from outside.

Operational realities others do not face

• The peak-season change freeze. Trading periods forbid changes for weeks at exactly the time attack volume peaks. Define an emergency security exception path before the freeze, with pre-agreed authority to patch a critical internet-facing vulnerability - otherwise the decision gets made under pressure by whoever is available.
• Store estates. Hundreds of sites with minimal local IT, shared terminals, high staff turnover and physical access by cleaners and contractors. Controls must survive that environment, which rules out anything depending on local diligence.
• Franchise and concession models. Your brand carries the reputational damage while another legal entity operates the systems. Contractual security requirements and evidence of compliance are the only lever - and franchisees rarely have security staff, so requirements must be specific and checkable.
• Seasonal and temporary staff receiving system access at volume, then leaving. Joiner and leaver processes designed for permanent staff break at that scale.
• Point-of-sale estates that are long-lived, sometimes unsupported, and expensive to replace - a standing exception unless compensated by segmentation.

Where to start

Confirm merchant level and validation route; map every place card data flows; reduce scope through tokenisation, P2PE and hosted fields; inventory and control payment-page scripts; establish the freeze-period exception path; then extend to loyalty data and privacy. The first three usually cut the programme's cost more than any control investment.

Key takeaways

• Scope reduction - tokenisation, P2PE, hosted fields - is worth more than any control you add.
• Digital skimming bypasses server-side controls entirely; inventory and monitor payment-page scripts.
• Loyalty and marketing data is where privacy regulators actually look.
• Agree the freeze-period security exception path in advance.