PCI DSS 4.0 for Online Shops: Compliance Rules 2026

Since 1 April 2025 the requirements originally marked as "future-dated" in PCI DSS 4.x are mandatory in any assessment as well, and the legacy v3.2.1 was retired in March 2024 (PCI SSC). For every German online shop accepting card payments — even through an iframe or redirect — script management, MFA and continuous audit-log review are now baseline duties. At the same time the threat landscape has hardened: 311 billion web attacks were measured worldwide in 2024, up 33 % year over year (Akamai), and in a German e-commerce market worth EUR 83.1 billion annually (bevh) card data is one of the most rewarding targets. This guide explains what has changed, where the typical compliance gaps sit and how we at XICTRON harden shops for PCI DSS 4.0.

Why PCI DSS 4.0 matters for every online shop

PCI DSS applies to every organisation that processes, transmits or stores cardholder data, regardless of size or transaction volume. The standard is maintained by the major card brands and enforced through acquirer contracts. Even a shop that "only" embeds a hosted iframe of a Payment Service Provider remains accountable. The changes introduced in v4.x make sure that the Cardholder Data Environment (CDE) is protected on a technical as well as an organisational level. Ignoring compliance creates exposure to fines and, in the case of a breach, higher liability.

The threat landscape already demands action. The IBM Cost of a Data Breach Report 2026 puts the global average breach cost at USD 4.99 million (IBM). In Germany, with an e-commerce market of EUR 83.1 billion (bevh), card data remains a rewarding target. Bitkom puts the damage from data theft, industrial espionage and sabotage in Germany at EUR 211 to 270.8 billion; 96 % of companies were affected or suspect they were (Bitkom).

• 311 billion web attacks were recorded worldwide in 2024, up 33 % year over year (Akamai State of the Internet 2025)
• More than 230 billion of them targeted commerce organisations (Akamai)
• 150 billion API attacks between January 2023 and December 2024; incidents related to the OWASP API Security Top 10 rose by 32 % (Akamai)
• Non-compliance penalties are set by the acquirer — the amount is defined in the acquirer contract, not in the standard
• In a breach, forensics, card replacement and notification of the affected customers are added on top
• The BSI situation report counts 119 new vulnerabilities per day, around 24 % more than in the preceding period; around 80 % of the reported attacks targeted small and medium-sized companies (BSI)

What changed fundamentally after March 2025

PCI DSS 4.0 was published in March 2022. The predecessor v3.2.1 was officially retired on 31 March 2024 (PCI SSC). Some of the new requirements applied immediately, others were marked as "future-dated" and had to be in place by 31 March 2025 (PCI SSC). Since 1 April 2025 these are binding in any assessment as well. A limited revision to v4.0.1 followed on 11 June 2024, clarifying several points including script management (PCI SSC).

The consequence: many merchants who could rely on a simplified SAQ A in 2023 must in 2026 evidence the full catalogue. Script integrity, MFA, audit logging and penetration testing are especially affected — none of which can be patched together on a short timeline. If you start now, you are already under pressure. For the broader security mindset, see our Zero-Trust guide for online shops.

Magecart and web skimming: the acute threat

Magecart refers to a loose group of actors who inject JavaScript into checkout pages and siphon card data directly from the customer's browser, invisible to the shop backend and traditional firewalls. The attacks rarely target the shop software itself; instead, they piggyback on third-party scripts loaded inside the payment page. Because the data is taken inside the customer's browser, it leaves no trace in server logs or order data; the theft usually surfaces only once card issuers report fraud patterns.

A particularly painful 2024 vulnerability was CosmicSting (CVE-2024-34102): it allowed attackers to read encryption keys out of affected shop systems and inject their own code from there. Anyone who applies security updates late leaves exactly this kind of gap open — skimming code can then run unnoticed for weeks. The countermeasure is unspectacular: schedule binding patch windows and monitor the payment page for unexpected scripts.

Script management under 6.4.3 and 11.6.1

Requirements 6.4.3 and 11.6.1 are the heart of the v4.x changes for shop operators. They demand three things: a complete inventory of every script loaded on payment pages, documented authorisation for each script with a justification of its necessity, and an integrity check through tamper detection at least weekly (PCI SSC/Akamai). In practice this means that every external or indirectly loaded script must be known, documented and monitored.

The scale is routinely underestimated. Next to its own code, a checkout page regularly loads analytics, chat, testing and payment scripts — each of which can gain access to the input fields. So count the script inventory of your own payment page once: the network tab of the developer tools is the starting point for Req. 6.4.3, not an industry average. In e-commerce a substantial share of the JavaScript comes from third parties, and that share is rarely under your own control.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.psp.example 'sha384-4g5z...';
  connect-src 'self' https://api.psp.example;
  frame-src https://checkout.psp.example;
  report-uri /csp-report-endpoint;

<!-- Subresource Integrity for statically included scripts -->
<script
  src="https://js.psp.example/v1/widget.js"
  integrity="sha384-4g5z.../abc123=="
  crossorigin="anonymous"></script>

CSP and Subresource Integrity are just building blocks. You also need server-side rendering where possible, a script inventory tied into change management, and monitoring that logs and alerts on hash deviations. Operators of a platform such as Shopware should couple theme updates and plugin rollouts to a mandatory script audit.

