PCI DSS 4.0.1 im Jahr 2026: Der Leitfaden für kleine Händler zu SAQ A, Script-Tampering und MFA

Wenn Ihr Online-Shop auch nur ein einziges Drittanbieter-Skript auf der Seite lädt, das ein Zahlungsformular berührt, können Sie nicht mehr davon ausgehen, dass die einfachste Version der PCI-Konformität für Sie gilt. Dieser einzelne Satz, der in den FAQ für PCI DSS v4.0.1 versteckt ist, hat die Compliance-Landschaft für Hunderttausende kleiner Händler im Jahr 2026 stillschweigend neu gezeichnet – und viele von ihnen werden es erst merken, wenn ihr Acquirer Beweise verlangt, die sie nicht erbringen können.

PCI DSS v4.0.1 ist keine sanfte Aktualisierung. Die 64 neuen oder aktualisierten Anforderungen sind seit dem 31. März 2025 obligatorisch; jede Bewertung im Jahr 2026 erfolgt nach dem neuen Standard, und die Zulassungsregeln für den benutzerfreundlichsten Selbstauskunftsfragebogen (SAQ) wurden in einer Weise verschärft, die die meisten E-Commerce-Shops mit Outsourcing-Modell überraschen wird. Die gute Nachricht ist, dass der Standard für ein kleines Unternehmen mit klarem Kopf und einer Checkliste weiterhin bewältigbar bleibt. Die schlechte Nachricht ist, dass „wir nutzen Stripe Checkout, also passt alles“ keine automatische Antwort mehr ist.

Dieser Leitfaden erläutert, was sich geändert hat, welchen Fragebogen Ihr Unternehmen tatsächlich benötigt, die zwei neuen Anforderungen (6.4.3 und 11.6.1), die den alten SAQ A „aufgefressen“ haben, die Authentifizierungsregeln, über die kleine Teams stolpern, und die realistischen Kosten, wenn man hierbei Fehler macht.

Der Status von PCI DSS im Jahr 2026

Der Payment Card Industry Data Security Standard ist das vertragliche Regelwerk, das die großen Kartenmarken – Visa, Mastercard, American Express, Discover, JCB – jedem Unternehmen auferlegen, das Karteninhaberdaten speichert, verarbeitet oder überträgt. Man „reicht ihn nicht bei der Regierung ein“. Ihr Acquirer (die Bank oder der Zahlungsdienstleister, der es Ihnen ermöglicht, Karten zu akzeptieren) setzt ihn über Ihren Händlervertrag durch und ist derjenige, der die Bußgelder einzieht, wenn etwas schiefgeht.

PCI DSS v4.0 wurde im März 2022 veröffentlicht. Version 4.0.1 – eher eine Klärung als ein völlig neuer Standard – wurde Mitte 2024 zur aktiven Version. Der Übergangszeitraum endete am 31. März 2025: Ab diesem Datum ist jede der 51 zukunftsdatierten Anforderungen ohne Schonfrist relevant, und jede im Jahr 2026 durchgeführte Bewertung erfolgt nach v4.0.1. Es gibt keine Option mehr, auf v3.2.1 zurückzugreifen.

Die 12 übergeordneten Anforderungsfamilien bleiben gleich und sind in sechs Kontrollziele unterteilt:

• Aufbau und Wartung eines sicheren Netzwerks: Firewalls und Standardeinstellungen der Anbieter (Anforderungen 1–2)
• Schutz von Karteninhaberdaten: Gespeicherte Daten und Datenübertragung (Anforderungen 3–4)
• Aufrechterhaltung eines Programms zum Management von Schwachstellen: Anti-Malware und sichere Entwicklung (Anforderungen 5–6)
• Implementierung starker Zugriffskontrollmaßnahmen: „Need-to-know“-Prinzip, Identifizierung, physischer Zugriff (Anforderungen 7–9)
• Regelmäßige Überwachung und Prüfung von Netzwerken: Protokollierung und Prüfung (Anforderungen 10–11)
• Aufrechterhaltung einer Informationssicherheitsrichtlinie: Governance (Anforderung 12)

