PCI DSS fuer ein Kleinanzeigenportal fuer Erwachsene: was wirklich ueber den Aufwand entscheidet
Einen Zahlungsdienstleister davon zu ueberzeugen, ein Kleinanzeigenportal fuer Erwachsene zu akzeptieren, ist schon ein eigener Kampf, und wenn er gewonnen ist, glauben die meisten Betreiber, der schwierige Teil sei vorbei. Das stimmt nicht. Das Konto, das schliesslich zusagt, bringt eine dauerhafte Pflicht mit sich, die nichts mit Altersverifikation, Moderation oder irgendeiner Regel zu tun hat, die ein Staat oder eine Suchmaschine auferlegen koennte. Es ist ein Sicherheitsstandard, den die Kartennetzwerke selbst geschrieben haben, und er gilt, sobald eine Kartennummer irgendeinen Teil des Geschaefts beruehrt, egal wie klein dieses Geschaeft ist.
Was folgt, ist keine Rechtsberatung, und wer wirklich mit echten Kartendaten arbeitet, sollte den eigenen Fall von einem Qualified Security Assessor pruefen lassen. Es ist die Form einer Entscheidung, die kaum ein Betreiber ueberhaupt als solche wahrnimmt, weil sie meist ein Entwickler trifft, der eine schoenere Zahlungsseite bauen will, lange bevor die Frage die geschaeftliche Seite des Unternehmens erreicht.
Die Regel, die Sie unterschrieben haben, ohne sie zu lesen
PCI DSS, der Datensicherheitsstandard der Kartenzahlungsindustrie, ist kein staatliches Gesetz, und keine Behoerde setzt ihn durch. Es ist eine vertragliche Pflicht, die in der Vereinbarung steht, die jeder Haendler mit einer Acquiring-Bank oder einem Zahlungsdienstleister unterschreibt, und sie existiert, weil Visa, Mastercard und die anderen Netzwerke von ihren Acquirern verlangen, sie an jedes Unternehmen weiterzugeben, das eine Kartennummer speichert, verarbeitet oder uebertraegt. Die Standardorganisation selbst ist eindeutig: Er gilt fuer jede Stelle, die Kartendaten verarbeitet, egal ob direkt oder ueber Dritte, ohne Ausnahme fuer Groesse oder Transaktionsvolumen.
Das ist eine andere Frage als die, die ein Zahlungsdienstleister stellt, bevor er ein Konto eroeffnet. Was ein Zahlungsdienstleister wissen will, bevor er sich auf die Zusammenarbeit einlaesst, betrifft das Geschaeft selbst: wem es gehoert, wie Anzeigen geprueft werden, wie Inserenten verifiziert werden. PCI DSS beginnt, nachdem dieses Konto existiert, und hoert eigentlich nie wirklich auf. Es wird jedes Jahr erneuert, solange das Geschaeft Karten akzeptiert, und es aendert seine Form, sobald sich die Art aendert, wie Karten angenommen werden.
Das Transaktionsvolumen spielt tatsaechlich eine Rolle, nur nicht so, wie man annimmt. Es legt eine Haendler-"Stufe" fest, von eins bis vier, und diese Stufe entscheidet, wie die Konformitaet bestaetigt wird: Ein kleiner Betreiber fuellt einen Selbstbewertungsfragebogen aus, waehrend ein Unternehmen mit Millionen Transaktionen im Jahr einen externen Pruefer braucht. Was das Volumen nicht tut, ist, irgendjemanden auszunehmen. Ein Hochrisiko-Haendler mit ein paar hundert Transaktionen im Monat unterliegt genau demselben zugrunde liegenden Standard wie eine grosse Kette, nur mit einem kuerzeren Formular geprueft.
Die eine Entscheidung, die den Aufwand fuer Jahre festlegt
Welches Formular fuer ein bestimmtes Geschaeft gilt, laesst sich nicht frei waehlen. Es wird vollstaendig durch eine technische Tatsache bestimmt: Laeuft die Kartennummer an irgendeinem Punkt durch ein System, das der Betreiber kontrolliert. Schickt man den Kunden auf eine vom Zahlungsdienstleister gehostete Zahlungsseite oder bindet man ein korrekt isoliertes Zahlungs-Iframe ein, das dieser Dienstleister bereitstellt, beruehrt die Kartennummer nie den eigenen Server des Betreibers. Baut man stattdessen ein Zahlungsformular, das die Kartennummer erfasst und, wenn auch nur kurz, an das eigene Backend schickt, bevor es weitergeleitet wird, beruehrt sie ihn sehr wohl.
Diese einzige Tatsache trennt den leichtesten Fragebogen vom schwersten um eine ganze Groessenordnung. Der vollstaendig ausgelagerte Weg, bekannt als SAQ A, umfasst rund zwanzig Anforderungen. Der Weg, bei dem die eigene Seite des Betreibers einen Teil des Zahlungsprozesses liefert oder beeinflusst, auch ohne die Kartennummer direkt zu beruehren, etwa ein selbst gehostetes Formular, dessen Felder die Daten weiterleiten, landet bei SAQ A-EP, nahe zweihundert Anforderungen. Kartendaten tatsaechlich auf eigenen Systemen zu speichern, zu verarbeiten oder zu uebertragen, landet bei SAQ D, das den vollstaendigen Satz an Kontrollen des Standards abdeckt: Verschluesselung, Schluesselverwaltung, Netzwerksegmentierung, Protokollierung, Zugriffskontrolle, alles, mehrere hundert Punkte.
Es lohnt sich, ein verbreitetes Missverstaendnis gleich auszuraeumen. Ein Iframe eines konformen Anbieters zu verwenden, laesst eine Website nicht automatisch in die schwerere Stufe SAQ A-EP fallen: Ein korrekt isoliertes Drittanbieter-Iframe, bei dem die eigene Seite des Betreibers keinen Code beisteuert, der die Zahlungsfelder sehen oder beruehren kann, qualifiziert sich meist weiterhin fuer den leichten Weg SAQ A. Was ein Geschaeft eine Stufe hochstuft, ist eigener Code des Betreibers, der in diese Seite hineinreicht, sei es ein selbst gebautes Formular, ein Skript, das hinzugefuegt wurde, um die Zahlung zu "verbessern", oder eine altmodische Integration, bei der der Browser Kartendaten ueber Code sendet, den der Betreiber geschrieben hat statt der Zahlungsdienstleister.
Was der leichte Weg seit letztem Jahr weiterhin verlangt
Es lohnt sich, eine Annahme zu korrigieren, die frueher stimmte und es nicht mehr tut. Betreiber, die den ausgelagerten Weg gewaehlt haben, lernten zu Recht, dass sie damit aus dem groessten Teil der technischen Last des Standards heraus waren, und manche glauben immer noch, das bedeute gar keine laufende Sicherheitspruefung. Seit PCI DSS Version 4.0.1, durchsetzbar seit April 2025, stimmt das nicht mehr. SAQ A enthaelt jetzt eine Anforderung fuer vierteljaehrliche externe Schwachstellenscans durch einen Approved Scanning Vendor, durchgefuehrt gegen die eigene Website des Betreibers, also die, die die Weiterleitung oder das Iframe hostet, auch wenn diese Website selbst nie eine Kartennummer sieht.
Die Logik hinter der Aenderung ist einfach, sobald man sie ausspricht: Die Seite, die den Kunden zum Zahlungsdienstleister schickt, gehoert immer noch zur Angriffsflaeche. Eine kompromittierte Zahlungsseite kann einen Kunden woanders hinleiten als zum echten Zahlungsdienstleister, oder ein boesartiges Skript laden, das Kartendaten direkt aus dem Browser liest, noch bevor das Iframe ueberhaupt laedt, ein Angriffsmuster, das echte Haendler bereits getroffen hat. Aus derselben Logik folgen zwei verwandte Anforderungen: Der Betreiber muss ein Inventar jedes Skripts fuehren, das auf der Zahlungsseite laeuft, und nicht autorisierte Aenderungen am Inhalt dieser Seite erkennen, Pflichten, die in SAQ A genau deshalb gelten, weil die Zahlungsseite dem Betreiber gehoert, auch wenn die Kartennummer selbst nie ihm gehoert hat.
Was der leichte Weg weiterhin vermeidet, und das ist die Luecke, die wirklich zaehlt, ist der jaehrliche Penetrationstest, den SAQ A-EP und SAQ D verlangen, zusammen mit den tiefgreifenden internen Kontrollen, die diese Stufen erfordern: gespeicherte Kartendaten verschluesseln, die Schluessel verwalten, die sie schuetzen, das Netzwerk um jedes System herum segmentieren, das sie beruehrt, und jeden Zugriff im Detail protokollieren. Den ausgelagerten Weg zu waehlen bedeutet nicht, gar keine Sicherheitsarbeit zu leisten. Es bedeutet ein paar Stunden Scannen und Skript-Hygiene im Jahr statt eines dauerhaften Sicherheitsprogramms rund um Daten, die das Geschaeft sonst selbst speichern wuerde.
Was es kostet, das falsch zu machen
Nichts davon wird von einem Gericht oder einer Behoerde durchgesetzt, und genau das macht es leicht zu unterschaetzen. Die Netzwerke bestrafen die Acquiring-Bank, wenn ein Haendler in ihrem Portfolio nicht konform ist, und der Acquirer reicht diese Kosten ueber den Vertrag direkt an den Haendler weiter, meist beginnend mit bescheidenen Betraegen, die steigen, je laenger die Nichtkonformitaet andauert. Es gibt keine oeffentliche Tabelle, die diese Betraege fuer jeden Acquirer festlegt, weil die Vereinbarung in privaten Vertraegen steckt und nicht in oeffentlichen Regeln, aber die Richtung ist konstant: Die Strafe waechst mit der Zeit, nicht damit, wie gut das Geschaeft die Verzoegerung erklaert.
Das ist der Preis dafuer, einfach nicht konform zu sein. Ein tatsaechlicher Sicherheitsvorfall, bei dem gespeicherte Kartennummern offengelegt werden, weil ein Betreiber Daten verarbeitet hat, die SAQ A ihm gerade ersparen sollte, ist eine Ausgabe ganz anderer Groessenordnung. Die Netzwerke koennen eine forensische Untersuchung durch eine spezialisierte Firma verlangen, bevor irgendjemand das Konto wieder oeffnen darf, bezahlt vom Haendler unabhaengig vom Ergebnis, und die betroffenen Karten werden auf Kosten des Haendlers neu ausgestellt. Eine Cyber-Haftpflichtversicherung schliesst diese Luecke fuer ein Geschaeft wie dieses nur selten, da Inhalte fuer Erwachsene bei mehr als einem grossen Versicherer auf der Liste der ausgeschlossenen Branchen der Cyber-Police stehen, was bedeutet, dass das hier beschriebene Risiko sehr oft nicht versichert ist und nicht nur teuer.
Die dauerhafteste Folge ist weder die Strafe noch die Untersuchung. Es ist die Entscheidung des Acquirers, sobald ein Sicherheitsvorfall oder eine anhaltende Nichtkonformitaet aktenkundig ist, das Konto zu schliessen statt das Risiko weiter zu tragen, und diese Schliessung so zu erfassen, dass andere Acquirer sie sehen koennen, bevor sie ein neues eroeffnen. Eine Zahlungsbeziehung, die beim ersten Mal Monate zum Aufbau brauchte, ist mit dieser Vorgeschichte am Geschaeft deutlich schwerer wieder aufzubauen.
Was diesen Monat zu tun ist
Finden Sie zunaechst schriftlich heraus, welcher Fragebogen heute wirklich gilt. Fragen Sie direkt beim Zahlungsdienstleister nach, statt die Antwort anzunehmen: Bestaetigen Sie, ob die aktuelle Zahlungsseite eine Weiterleitung, ein korrekt isoliertes Iframe oder etwas ist, das den eigenen Server des Betreibers an irgendeinem Punkt beruehrt, denn die Antwort auf diese Frage ist das gesamte Compliance-Programm in einem Satz. Lassen Sie sich das per E-Mail bestaetigen, nicht am Telefon, denn das ist der Bezugspunkt fuer jede folgende Entscheidung.
Behandeln Sie jede Anfrage, die Art der Kartenerfassung zu aendern, zuerst als Compliance-Frage und erst dann als Gestaltungsfrage. Ein Entwickler, der ein massgeschneidertes Zahlungsformular bauen will, weil die gehostete Seite generisch wirkt, oder der einen Chat oder ein Analyse-Skript auf derselben Seite hinzufuegt, die das Zahlungs-Iframe hostet, trifft eine PCI-Entscheidung, ganz gleich, ob jemand es so nennt. Pruefen Sie eine solche Aenderung, bevor sie live geht, nicht nachdem ein Scan sie meldet.
Reichen Sie die jaehrliche Bestaetigung fristgerecht ein und bewahren Sie die Ergebnisse jedes vierteljaehrlichen Scans auf, auch die langweiligen, bei denen sich nichts aendert, denn eine abgelaufene Bestaetigung liest sich in den Augen eines Acquirers genauso, als haette man sie nie eingereicht. Nichts davon ist schwierig, wenn die zugrunde liegende Architektur stimmt. Eine Zahlung, die von Anfang an um eine gehostete Seite oder ein korrekt isoliertes Iframe herum aufgebaut ist, macht daraus einen Nachmittag Papierkram, einmal jaehrlich wiederholt. Eine Zahlung, die sich still und leise angewoehnt hat, Kartendaten zu beruehren, macht aus derselben Pflicht ein dauerhaftes Sicherheitsprogramm, das das Geschaeft nie zu betreiben geplant hatte.
