PCI DSS 4.0: die Kartendatenregeln und wen sie binden

PCI DSS schützt Karteninhaberdaten: Kartennummer, Ablaufdatum, Name des Inhabers und die dahinterliegenden Authentifizierungsdaten. Er bindet jeden, der diese Daten speichert, verarbeitet oder überträgt, also Händler, Acquirer, Abwickler, Facilitatoren und jeden Dienstleister dazwischen, und er reicht auch auf die damit verbundenen Systeme.

Ein Gesetz ist er nicht. Keine Aufsicht verhängt ein PCI-Bußgeld, die Pflicht kommt über den Akzeptanzvertrag. Das Council selbst weist darauf hin, dass die durchsetzende Stelle bestimmt, wer was nachweisen muss, also System, Acquirer oder Payment Facilitator; deshalb treffen zwei ähnlich große Händler auf unterschiedliche Nachweispflichten. Die regulierten Pflichten daneben behandelt Finance Loop unter DORA in Deutschland.

Version 4.0 behielt die zwölf Anforderungsbereiche und änderte den Weg dorthin. Die größte Ergänzung ist der individuelle Ansatz: Statt die Maßnahme wie beschrieben umzusetzen, darf eine Organisation das genannte Ziel auf eigenem Weg erreichen, begründen, warum ihre Methode das Ziel erreicht, und diese Begründung von einem Prüfer bestätigen lassen. Dieser Weg kostet mehr Arbeit, nicht weniger, und er ist für erfahrene Sicherheitsteams gedacht, deren Maßnahmen dem vorgegebenen Wortlaut nicht entsprechen.

Der Rest der Änderung verschiebt das Gewicht von der Behauptung zum Nachweis. Die Authentifizierungsanforderungen wurden strenger, darunter Mehrfaktorzugriff auf die Kartendatenumgebung. Mehrere Maßnahmen verlangen nun eine zielgerichtete Risikoanalyse, die die Häufigkeit einer Tätigkeit aus der eigenen Risikobewertung ableitet statt aus einem festen Intervall. Version 4.0.1 folgte als Pflegeausgabe, die 4.0 korrigiert und klarstellt, und sie ist die zu zitierende Fassung.

Zwei davon gelten seit dem 31. März 2025 nach einer Übergangszeit, und beide betreffen das Geschehen im Browser. Anforderung 6.4.3 betrifft die auf einer Zahlungsseite geladenen Skripte: Jedes ist zu inventarisieren, braucht eine schriftliche fachliche Begründung, muss von einer benannten Stelle ausdrücklich freigegeben sein und laufend auf Integrität geprüft werden, auch die Skripte von Dritten. Anforderung 11.6.1 verlangt einen Mechanismus, der unbefugte Änderungen an der Zahlungsseite erkennt, wie der Browser des Kunden sie erhält. Anforderung 12.3.1 betrifft die zielgerichtete Risikoanalyse zu 11.6.1.

Der Angriff dahinter erklärt die Fristen. Ein in eine Checkout-Seite eingeschleustes Skript, meist über einen Tag-Manager oder einen Analysedienst, liest die Kartennummer bei der Eingabe mit und schickt sie fort, und auf dem Server des Händlers sieht nichts verdächtig aus. Jedes Marketing- oder Analyse-Tag auf einer Seite, die Kartendaten aufnimmt, fällt nach dieser Logik unter 6.4.3.

Der kleinste Fragebogen wurde im selben Monat umgebaut. Das Council entfernte die Anforderungen 6.4.3, 11.6.1 und 12.3.1 aus SAQ A und setzte eine Zugangsvoraussetzung an ihre Stelle: Der Händler muss bestätigen, dass seine Seite nicht für Skriptangriffe anfällig ist, die seine E-Commerce-Systeme treffen könnten. Die Fassung vom Januar 2025 gilt seit dem 31. März 2025, mit dem die Fassung vom Oktober 2024 auslief.

Lesen Sie den Tausch genau, bevor Sie ihn für Entlastung nehmen. Die drei Anforderungen verließen den Fragebogen und blieben im Standard, gelten also weiter für Händler mit SAQ D oder einer Prüfung vor Ort, und die neue Zugangsvoraussetzung verlangt eine Erklärung über genau das Ergebnis, das die entfernten Anforderungen erzeugen sollten. Adyens Leitfaden zu den Voraussetzungen nennt die andere Bedingung für SAQ A: Jedes Element der Zahlungsseite und des Formulars im Browser des Kunden muss ausschließlich und unmittelbar von einem konformen Drittanbieter oder Abwickler kommen.