Was sich in v4.0.1 geändert hat, ist die Tiefe, nicht die Breite. Der Standard erwartet nun von Ihnen, dass Sie darüber nachdenken, wie Skripte auf Zahlungsseiten ausgeführt werden, wie oft Sie Ihre eigenen Kontrollen überprüfen, wie Sie Administratoren authentifizieren und ob das Passwort, das Ihr Buchhalter vor fünf Jahren gewählt hat, noch akzeptabel ist.

Händler-Level: Wo die meisten kleinen Unternehmen stehen

Die Kartenmarken ordnen jeden Händler basierend auf dem jährlichen Transaktionsvolumen einem von vier Leveln zu. Das Level bestimmt, wie die Compliance validiert wird, nicht, ob der Standard gilt.

• Level 1: mehr als 6 Millionen Kartentransaktionen pro Jahr oder jeder Händler, bei dem ein bestätigter Datendiebstahl von Kontodaten vorliegt. Erfordert eine jährliche Vor-Ort-Bewertung durch einen Qualified Security Assessor (QSA) und einen vierteljährlichen Scan durch einen Approved Scanning Vendor (ASV).
• Level 2: 1 Million bis 6 Millionen Transaktionen pro Jahr. In der Regel ein jährlicher SAQ oder eine Vor-Ort-Bewertung durch einen QSA, abhängig von der Kartenmarke.
• Level 3: 20.000 bis 1 Million E-Commerce-Transaktionen pro Jahr. Jährlicher SAQ plus vierteljährliche ASV-Scans.
• Level 4: weniger als 20.000 E-Commerce-Transaktionen pro Jahr oder bis zu 1 Million Transaktionen insgesamt über alle Kanäle hinweg. Jährlicher SAQ und für die meisten Kanäle vierteljährliche ASV-Scans.

Wenn Sie eine Online-Boutique, einen SaaS-Abrechnungsprozess, ein regionales Dienstleistungsunternehmen oder ein einzelnes Restaurant betreiben, gehören Sie fast sicher zu Level 4. Das betrifft die überwiegende Mehrheit der Händler weltweit. Die Validierung ist einfacher, aber der zugrunde liegende Standard ist identisch – eine durchgesickerte Kartennummer bei einem Händler mit 200 Transaktionen pro Jahr wird genauso behandelt wie ein Leck bei einem Großunternehmen.

Selbstauskunftsfragebögen (SAQs): Wählen Sie den richtigen aus

Über den Selbstauskunftsfragebogen (Self-Assessment Questionnaire, SAQ) bescheinigen Händler der Level 2–4 ihre Compliance. Der PCI Council unterhält neun SAQs, und welcher der richtige ist, hängt genau davon ab, wie Ihre Zahlungsdaten fließen. Die Wahl des falschen SAQ ist der häufigste Fehler, den kleine Händler machen.

• SAQ A: E-Commerce- oder Versandhandel-/Telefonhandel-Händler, die alle Funktionen für Karteninhaberdaten vollständig an PCI-DSS-validierte Dritte auslagern. Früher die einfachste Lösung für Shopify-, Stripe Checkout- und PayPal-Händler – aber lesen Sie den nächsten Abschnitt, da die Zulassungsregeln verschärft wurden.
• SAQ A-EP: E-Commerce-Händler, die die Zahlungsabwicklung teilweise auslagern, deren Website jedoch weiterhin die Sicherheit der Transaktion beeinflusst (zum Beispiel Websites, die ihre eigene Checkout-Seite erstellen und eine Zahlungs-API aufrufen).
• SAQ B: Händler, die nur Imprint-Maschinen oder eigenständige Terminals mit Einwahlverbindung verwenden. Keine Internetverbindung berührt Kartendaten.
• SAQ B-IP: Händler, die eigenständige IP-verbundene Zahlungsterminals verwenden (die meisten modernen Tresen-Terminals).
• SAQ C-VT: Händler, die Kartendaten über ein virtuelles Terminal an einem isolierten Arbeitsplatz eingeben.
• SAQ C: Händler mit einer Zahlungsanwendung, die mit dem Internet verbunden ist, wobei keine Daten gespeichert werden.
• SAQ P2PE: Händler, die eine validierte Point-to-Point-Verschlüsselungslösung verwenden.
• SAQ D-Merchant: Auffangkategorie für Händler, auf die kein anderer SAQ passt – und mit Abstand der umfangreichste Fragebogen.
• SAQ D-Service Provider: für Dienstleister, die zur Selbstauskunft berechtigt sind.

