Seit dem 1. April 2025 sind auch die zunächst als "future-dated" markierten Anforderungen von PCI DSS 4.x in jedem Assessment verbindlich, und der alte Standard v3.2.1 ist seit März 2024 zurückgezogen (PCI SSC). Für jeden deutschen Online-Shop, der Kreditkartenzahlungen entgegennimmt — auch über iframe oder Redirect —, bedeutet das: Skript-Management, MFA und kontinuierliche Audit-Log-Reviews gehören jetzt zum Pflichtprogramm. Gleichzeitig hat sich die Bedrohungslage verschärft. Weltweit wurden 2024 311 Mrd. Web-Angriffe gemessen, ein Plus von 33 % gegenüber dem Vorjahr (Akamai), und im deutschen E-Commerce-Markt mit einem Jahresvolumen von 83,1 Mrd. EUR (bevh) sind Kartendaten eines der lohnendsten Ziele. Dieser Leitfaden erklärt, was sich ändert, wo die typischen Compliance-Lücken liegen und wie wir bei XICTRON Shops auf PCI DSS 4.0 ausrichten.
Warum PCI DSS 4.0 für jeden Online-Shop relevant ist
PCI DSS gilt für jede Organisation, die Kreditkartendaten verarbeitet, übermittelt oder speichert — unabhängig von Größe oder Transaktionsvolumen. Der Standard wurde von den großen Kartennetzwerken entwickelt und wird über die Acquirer-Verträge durchgesetzt. Auch wer vermeintlich "nur" ein iframe-Checkout-Formular eines Payment Service Providers einbindet, bleibt in der Verantwortung. Die Neuerungen in Version 4.x stellen sicher, dass die Karteninhaberdaten-Umgebung (CDE) nicht nur technisch, sondern auch organisatorisch geschützt ist. Wer Compliance ignoriert, riskiert Strafen und — im Schadenfall — höhere Haftung.
Die Bedrohungslage zwingt ohnehin zum Handeln. Der IBM Cost of a Data Breach Report 2026 beziffert die durchschnittlichen Kosten einer Datenpanne weltweit auf 4,99 Mio. USD (IBM). Im deutschen E-Commerce-Markt mit 83,1 Mrd. EUR Jahresvolumen (bevh) bleiben Kartendaten ein lohnendes Ziel. Bitkom beziffert den Schaden durch Datendiebstahl, Industriespionage und Sabotage in Deutschland auf 211 bis 270,8 Mrd. EUR; 96 % der Unternehmen waren davon betroffen oder vermuten es (Bitkom).
- 311 Mrd. Web-Attacks wurden 2024 weltweit gemessen, ein Plus von 33 % gegenüber dem Vorjahr (Akamai State of the Internet 2025)
- über 230 Mrd. dieser Angriffe trafen Commerce-Organisationen (Akamai)
- 150 Mrd. API-Angriffe zwischen Januar 2023 und Dezember 2024; Vorfälle rund um die OWASP API Security Top 10 legten um 32 % zu (Akamai)
- Vertragsstrafen bei Non-Compliance setzt der Acquirer fest — ihre Höhe steht im Acquirer-Vertrag, nicht im Standard
- Im Schadenfall kommen Forensik, Kartenersatz und die Benachrichtigung der Betroffenen hinzu
- Der BSI-Lagebericht zählt täglich 119 neue Schwachstellen, rund 24 % mehr als im Zeitraum davor; rund 80 % der angezeigten Angriffe richteten sich gegen kleine und mittlere Unternehmen (BSI)
Was sich seit März 2025 grundlegend geändert hat
PCI DSS 4.0 wurde im März 2022 veröffentlicht. Die Vorgängerversion v3.2.1 wurde am 31. März 2024 offiziell zurückgezogen (PCI SSC). Ein Teil der neuen Anforderungen galt sofort, ein weiterer war als "future-dated" markiert und musste bis zum 31. März 2025 umgesetzt sein (PCI SSC). Seit dem 1. April 2025 sind auch diese in jedem Assessment bindend. Eine "Limited Revision" zu v4.0.1 folgte am 11. Juni 2024 und schuf unter anderem Klarstellungen zum Skript-Management (PCI SSC).
Die Folge: Viele Shop-Betreiber, die 2023 noch mit einem vereinfachten SAQ A durchkamen, müssen 2026 den kompletten Anforderungskatalog nachweisen. Besonders betroffen sind die Bereiche Skript-Integrität, MFA, Audit-Logging und Pen-Testing — alles Themen, die sich nicht kurzfristig durch eine Checkliste abarbeiten lassen. Wer jetzt erst anfängt, hat Handlungsdruck. Mehr zum Sicherheits-Mindset haben wir im Zero-Trust-Guide für Online-Shops zusammengefasst.
| Bereich | v3.2.1 (bis 03/2024) | v4.x (ab 04/2025) |
|---|---|---|
| Passwortlänge | mindestens 7 Zeichen | mindestens 12 Zeichen, alphanumerisch (Req. 8.3.6) |
| MFA | nur Administratoren | alle Non-Console-Zugriffe in der CDE (Req. 8.4.2) |
| Skript-Inventar | nicht gefordert | vollständiges Inventar mit Autorisierung (Req. 6.4.3) |
| Tamper-Detection | nicht gefordert | mindestens wöchentliche Prüfung der Payment-Page (Req. 11.6.1) |
| Audit-Log-Review | täglich manuell möglich | automatisiert (Req. 10.4.1.1) |
| Pen-Testing | jährlich | jährlich plus Multi-Tenant-Support (Req. 11.4.7) |
Neu in v4.x ist der "Customized Approach": Organisationen dürfen Schutzziele auch mit alternativen Kontrollen erreichen, solange ein dokumentiertes Risk-Assessment vorliegt. Das gibt größeren Shops Spielraum, setzt aber voraus, dass Bedrohungsmodelle sauber formalisiert werden. Für die meisten KMU bleibt der "Defined Approach" mit den Standardkontrollen der pragmatische Weg.
Magecart und Web-Skimming: Die akute Bedrohung
Magecart bezeichnet eine lose Gruppe von Akteuren, die JavaScript in Checkout-Seiten einschleusen und Kartendaten direkt im Browser des Kunden abgreifen — unbemerkt vom Shop-Backend und von klassischen Firewalls. Die Angriffe treffen oft nicht die Shop-Software selbst, sondern Drittanbieter-Skripte, die auf der Payment-Seite geladen werden. Weil der Abgriff im Browser des Kunden stattfindet, bleibt er in Server-Logs und Bestelldaten unsichtbar; auffällig wird er meist erst, wenn Kartenherausgeber Missbrauchsmuster melden.
Besonders schmerzhaft war 2024 die Schwachstelle CosmicSting (CVE-2024-34102): Über sie ließen sich Verschlüsselungsschlüssel aus betroffenen Shop-Systemen auslesen und darüber eigener Code einschleusen. Wer Sicherheitsupdates verzögert einspielt, lässt genau solche Lücken offen — Skimming-Code kann dann wochenlang unbemerkt mitlaufen. Die Gegenmaßnahme ist unspektakulär: Patch-Fenster verbindlich terminieren und die Payment-Seite auf unerwartete Skripte überwachen.
Magecart-Skripte werden oft über legitime Drittanbieter (Analytics, Chat, Werbe-Pixel) nachgeladen. Server-seitige Scanner sehen davon nichts, weil die Manipulation erst im Browser passiert. Genau deshalb verlangen Requirements 6.4.3 und 11.6.1 ein aktives Skript-Management mit Integritätsprüfung. Ergänzend empfiehlt sich ein zweiter Verteidigungsring gegen KI-gestützte Angriffe, denn Angreifer automatisieren ihre Kampagnen zunehmend.
Skript-Management nach 6.4.3 und 11.6.1
Requirements 6.4.3 und 11.6.1 sind das Herzstück der v4.x-Neuerungen für Shop-Betreiber. Sie verlangen drei Dinge: ein vollständiges Inventar aller Skripte, die auf Zahlungsseiten geladen werden, eine dokumentierte Autorisierung jedes Skripts mit Begründung seiner Notwendigkeit und eine Integritätsprüfung per Tamper-Detection mindestens einmal pro Woche (PCI SSC/Akamai). In der Praxis heißt das: Jedes externe oder intern nachgeladene Skript muss bekannt, dokumentiert und überwacht sein.
Die Dimension wird oft unterschätzt. Eine Checkout-Seite lädt neben dem eigenen Code regelmäßig Analyse-, Chat-, Test- und Zahlungsskripte — jedes davon kann Zugriff auf die Eingabefelder bekommen. Zählen Sie das Skript-Inventar Ihrer eigenen Payment-Seite darum einmal aus: Der Netzwerk-Reiter der Entwicklerwerkzeuge liefert den Ausgangspunkt für Req. 6.4.3, nicht ein Branchendurchschnitt. Im E-Commerce stammt ein erheblicher Teil des JavaScripts von Drittanbietern, und genau dieser Teil steht selten unter eigener Kontrolle.
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 für statisch eingebundene Skripte -->
<script
src="https://js.psp.example/v1/widget.js"
integrity="sha384-4g5z.../abc123=="
crossorigin="anonymous"></script>CSP und Subresource Integrity sind jedoch nur Bausteine. Ergänzend braucht es Server-seitiges Rendering, ein Script-Inventar im Change-Management und ein Monitoring, das Hash-Abweichungen protokolliert und alarmiert. Wer eine Plattform wie Shopware betreibt, sollte Theme-Updates und Plugin-Rollouts zwingend mit einem Skript-Audit koppeln.
MFA und Authentifizierung verschärft
Die Passwort-Anforderungen wurden mit v4.x deutlich verschärft. Requirement 8.3.6 verlangt nun mindestens 12 alphanumerische Zeichen (vorher 7). Viel wichtiger ist Requirement 8.4.2: Seit dem 31. März 2025 muss Multi-Faktor-Authentifizierung für jeden Non-Console-Zugriff innerhalb der CDE aktiv sein, nicht mehr nur für administrative Accounts (PCI SSC). Das betrifft jeden Shop-Mitarbeiter, der remote auf Server, Datenbanken oder Admin-Oberflächen zugreift, über die Kartendaten sichtbar sein könnten.
Warum das so wichtig ist, zeigt der Verizon DBIR 2025: Die Nutzung gestohlener Zugangsdaten liegt als Einstiegsweg bei 22 %, die Ausnutzung von Schwachstellen bei 20 % aller ausgewerteten Datenpannen (Verizon). Ein zweiter Faktor — idealerweise als Hardware-Key oder Phishing-resistenter Authenticator — entwertet den kompromittierten Login. Wer bisher SMS-Codes einsetzt, sollte zeitnah auf TOTP- oder FIDO2-basierte Verfahren migrieren. Für die praktische Umsetzung planen wir in unseren Beratungsprojekten standardmäßig ein Rollen-Audit ein: Wer braucht wirklich CDE-Zugriff, wer kann über ein gescoptes Admin-Panel abgebildet werden?
Vulnerability Scans und Penetration Tests im Quartalstakt
PCI DSS 4.x schreibt quartalsweise externe ASV-Scans durch einen Approved Scanning Vendor vor. Jede Schwachstelle mit CVSS-Score ≥ 4,0 muss innerhalb des Scan-Fensters behoben und in einem Clean-Scan nachgewiesen werden (PCI SSC). Ergänzend sind authentifizierte interne Scans (Req. 11.3.1.2) ebenfalls quartalsweise verpflichtend (PCI SSC). Penetration-Tests sind jährlich sowie nach wesentlichen Änderungen durchzuführen. Neu: Seit dem 31. März 2025 müssen Multi-Tenant-Service-Provider (also auch Hoster und Cloud-Anbieter) ihre Kunden aktiv bei externem Pen-Testing unterstützen — Requirement 11.4.7 (PCI SSC). Für Shop-Betreiber bedeutet das konkret: der Hoster muss Testumgebungen, Zugangswege und eine Koordinationsinstanz bereitstellen, damit Pen-Tester legal und produktivsicher arbeiten können. Wer eigenen Code im Checkout pflegt, profitiert zusätzlich von begleitender individueller Programmierung, die Security-Reviews in jede Release-Pipeline einzieht.
Tokenisierung als Scope-Reduzierer
Die wirkungsvollste Strategie, um PCI-Aufwand überhaupt zu reduzieren, bleibt die Tokenisierung: Statt der echten Kartennummer (PAN) verarbeitet und speichert der Shop nur ein Token des Payment Service Providers. Je weniger Systeme die PAN überhaupt zu sehen bekommen, desto kleiner fällt der Geltungsbereich aus, den ein Assessment abdecken muss. Network Tokens gehen noch einen Schritt weiter: Sie werden direkt vom Kartennetzwerk ausgestellt und automatisch aktualisiert, wenn Karten verloren gehen oder ablaufen. Das senkt die Zahl der Zahlungsabbrüche durch abgelaufene Karten.
Network Tokens
Das Kartennetzwerk stellt ein eigenes Token aus und aktualisiert es beim Kartentausch automatisch — hinterlegte Zahlungsmittel bleiben nutzbar.
Token statt PAN
Der Shop speichert nur das Token des Zahlungsdienstleisters. Die echte Kartennummer erreicht die eigenen Systeme gar nicht erst.
Kleinerer Geltungsbereich
Wer die PAN konsequent auslagert, hält Systeme aus dem PCI-Geltungsbereich heraus. Wie weit das trägt, klärt der Assessor am konkreten Aufbau.
Für die meisten deutschen Mittelständler ist damit der Weg klar: PAN so früh wie möglich durch Tokens ersetzen, den Checkout in einen gehosteten Iframe oder eine Redirect-Seite des PSP auslagern und im Shop-Backend nur noch Tokens vorhalten. Wer Wallet-Zahlungen und neue europäische A2A-Verfahren wie Wero einbindet, entkoppelt sich zusätzlich von klassischen Kartenrisiken. Und Express-Checkout-Varianten profitieren ohnehin von tokenisierten Zahlungsmitteln.
SAQ A vs. A-EP vs. D — welcher Bogen für welchen Shop?
Self-Assessment Questionnaires (SAQs) sind die praktische Umsetzung der Compliance für Merchants der Stufen 2 bis 4. Die Wahl des richtigen SAQ entscheidet über Aufwand und Kosten. SAQ A richtet sich an Shops, die den Zahlungsprozess vollständig an einen PCI-konformen Dienstleister auslagern (iframe oder Redirect). SAQ A-EP gilt für Shops, die zwar keine PAN-Daten berühren, deren Server aber den Zahlungsprozess beeinflussen (z. B. durch eigene Checkout-Logik). SAQ D ist die Vollversion für Merchants, die Kartendaten selbst verarbeiten oder speichern.
| Kriterium | SAQ A | SAQ A-EP | SAQ D (Merchant) |
|---|---|---|---|
| Typischer Shop | iframe / Redirect-Checkout | Eigener Checkout mit JS-Hosted Fields | Server verarbeitet PAN |
| Anforderungsumfang | am geringsten | deutlich größer | am größten |
| Skript-Management 6.4.3 / 11.6.1 | Pflicht seit 31.03.2025 oder PSP-Nachweis (FAQ 1588) | Pflicht | Pflicht |
| MFA Req. 8.4.2 | in Admin-Zonen | Pflicht in gesamter CDE | Pflicht in gesamter CDE |
| ASV-Scans quartalsweise | nicht erforderlich | erforderlich | erforderlich |
| Typischer Aufwand | niedrig bis mittel | hoch | sehr hoch |
Mit FAQ 1588 (Stand 31.03.2025) hat das PCI SSC klargestellt: Auch iframe-Merchants müssen die Skript-Anforderungen 6.4.3 und 11.6.1 entweder selbst umsetzen oder eine dokumentierte Bestätigung ihres PSP vorlegen, dass dieser die Skripte auf der Payment-Seite managt (PCI SSC). Wer bisher gedacht hat, ein iframe schiebe die Verantwortung komplett weiter, liegt falsch. Prüfen Sie die Verträge Ihres Payment-Dienstleisters entsprechend.
Cloud Shared Responsibility verstehen
Wer seinen Shop in der Cloud betreibt, teilt sich die PCI-Verantwortung mit dem Betreiber der Plattform. Seriöse Anbieter veröffentlichen dazu eine Verantwortungsmatrix, in der steht, welche Kontrollen sie selbst abdecken und welche beim Kunden bleiben — Daten, Betriebssystem-Patches und Firewall-Konfiguration gehören in der Regel zur Kundenverantwortung. Fordern Sie diese Matrix an und gleichen Sie sie Anforderung für Anforderung mit dem eigenen Aufbau ab. Entscheidend ist, den eigenen Anteil aktiv zu erheben und nicht davon auszugehen, dass eine geprüfte Plattform alle Kontrollen automatisch abdeckt.
Wer einen deutschen Hoster bevorzugt, sollte auf eine ausdrückliche PCI-Verantwortlichkeitsmatrix und auf belegbare Zertifizierungen für das Rechenzentrum achten. Für unsere Shop-Kunden liefern wir eine dokumentierte Trennung der Verantwortlichkeiten sowie Logging- und Patch-Workflows, die sich am PCI-Mindestmass orientieren — ohne dass wir einen eigenen QSA-Status anbieten.
Compliance in 7 Schritten erreichen
Der Weg zu PCI DSS 4.0 lässt sich pragmatisch strukturieren. Die folgende Reihenfolge hat sich in unseren Beratungsprojekten bewährt und vermeidet teure Umwege.
- Scope festlegen: Alle Systeme, Netzwerke, Skripte und Dienstleister identifizieren, die Kartendaten berühren oder beeinflussen können. Diagramm mit Datenflüssen anfertigen.
- Gap-Analyse: Ist-Zustand gegen die 64 Neuerungen von v4.x spiegeln, priorisierte Lücken-Liste mit Verantwortlichen erstellen.
- Scope reduzieren: Kartendaten tokenisieren, Checkout auf gehosteten PSP auslagern, Admin-Zonen aus der CDE entfernen — die wirkungsvollste Maßnahme vor jeder Technik.
- Skript-Inventar aufbauen: Jede Zeile JavaScript auf Zahlungsseiten erfassen, CSP und SRI aktivieren, Tamper-Detection-Monitoring einrichten (Req. 6.4.3/11.6.1).
- Technische Kontrollen härten: MFA 8.4.2 überall, Passwort-Policy 8.3.6 auf 12 Zeichen, automatisierte Log-Reviews 10.4.1.1 aufsetzen.
- Scans und Tests: ASV-Scans quartalsweise, interne authentifizierte Scans, jährliche Pen-Tests — alles mit dokumentierten Reports und Remediation-Nachweisen.
- Kontinuierliches Monitoring: Audit-Logs 12 Monate vorhalten (davon drei Monate sofort abrufbar), Security-Control-Ausfälle gemäß 10.7.2 erkennen und beheben.
Compliance ist kein Zustand, sondern ein Betriebsmodus. Einmal bestanden, verfallen Kontrollen schnell: ein Konto ohne MFA, ein neues Skript auf der Payment-Seite, ein Log-Review, der drei Monate ausfällt. Wer Compliance als Dauerbetrieb und nicht als jährliches Ritual begreift, vermeidet spätere Nachbesserungen. Auch Marketing-Attribution und Fraud-Prevention profitieren von sauber geführten Audit-Logs.
Wie XICTRON Ihre Shop-Sicherheit härtet
Wir begleiten Shop-Betreiber bei der Umsetzung von PCI DSS 4.0 entlang des gesamten Stacks — vom Hosting über Scope-Reduktion durch Tokenisierung und sauberes Skript-Management für Shopware- und WooCommerce-Checkouts bis zu MFA-Rollouts und automatisierten Log-Reviews im Cloud-Betrieb. Wir liefern keine QSA-Zertifizierung, sondern die technische und organisatorische Grundlage, auf der Ihr QSA anschließend prüfen kann. Starten Sie am besten mit einem strukturierten Gap-Assessment.
Dieser Artikel basiert auf Daten und Anforderungen aus: PCI Security Standards Council (v4.0 / v4.0.1 / FAQ 1588), Akamai (State of the Internet 2025), BSI (Lagebericht 2025), bevh (E-Commerce Deutschland), IBM (Cost of a Data Breach Report 2026), Verizon (DBIR 2025) und Bitkom (Wirtschaftsschutz). Die genannten Werte können je nach Stichtag, Region und Merchant-Profil variieren.
Ja. Seit FAQ 1588 (Stand 31.03.2025) hat das PCI SSC klargestellt, dass auch iframe-Merchants die Skript-Anforderungen 6.4.3 und 11.6.1 entweder selbst umsetzen müssen oder eine dokumentierte Bestätigung ihres Payment Service Providers vorlegen müssen, dass dieser die Skripte auf der Payment-Seite managt (PCI SSC). SAQ A umfasst deutlich weniger Fragen als SAQ D, entbindet aber nicht von Skript-Integrität und MFA.
PCI-Strafen verhängt nicht der Standard selbst; sie werden über den Acquirer-Vertrag durchgesetzt. Höhe und Auslöser stehen dort und unterscheiden sich je Vertrag und Merchant-Größe. Im Schadenfall kommen Forensik, Kartenersatz und die Benachrichtigung der Betroffenen hinzu. In der Regel schützen sich Organisationen davor durch frühzeitige Gap-Analysen und dokumentierte Maßnahmen.
Externe ASV-Scans sind quartalsweise verpflichtend; jede Schwachstelle ab CVSS 4,0 muss im Scan-Fenster behoben und in einem Clean-Scan nachgewiesen werden (PCI SSC). Authentifizierte interne Scans (Req. 11.3.1.2) sind ebenfalls quartalsweise erforderlich (PCI SSC). Penetration-Tests sind jährlich sowie nach wesentlichen Änderungen der CDE durchzuführen.
Ja. Tokenisierung ist der wirkungsvollste Einzelhebel: Die echte Kartennummer (PAN) erreicht die Shop-Systeme gar nicht erst, damit fallen ganze Systeme aus dem PCI-Geltungsbereich. Network Tokens der Kartennetzwerke aktualisieren sich zudem automatisch, wenn eine Karte ersetzt wird. Wie weit die Reduktion im Einzelfall trägt, hängt vom Aufbau des Checkouts ab und gehört in die Abstimmung mit Assessor und Zahlungsdienstleister.
Seit dem 31. März 2025 müssen Multi-Tenant-Service-Provider nach Requirement 11.4.7 ihre Kunden bei externem Pen-Testing unterstützen (PCI SSC). Das betrifft jeden Managed-Hoster, auf dem Shop-Software betrieben wird. Unsere Managed-Umgebungen für Shop-Kunden stellen Testumgebungen, klare Kommunikationswege und dokumentierte Shared-Responsibility-Matrizen bereit. Eine vollständige QSA-Zertifizierung ersetzen wir damit nicht — wir schaffen aber die technische Grundlage.
PCI DSS 4.x verlangt, dass Audit-Logs mindestens zwölf Monate aufbewahrt werden, davon die letzten drei Monate direkt und ohne Wiederherstellung aus Backups zugreifbar (PCI SSC). Requirement 10.4.1.1 fordert seit dem 31.03.2025 zusätzlich automatisierte Log-Reviews, und 10.7.2 verlangt das fortlaufende Erkennen und Beheben von Ausfällen der Security-Controls (PCI SSC). Praktisch heißt das: Log-Pipeline mit zentralem SIEM, Alarm bei Ausfall einer Quelle und dokumentierte Incident-Reaktion.