MFA and authentication tightened

Password requirements have been noticeably tightened in v4.x. Requirement 8.3.6 now mandates at least 12 alphanumeric characters (up from 7). Even more important is Requirement 8.4.2: since 31 March 2025, multi-factor authentication is required for every non-console access inside the CDE, not just for administrative accounts (PCI SSC). This affects every shop employee who connects remotely to servers, databases or admin consoles where card data could become visible.

The Verizon DBIR 2025 explains why this matters: use of stolen credentials accounts for 22 % of the analysed breaches as an initial access vector, exploitation of vulnerabilities for 20 % (Verizon). A second factor — ideally a hardware key or a phishing-resistant authenticator — devalues the stolen login. If you still rely on SMS codes, plan a migration to TOTP or FIDO2 schemes soon. In our consulting projects we always run a role audit as part of the exercise: who really needs CDE access, and who can be served through a scoped admin panel?

Vulnerability scans and penetration testing on a quarterly cycle

PCI DSS 4.x requires quarterly external ASV scans conducted by an Approved Scanning Vendor. Every vulnerability with a CVSS score of 4.0 or higher must be remediated and documented with a clean scan within the scan window (PCI SSC). In addition, authenticated internal scans (Req. 11.3.1.2) are required quarterly (PCI SSC). Penetration tests are mandatory annually and after significant changes. New since 31 March 2025: multi-tenant service providers (hosting and cloud) must actively support their customers in external pen-testing — Requirement 11.4.7 (PCI SSC). For shop operators this means the host has to provide staging environments, access paths and a coordination contact so pen-testers can work legally and safely on production. Teams that maintain custom code in the checkout benefit additionally from accompanying custom development that builds security reviews into every release pipeline.

Tokenisation as a scope reducer

The single most effective way to shrink the PCI footprint remains tokenisation: instead of the actual Primary Account Number (PAN), the shop processes and stores only a token issued by the PSP. The fewer systems ever see the PAN, the smaller the scope an assessment has to cover. Network tokens go a step further: they are issued directly by the card network and automatically updated when cards are lost or expire, which reduces the number of failed payments caused by expired cards.

For most German SMEs the path is clear: replace PAN with tokens as early as possible, move the checkout into a hosted iframe or redirect page at the PSP, and keep only tokens inside the shop backend. Shops that integrate wallets and new European A2A methods such as Wero decouple themselves from classic card risks. And express checkout flows naturally benefit from tokenised payment methods.

SAQ A vs. A-EP vs. D — which questionnaire for which shop?

Self-Assessment Questionnaires (SAQs) are the practical compliance vehicle for merchants at levels 2 to 4. Picking the right SAQ determines cost and effort. SAQ A applies to shops that fully outsource the payment process to a PCI compliant provider (iframe or redirect). SAQ A-EP covers shops that never touch PAN but whose servers influence the payment flow (for example through custom checkout logic). SAQ D is the full version for merchants that process or store card data themselves.

Understanding cloud shared responsibility

If you run your shop in the cloud, you share PCI responsibility with whoever operates the platform. Serious providers publish a responsibility matrix stating which controls they cover themselves and which stay with the customer — data, OS patches and firewall configuration are typically on the customer side. Ask for that matrix and walk it through requirement by requirement against your own setup. What matters is actively mapping your own share instead of assuming that an assessed platform covers every control automatically.

If you prefer a German-based host, insist on an explicit PCI responsibility matrix and on evidence for the data centre's certifications. For our shop customers we provide a documented split of responsibilities and logging and patch workflows that follow the PCI baseline — without offering our own QSA status.

Reaching compliance in seven steps

The road to PCI DSS 4.0 can be structured pragmatically. The following sequence has proven itself in our consulting engagements and avoids expensive detours.

1. Define the scope: identify every system, network, script and service provider that touches or influences card data. Produce a diagram with all data flows.
2. Gap analysis: map the current state against the 64 new items in v4.x and produce a prioritised gap list with owners.
3. Reduce the scope: tokenise card data, move checkout into a hosted PSP flow, pull admin zones out of the CDE — the most effective measure before any technical hardening.
4. Build a script inventory: log every line of JavaScript on payment pages, enable CSP and SRI, deploy tamper-detection monitoring (Req. 6.4.3 / 11.6.1).
5. Harden technical controls: MFA 8.4.2 everywhere, password policy 8.3.6 at 12 characters, automated log review 10.4.1.1.
6. Scans and testing: quarterly ASV scans, authenticated internal scans, annual pen-tests — all with documented reports and remediation evidence.
7. Continuous monitoring: retain audit logs for 12 months (3 months immediately retrievable), detect and remediate security control failures according to 10.7.2.

How XICTRON hardens your shop security

We guide shop operators through PCI DSS 4.0 along the full stack — from hosting through scope reduction by tokenisation and clean script management for Shopware and WooCommerce checkouts, to MFA rollouts and automated log review running in our cloud setups. We do not provide QSA certification; instead we deliver the technical and organisational foundation on which your QSA can later assess. The best starting point is a structured gap assessment.