Jeder SAQ fragt nur die Teilmenge der über 300 Kontrollen ab, die für das jeweilige Akzeptanzmodell relevant sind. SAQ A hat weniger als 30 Fragen; SAQ D-Merchant hat über 250. Der Aufwandsunterschied ist enorm, weshalb Händler sich wann immer möglich für SAQ A qualifizieren wollen.

Die SAQ-A-Berechtigungsfalle

Die wichtigste Änderung, die kleine E-Commerce-Händler im Jahr 2026 verstehen müssen, ist, wer sich tatsächlich für den SAQ A qualifiziert. Das PCI Security Standards Council hat Anfang 2025 die FAQ 1588 veröffentlicht und die Kriterien erheblich verschärft.

Unter der Version 4.0.1 ist der SAQ A nur noch verfügbar, wenn Sie bestätigen können, dass Ihre E-Commerce-Seiten – einschließlich der Seite, die Ihr eingebettetes Zahlungs-Iframe oder Redirect enthält – nicht anfällig für Angriffe durch Skripte sind, die Ihre Zahlungsumgebung beeinträchtigen könnten. Dies ist eine Reaktion auf die Welle von Digital-Skimming-Angriffen (oft als „Magecart“ bezeichnet), bei denen Angreifer eine JavaScript-Bibliothek eines Drittanbieters kompromittieren und Kartendaten selbst von Websites exfiltrieren, die dachten, sie hätten alles ausgelagert.

In der Praxis können Sie dies auf zwei Arten erfüllen:

1. Implementieren Sie die Skript-Schutzmaßnahmen der Anforderungen 6.4.3 und 11.6.1 selbst. Erfassen Sie jedes Skript, das auf Ihrer Zahlungsseite geladen wird, autorisieren Sie jedes einzelne, begründen Sie dessen Notwendigkeit und implementieren Sie einen Mechanismus zur Erkennung von Änderungen und Manipulationen, der Sie alarmiert, wenn sich ein HTTP-Header oder Seiteninhalt unerwartet ändert. Der Mechanismus muss die Zahlungsseite mindestens alle sieben Tage bewerten oder in einer Häufigkeit, die Sie durch eine gezielte Risikoanalyse rechtfertigen.
2. Holen Sie eine schriftliche Bestätigung Ihres Zahlungsabwicklers ein, dass seine eingebettete Lösung integrierte Schutzmaßnahmen gegen skriptbasierte Angriffe in Ihrem Namen enthält.

Der zweite Weg ist derjenige, den die meisten kleinen Händler einschlagen werden, aber er erfolgt nicht automatisch. Sie benötigen eine dokumentierte Erklärung des Abwicklers – keine Marketingseite. Viele Händler von Stripe, Adyen, Braintree und Square werden feststellen, dass ihr Abwickler eine entsprechende Bescheinigung (Attestation) veröffentlicht hat; einige kleinere Gateways haben dies nicht getan. Wenn Ihr Abwickler Ihnen diese Bestätigung nicht schriftlich geben kann, müssen Sie den SAQ A-EP ausfüllen oder die Kontrollen selbst aufbauen.

Falls Ihr „ausgelagerter“ Checkout tatsächlich vom Händler kontrolliertes JavaScript lädt, das das Zahlungsformular beeinflussen könnte – etwa Analyse-Tools, A/B-Tests, Chat-Widgets, Tag-Manager –, führt die konservative Auslegung dazu, dass Sie sich nicht mehr für den SAQ A qualifizieren, ungeachtet dessen, was Ihr Abwickler sagt.