Die Antwort folgt aus der Anbindung, nicht aus der Unternehmensgröße. Ein Checkout, der den Kunden zum Anbieter weiterleitet oder dessen eigenen Iframe einbettet, hält die Kartennummer aus der Seite des Händlers heraus und führt zu SAQ A. Eine Händlerseite, die die Karte in eigenen Feldern aufnimmt und weiterschickt, auch ohne zu speichern, landet im deutlich längeren SAQ A-EP. Wer Kartennummern irgendwo speichert oder auf eigenen Systemen verarbeitet, ist in SAQ D.

Das Transaktionsvolumen bestimmt den Nachweis, nicht den Fragenkatalog. Die Systeme teilen Händler nach Jahrestransaktionen in Stufen ein, und die höchste Stufe verlangt eine Prüfung vor Ort durch einen qualifizierten Sicherheitsprüfer statt einer Selbstauskunft. Fragen Sie Ihren Acquirer schriftlich, in welcher Stufe er Sie führt und welchen Fragebogen er erwartet, denn dieses Paar bestimmt die Kosten der ganzen Übung.

Der günstigste Weg zu einer Anforderung ist, ihr nicht zu unterliegen. Wird die Kartennummer in Feldern aufgenommen, die der Anbieter ausliefert und steuert, und erhält Ihr System immer nur einen Token, dann halten Datenbank, Protokolle, Backups und Supportwerkzeuge keine Karteninhaberdaten und liegen außerhalb der Prüfung. Das ist das ganze Argument für Fremdfelder oder eine Weiterleitung.

Zwei Fehler heben es auf. Eine Seite, die die Felder des Anbieters ausliefert und daneben eigene Skripte in dieselbe Seite lädt, holt diese Skripte zurück in den Umfang, und genau darum geht es in 6.4.3. Und ein Token liegt nicht automatisch außerhalb: Hält der Händler etwas, das sich in eine Kartennummer zurückrechnen lässt, oder das Schlüsselmaterial dafür, sind die Daten weiter da. Die Speicherfrage behandelt Finance Loop unter Payment Orchestration, die Acquirer-Seite unter Acquiring.

Ein deutsches Zahlungsinstitut antwortet inzwischen auf beides, und beide fragen Unterschiedliches über dieselben Systeme. PCI DSS schützt einen Datentyp über die Umgebung, die ihn berührt, und die durchsetzende Stelle ist ein Vertragspartner. DORA regelt die operationale Widerstandsfähigkeit des ganzen beaufsichtigten Unternehmens, und die durchsetzende Stelle ist die BaFin.

Die Überschneidung ist praktisch, nicht rechtlich. Bestandsverzeichnisse, Schwachstellenmanagement, Zugriffssteuerung, Vorfallbehandlung und Auslagerungsaufsicht stehen in beiden, die Nachweise lassen sich also einmal erzeugen und zweimal vorlegen, wenn die Dokumentation darauf gebaut ist. Zwei Dinge übertragen sich nicht: Die DORA-Meldung geht an die Aufsicht mit regulatorischen Fristen, und der PCI-Umfang ist enger als der von DORA, ein DORA-Programm weist also keine PCI-Konformität für die Kartendatenumgebung nach. Das Resilienzregime behandelt Finance Loop unter DORA in Deutschland, das weitere Feld unter Cybersicherheit im Finanzwesen.

Inhaltlich nichts. Version 4.0.1 ist eine begrenzte Überarbeitung, die Fehler korrigiert und Formulierungen in 4.0 klarstellt; sie brachte keine neuen Anforderungen und verschob keine Fristen. Wer auf 4.0 hinarbeitet, arbeitet auf 4.0.1 hin, und 4.0.1 ist die Fassung, die in ein Dokument oder einen Vertrag gehört.

Nein, und der Unterschied zählt weniger, als er klingt. Den Standard setzen die Kartensysteme und sie setzen ihn über Verträge durch, die Folgen eines Verstoßes sind also kaufmännisch: Nachweisforderungen, vom Acquirer weitergegebene Strafen und im schweren Fall der Verlust der Kartenakzeptanz. Ein Vorfall mit Kartendaten löst zusätzlich die Pflichten aus, die Gesetz sind, darunter die Meldung nach der Datenschutz-Grundverordnung, weshalb aus einem solchen Vorfall zwei getrennte Verfahren werden.