Retail and eCommerce cybersecurity: PCI DSS, NIS2 and fraud prevention 2026

Retail and eCommerce are systematic targets for payment fraud, Magecart skimmers, account takeover campaigns and large scale card data breaches. High transaction volume, payment instrument data, enriched PII profiles and seasonal peaks make physical stores, pure online retailers and digital marketplaces a priority target. The mandatory reference framework for any organisation that processes, transmits or stores cardholder data is PCI DSS v4.0.1, applicable in its current version since 31 March 2025. NIS2 broadens the European regulatory perimeter by including digital marketplaces and online platforms as important entities, adding obligations that coexist with PCI discipline.

Key takeaways

• PCI DSS v4.0.1 is mandatory as of 31 March 2025; the thirteen new obligations flagged as future-dated requirements in v4.0 stopped being best practice and are now fully auditable.
• Digital marketplaces and online platform service providers fall within Annex II of NIS2 as important entities when they exceed the medium enterprise thresholds.
• Magecart remains the dominant threat in eCommerce: the JavaScript web skimmer is injected through a third-party provider, survives CMS patches and is only detected through client-side script monitoring.
• Account takeover, gift card fraud and return fraud drive direct margin loss, are hard to separate from legitimate traffic and require retail-specific fraud scoring.
• PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 mandate inventorying, authorising and monitoring every script executed on the payment page, which closes the main Magecart vector when implemented rigorously.

Why retail is a priority target

Transaction volume is an order of magnitude higher than that of most sectors, which dilutes detection of individual fraudulent transactions and lets attackers operate beneath legitimate noise. Antifraud scoring models work with false positive rates limited by their impact on conversion.

Data nature combines card data with personal information enriched by purchase history, preferences and behaviour. The full package is monetised on underground markets above the price of an isolated card because it enables social engineering and targeted impersonation against loyalty programmes.

Seasonal peaks are the third structural factor. Black Friday, Cyber Monday and sales concentrate a disproportionate share of annual revenue in a few weeks. Operations teams prioritise availability and attackers know it: documented Magecart campaigns have activated in sync with Black Friday to maximise capture before detection.

Technological fragmentation is endemic. A typical retail brand combines physical POS with legacy models, mobile app, SaaS eCommerce, owned marketplace, external integrations, loyalty programme and CRM. Each component introduces attack surface and PCI discipline must cover the full card data flow across that architecture.

PCI DSS v4.0.1: scope and deadlines

PCI DSS is a private standard from the PCI Security Standards Council, founded by the five international card networks. Compliance is contractually enforceable by the brands through the acquirer. Any merchant or service provider that stores, processes or transmits cardholder data is subject to the standard, with scope modulated by the entity level and the corresponding validation method.

Version 4.0 was published in March 2022 and 4.0.1 in June 2024 with clarifications and corrections that did not introduce substantive new requirements. Version 3.2.1 ceased to be valid on 31 March 2024. Thirteen new requirements flagged as future-dated had a grace period until 31 March 2025, and since that date they are fully auditable. Organisations that did not anticipate the transition find themselves in 2026 with consolidated findings in their annual reports.

The key concept is the Cardholder Data Environment (CDE), made up of systems that process, store or transmit card data, together with connected systems that may affect their security. The sensible strategy is to minimise the CDE through tokenisation, externalising capture to a certified processor and network segmentation. An iframe embedded directly from the processor can lift the merchant server out of the processing CDE.

Merchant levels are determined by annual transaction volume with each brand. Level 1 (more than six million Visa or Mastercard transactions annually) requires a RoC issued by an external QSA. Levels 2 to 4 allow validation through SAQ, with variants depending on architecture: SAQ A for fully outsourced commerce, SAQ A-EP for eCommerce that controls the page but does not capture data directly, SAQ D for architectures with own capture. The wrong choice of SAQ is a frequent finding.

NIS2, GDPR and Spanish eCommerce Law

NIS2 classifies online marketplace providers, search engines and social network platforms that exceed the medium enterprise thresholds as important entities, listed in Annex II of the directive. The Spanish transposition is Real Decreto-ley 7/2025 (BOE of 17 April 2025), pending parliamentary ratification scheduled for 2026. Obligations cover risk management, notification of significant incidents and registration with INCIBE-CERT as sectoral authority.

The GDPR and LOPDGDD apply fully to the processing of personal customer data. Granular consent, minimisation, legitimate basis for secondary uses and management of data subject rights are habitual areas of AEPD inspection. A card data breach is also a personal data breach, which triggers AEPD notification within 72 hours and communication to affected individuals when the risk is high.

Spanish Law 34/2002 (LSSI-CE) regulates provider identification, pre-contractual information, electronic contracting and commercial communications. Overall, a medium sized Spanish eCommerce operates under PCI before the acquirer, NIS2 before INCIBE-CERT if it exceeds the thresholds, GDPR before AEPD and LSSI-CE as a consumer framework. Integrated management requires a single incident management process that satisfies all notification deadlines.