Authentifizierung: Die zwei Regeln, die kleine Teams treffen

Unabhängig davon, welcher SAQ gilt, überraschen zwei Änderungen der Zugriffskontrolle in v4.0.1 fast jedes kleine Unternehmen.

Anforderung 8.3.6: Passwörter müssen mindestens 12 Zeichen lang sein. Wenn das System nur 8 Zeichen unterstützt, können Sie bei 8 bleiben, aber jedes leistungsfähigere System muss hochgestuft werden. Passwörter müssen sowohl numerische als auch alphabetische Zeichen enthalten. Das alte Minimum von 7 Zeichen aus v3.2.1 ist hinfällig.

Anforderung 8.4.2: Multi-Faktor-Authentifizierung für jeden Zugriff auf die Karteninhaberdatenumgebung. Zuvor war MFA nur für den Fernzugriff durch Administratoren erforderlich. Unter v4.0.1 benötigt jeder – Administrator, Entwickler, Drittanbieter-Support, Sie selbst – jedes Mal MFA, wenn er auf eine Systemkomponente innerhalb der Karteninhaberdatenumgebung (CDE) zugreift, nicht nur bei einer Verbindung von außerhalb des Netzwerks. Die MFA selbst muss resistent gegen Replay-Angriffe sein und mindestens zwei der folgenden Faktoren erfordern: etwas, das Sie wissen; etwas, das Sie haben; etwas, das Sie sind.

Für einen kleinen Händler bedeutet die praktische Umsetzung: Aktivieren Sie MFA in Ihrem Abwickler-Portal, Ihrem Hosting-Control-Panel, Ihrem Domain-Registrar, Ihrem DNS-Anbieter, Ihrem E-Commerce-Admin-Bereich, Ihrem POS-Backoffice und auf jedem Laptop, der mit diesen Systemen in Berührung kommt. Verwenden Sie eine Authentifizierungs-App oder einen Hardware-Schlüssel – SMS-basierte MFA wird zunehmend als unzureichend angesehen, auch wenn der Standard sie technisch noch zulässt.

Gezielte Risikoanalyse: Das Dokument, das Sie wahrscheinlich benötigen

PCI DSS v4.x führt die gezielte Risikoanalyse (Targeted Risk Analysis, TRA) ein – eine kurze, dokumentierte Analyse, mit der Sie rechtfertigen, wie häufig Sie bestimmte Kontrollen durchführen. Etwa ein Dutzend Anforderungen enthalten die Option „Häufigkeit gemäß der gezielten Risikoanalyse des Unternehmens definiert“.

Anforderung 12.3.1 legt fest, was eine TRA enthalten muss: Identifizierung des zu schützenden Assets, die abzuwehrende Bedrohung, die Faktoren, die Wahrscheinlichkeit und Auswirkungen beeinflussen, sowie die Begründung für die gewählte Häufigkeit. Das PCI Council veröffentlicht eine Vorlage in Anhang E2 des Standards.

Für einen Level-4-Händler ist dies in der Regel ein einseitiges Dokument pro Kontrolle. Der Fehler, den es zu vermeiden gilt, ist, es ganz wegzulassen. Wenn Ihr Auditor oder Acquirer Sie fragt, warum Sie Ihre Zahlungsseite alle 30 Tage statt alle 7 Tage auf Manipulationen scannen, ist „wir dachten, es reicht aus“ keine akzeptable Antwort; „hier ist unsere TRA vom 14. Januar 2026, unterzeichnet vom Inhaber“ hingegen schon.

Halten Sie sich vom maßgeschneiderten Ansatz (Customized Approach) der Version 4.0 fern. Dieser existiert für risikobewusste Großunternehmen mit spezialisierten Sicherheitsteams; für kleine Händler ist der definierte Ansatz (Defined Approach) mit seiner expliziten Checkliste schneller, kostengünstiger und einfacher zu verteidigen.

Was Nicht-Konformität tatsächlich kostet