Top 6 threats in retail and eCommerce

1. Magecart web skimmers. Injection of malicious JavaScript into the payment page to capture card data before submission to the processor. Dominant vector in eCommerce and primary cause of large scale breaches in recent years.

2. Account takeover (ATO). Hijacking of legitimate accounts using reused, stolen or brute-forced credentials. The attacker uses the account for purchases with saved payment methods, draining gift card balances or redeeming loyalty points.

3. Gift card fraud. Fraudulent generation, testing or redemption of gift cards. Includes automated balance checking, mass purchases with stolen card and resale, and abuse of returns without receipt that refund value in gift card form.

4. Return fraud. Common variants: returning a product different from the one purchased (wardrobing, sticker swap, brick-in-the-box), falsified receipt, returning a product bought with a stolen card for a clean refund.

5. Supply chain JavaScript. Compromise of a provider of JS services integrated into the page (analytics, chat, recommendation, A/B testing, tag manager). Compromising the provider is enough for the injection to reach every page that loads that script.

6. POS malware. Malicious software on POS terminals or the management server that captures magnetic stripe or chip data before encryption. Historically responsible for major retail breaches, it remains active in chains with heterogeneous POS fleets.

Magecart deep dive

Magecart is an umbrella covering more than a dozen actors with shared TTPs. The canonical pattern is the injection of JavaScript that executes in the legitimate customer browser during payment, captures the form data and exfiltrates it to an attacker-controlled domain before submission to the processor. The victim completes the purchase normally because the legitimate transaction executes, which delays detection.

Injection vectors are three: direct compromise of the merchant eCommerce through a CMS vulnerability (legacy Magento, Adobe Commerce, WordPress WooCommerce plugins); compromise of a third-party script provider; or compromise of the script delivery chain (CDN, public S3 bucket, npm library with compromised dependency).

Obfuscation techniques have evolved. The script is loaded conditionally only on payment pages to avoid generic scans, uses variable names that mimic legitimate analytics (gtm, ga, _paq), hides payload in modified favicons, CSS comments or image attributes, and exfiltration uses domains similar to the merchant legitimate CDN or genuine cloud services.

Effective detection combines three layers: SRI on external scripts, which invalidates execution if content changes against the declared hash; strict CSP that blocks unauthorised scripts with report-uri; and active client-side monitoring through a specialised tool that runs a headless browser against the payment page and compares the inventory of scripts, domains and network behaviour. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 formalise these layers as auditable.

Priority technical controls

The defensive architecture of a robust eCommerce rests on a core of controls whose correct implementation closes the dominant attack vectors.

Strict CSP. Policy with default-src 'self', explicit listing of allowed domains per directive, prohibition of unsafe-inline and unsafe-eval, script-src with nonces or hashes per essential inline block, and active report-uri. The transition requires a monitoring phase using Content-Security-Policy-Report-Only to inventory legitimate violations before blocking.

SRI on external scripts. integrity attribute with SHA-384 hash on every critical <script src> or <link>. Not viable for scripts the provider updates frequently; in those cases mitigation combines strict CSP, own hosting with pinned build, or removal of the script.

CDE segmentation. Network separation between systems that process card data and the rest of the environment, validated through segmentation testing at least annually under requirement 11.4.5. Reducing CDE scope reduces sustained compliance cost.

Web frontend WAF. Deployment of a WAF (Web Application Firewall) in blocking mode in front of the eCommerce with OWASP Top 10 rules, credential stuffing protection, rate limiting per sensitive endpoint and bot blocking through progressive challenge. Requirement 6.4.2 mandates a WAF or equivalent for every public-facing web application.

Specific fraud scoring. Engine that combines device signals, geolocation, order velocity per card or account, billing-shipping address mismatch, suspicious cart pattern and IP reputation. Calibration requires legitimate and fraudulent history to tune thresholds without penalising conversion.

Tokenisation and P2PE. Tokenisation replaces the PAN with a token reversible only by the processor and removes the PAN from the merchant environment. PCI SSC validated P2PE encrypts data at the hardware terminal and decrypts it only in the provider HSM, exempts the merchant from most physical channel requirements and radically simplifies compliance for retailers with extensive physical presence.

POS security and physical channel

The POS fleet introduces specific challenges that controls focused on eCommerce do not cover. Terminal hardening covers removal of unnecessary services, disabling of non-essential USB ports, robust administrative passwords, regular firmware patching and boot image validation. Brand terminals with PCI PTS certification offer a more secure baseline than generic readers.

POS-specific EDR operates with limited resources, tolerates environments without permanent connectivity and detects POS malware behaviours (access to payment process memory, atypical outbound connections, file writes to sensitive locations). Network segmentation isolates POS terminals from the corporate network and customer WiFi through separate VLANs for payment terminals, back office and public WiFi, with firewall and active logging between them.

Physical antitampering controls cover periodic visual inspection to detect overlay skimmers, serial number registration with routine reconciliation, terminal sealing with labels that detect opening, and store staff training. Documented inspections are auditable evidence under requirement 9.5.1.

PCI DSS retail audit

The RoC is issued by an external QSA accredited by PCI SSC and covers each of the more than three hundred sub-requirements with documented evidence, interviews, process observation and technical testing. It is the level required of Level 1 merchants and service providers.

The SAQ is a self-assessment signed by the entity and validated by the acquirer. The applicable variant depends on architecture: SAQ A (fully outsourced), SAQ A-EP (eCommerce that controls the page but does not capture PAN), SAQ B-IP (terminals with IP connection), SAQ D (any scenario not covered). Wrong SAQ choice is one of the most common findings and produces technical non-compliance the merchant is unaware of.

Annual pentesting of the CDE and after significant changes is mandatory under requirement 11.4. It covers external network, internal network and web application with focus on the card flow. A professional web audit evaluates the full cycle: registration, login, catalogue, cart, checkout, account management and returns, including payment screens, processor webhooks and mobile APIs. Retail-specific social engineering simulates gift card scam by call to customer service, vendor impersonation to modify a bank account, and manipulation of a store employee to process a return without receipt.

Frequently asked questions

Is a retail SME with eCommerce required to comply with PCI DSS?

Yes, regardless of size. PCI DSS applies to any merchant that processes, stores or transmits card data, with no minimum threshold. What varies with volume is the validation method: an SME with eCommerce fully outsourced can validate through SAQ A, but the substantive obligations remain enforceable. The difference compared to a Level 1 merchant lies in the depth of evidence, not in the existence of the obligation.

Is a Shopify or other SaaS store automatically PCI compliant?

No. The SaaS provider covers its platform through its own certification as a PCI service provider, but the merchant retains residual obligations: correct checkout configuration so the processor iframe is the only capture path, management of third-party scripts added to the theme, access control to the admin panel, incident management and training. Requirement 12.8 mandates a documented responsibility matrix with each relevant PCI provider.

How do I detect a Magecart skimmer on my site?

Effective detection combines prevention and monitoring. In prevention: strict CSP with active report-uri, SRI on pinnable external scripts, updated inventory of all payment page scripts and explicit authorisation under requirement 6.4.3. In monitoring: a tool that runs a headless browser against the payment page at regular intervals and alerts on changes in inventory, contacted domains or exfiltrations. Manual source code review is not enough because modern skimmers load conditionally.

Does a digital marketplace fall under NIS2?

Yes, when it exceeds the medium enterprise thresholds (more than fifty employees or more than ten million euros in turnover or balance sheet). Online marketplace providers appear explicitly in Annex II as important entities, with obligations on risk management, significant incident notification and registration with INCIBE-CERT. A NIS2 audit (compliance guide) anticipates the situation.

How much does PCI DSS compliance cost in a typical eCommerce?

Cost varies with architecture and merchant level. A SaaS eCommerce validated through SAQ A can maintain compliance at moderate annual cost: WAF, Magecart monitoring tool, quarterly ASV scanning and QSA support for SAQ review. A Level 1 merchant with RoC and POS fleet multiplies the cost through full QSA audit, annual pentesting, P2PE or tokenisation and a dedicated team. The most cost-efficient strategy is to minimise the CDE: smaller auditable environment, lower sustained cost.

How do I prepare Black Friday from a security perspective?

At least three months ahead: change freeze on the eCommerce during the two weeks before the peak, synthetic load exercise, vulnerability scan of the full CDE, review of script inventory on the payment page, verification of CSP and SRI, adjustment of WAF rate limiting thresholds, validation of the incident response runbook and verification of notification channels to processor and acquirer. During the peak, active script monitoring, hourly fraud rate tracking and 24x7 on-call are the dynamic defences that prevent a Magecart incident from persisting.

Related resources

• What is a CVE: vulnerabilities explained
• Complete cybersecurity audit business guide
• NIS2 Spain compliance 2026
• Web application penetration testing
• What is a WAF (Web Application Firewall)
• Ransomware in Spain 2026: landscape and defence

Retail audit with Secra

At Secra we support retailers, eCommerce and marketplaces in meeting PCI DSS v4.0.1, NIS2 and the rest of the regulatory framework applicable to the sector. We run full payment flow pentesting with focus on checkout, mobile APIs and processor webhooks, we evaluate CSP and SRI configuration of the payment page to close the Magecart vector under requirements 6.4.3 and 11.6.1, we review the CDE architecture with a minimisation strategy through tokenisation and P2PE, and we build the remediation roadmap prioritised by regulatory impact.

If you need a diagnostic ahead of your next PCI audit or want to anticipate the NIS2 adequacy of your marketplace, contact us.