Kleine Händler unterschätzen das finanzielle Risiko, weil sich die Bußgelder hypothetisch anfühlen, bis sie es nicht mehr sind. Die Zahlen, die aus Acquirer-Gebührenordnungen und Branchenberichten stammen, sind ernüchternd.

Routinehafte Nicht-Konformität – etwa das Versäumnis, einen SAQ einzureichen oder abgelaufene ASV-Scans – löst in der Regel monatliche Strafzahlungen Ihres Acquirers aus, die bei 5.000 bis 10.000 US-Dollar pro Monat beginnen. Nach drei bis sechs Monaten der Nicht-Konformität steigen diese Strafen üblicherweise auf 25.000 bis 50.000 US-Dollar pro Monat an, und chronische Verstöße können 50.000 bis über 100.000 US-Dollar pro Monat erreichen. Der Acquirer kann zudem Ihre Bearbeitungsgebühren pro Transaktion erhöhen oder das Händlerkonto kündigen, was oft schädlicher ist als die Bußgelder selbst.

Ein bestätigter Datendiebstahl spielt in einer anderen Liga. Kartenorganisationen verhängen Strafen von etwa 50 bis 90 US-Dollar pro kompromittiertem Datensatz, zusätzlich zu den obligatorischen Kosten für forensische Untersuchungen (ab 15.000 US-Dollar), Gebühren für die Neuausstellung von Karten, die die Organisationen an den Händler weitergeben, und den Chargebacks für betrügerische Transaktionen. Branchenstudien beziffern die durchschnittlichen Gesamtkosten einer Kreditkartendaten-Verletzung für einen mittelgroßen Händler auf 150.000 bis 3 Millionen US-Dollar; bei großen Vorfällen geht es in die Millionen. Für einen Level-4-Händler mag die jährliche Compliance etwa 3.000 US-Dollar kosten, während ein einziger Vorfall den Gewinn eines ganzen Jahrzehnts vernichten kann.

Zudem kommen staatliche Gesetze und Behörden wie die FTC ins Spiel. Benachrichtigungskosten, Anwaltsgebühren, das Risiko von Sammelklagen und behördliche Nachprüfungen übersteigen routinemäßig die Strafzahlungen der Kartenorganisationen selbst.

Eine praktische Compliance-Checkliste 2026 für kleine Händler

Der Standard wirkt in seiner Gesamtheit einschüchternd, aber die Checkliste für einen typischen kleinen E-Commerce- oder Dienstleistungshändler ist überschaubar. Arbeiten Sie sie in dieser Reihenfolge ab.

1. Bestätigen Sie Ihre Händler-Stufe (Merchant Level) schriftlich bei Ihrem Acquirer. Die Stufen werden pro Acquirer-Beziehung vergeben, nicht global.
2. Erstellen Sie eine Übersicht Ihres Karteninhaber-Datenflusses. Zeichnen Sie ein Diagramm, das zeigt, wo Kartendaten eingehen, wohin sie fließen und wo sie das System verlassen. Falls Kartendaten jemals auf Ihren Servern landen, erweitert sich Ihr Prüfungsumfang (Scope) enorm.
3. Wählen Sie den richtigen SAQ aus. Lesen Sie jede Option sorgfältig durch. Wenn Sie als E-Commerce-Händler SAQ A beanspruchen, prüfen Sie Ihre Berechtigung anhand von FAQ 1588.
4. Lassen Sie sich von Ihrem Zahlungsdienstleister schriftlich bestätigen, dass dessen eingebettete Lösung Schutz vor Skript-Angriffen bietet. Legen Sie dies zu Ihren Compliance-Unterlagen.
5. Inventarisieren Sie jedes Skript auf Ihren Zahlungsseiten. Wenn Sie keine Bestätigung vom Zahlungsdienstleister erhalten können, bereiten Sie sich darauf vor, Anforderung 6.4.3 (autorisierte Skripte) und 11.6.1 (Erkennung von Manipulationen) umzusetzen.
6. Aktivieren Sie MFA überall, wo ein Administrator Zugriff auf Zahlungssysteme hat. Nutzen Sie eine Authentifizierungs-App, kein SMS.
7. Erhöhen Sie die Passwortlänge auf mindestens 12 Zeichen mit einer Mischung aus Zahlen und Buchstaben.
8. Planen Sie vierteljährliche ASV-Scans ein, sofern Ihr SAQ diese erfordert (meist der Fall bei Systemen mit Internetverbindung).
9. Dokumentieren Sie eine gezielte Risikoanalyse für alle Kontrollen, deren Häufigkeit Sie selbst festlegen.
10. Erstellen Sie eine Informationssicherheitsrichtlinie (Anforderung 12). Ein einfaches einseitiges Dokument, das die akzeptable Nutzung, Kontakte für die Reaktion auf Vorfälle und einen jährlichen Überprüfungsplan abdeckt, genügt den Grundlagen für kleine Händler.
11. Schulen Sie jährlich jeden Mitarbeiter, der mit Zahlungen in Berührung kommt. Führen Sie Teilnehmerlisten oder E-Learning-Nachweise.
12. Reichen Sie den SAQ und die Konformitätsbescheinigung (Attestation of Compliance) fristgerecht bei Ihrem Acquirer ein. Tragen Sie dies in Ihren Kalender ein.

Selbst bei dieser Detailtiefe deckt ein konzentriertes Arbeitswochenende plus ein paar hundert Euro für einen ASV-Scan die Anforderungen für die meisten kleinen Händler ab.

Wie die Buchhaltung ins Bild passt

PCI-Compliance ist nicht nur eine Sicherheitsübung – sie hat direkte Auswirkungen auf die Buchhaltung. Compliance-Kosten (SAQ-Tools, ASV-Scans, MFA-Hardware, Dienste zur Manipulationserkennung), Transaktionsgebühren, die je nach Compliance-Status variieren, sowie etwaige Bußgelder oder Sanierungskosten fließen alle in Ihre Bücher ein. Ebenso die Umsatzfolgen einer Sicherheitsverletzung: Rücklastschriften (Chargebacks), Rückerstattungen, von Ihrem Acquirer weitergegebene Neuausstellungsgebühren und entgangene Verkäufe während der Reaktion auf den Vorfall.

Eine saubere, positionsgenaue Buchführung für jede zahlungsbezogene Ausgabe – aufgeschlüsselt nach Zahlungsdienstleister, Sicherheitswerkzeugen und Compliance-Diensten – zahlt sich dreifach aus. Sie dokumentiert, dass Compliance-Investitionen getätigt werden (hilfreich bei Anfragen von Acquirern oder Versicherern). Sie macht die tatsächlichen Kosten jedes Akzeptanzkanals sichtbar, was Ihnen bei der Verhandlung von Gebühren hilft. Und falls es zu einer Sicherheitsverletzung kommt, bietet sie Ihrem forensischen Buchhalter eine klare Spur, um Schäden für die Versicherungsentschädigung zu quantifizieren.

Halten Sie Ihre Compliance-Unterlagen prüfungsbereit

Ganz gleich, ob Sie auf einen Fragebogen eines Acquirers, einen Cyber-Versicherungs-Underwriter oder einen forensischen Buchhalter nach einer Sicherheitsverletzung antworten: Händler, die PCI-Ereignisse gut überstehen, sind diejenigen, deren Bücher und Aufzeichnungen eine klare Geschichte erzählen. Beancount.io bietet textbasierte, versionsverwaltete Buchhaltung, die Ihnen einen transparenten, mit Zeitstempeln versehenen Pfad jeder Zahlungsabwicklungsgebühr, jedes Sicherheitswerkzeugs und jeder Compliance-Ausgabe bietet – keine Blackboxen, kein Vendor-Lock-in und bereit für das Zeitalter der KI-gestützten Finanzen. Starten Sie kostenlos und verbinden Sie Ihre Compliance-Arbeit mit einer Buchhaltung, die jeder Prüfung standhält.