PCI DSS erklärt: wie dein Checkout entscheidet, was du nachweisen musst

Die leichteste und sicherste PCI Position baust du dir selbst

Bevor es um Anforderungen, Stufen und Fragebögen geht, hier das Nützlichste, was dir ein Entwickler zur Kartensicherheit sagen kann. Wie viel PCI DSS auf dich zukommt, entscheidet vor allem, wie dein Checkout gebaut ist. Richte die Zahlung so ein, dass die Kartennummer direkt aus dem Browser der Kundin zu einem gehosteten, geprüften Zahlungsanbieter wandert und deine eigenen Server nie berührt, dann fällt der größte Teil des Standards einfach aus deinem Geltungsbereich heraus. Baust du stattdessen ein Kartenformular auf deinen eigenen Seiten, sodass die Nummer durch deine Systeme läuft, dann holst du dir das volle Gewicht des Standards ins Haus.

Das ist die ehrliche Überschrift. Aus dem PCI Geltungsbereich prüfst du dich nicht heraus, du baust dich heraus, und zwar an der Stelle, an der du entscheidest, wie der Zahlungsfluss funktioniert. Diese Entscheidung fällt meist lange bevor jemand das Wort Compliance erwähnt. Wie das genau geht, zeige ich weiter unten, denn dort steckt mein größter Mehrwert und dort wird das meiste Geld gespart oder verschwendet. Die Unternehmen in den Beispielen sind erfunden. Jede Tatsache über den Standard trägt eine Fußnote zu einer Primärquelle.

Was PCI DSS ist und wer dahintersteht

PCI DSS steht für Payment Card Industry Data Security Standard. Es ist eine Grundlinie technischer und organisatorischer Anforderungen zum Schutz von Zahlungskartendaten, und sie gilt für jede Organisation, die solche Daten speichert, verarbeitet oder überträgt oder deren Sicherheit beeinflussen kann.¹ Die aktuelle Fassung ist PCI DSS v4.0.1, veröffentlicht im Juni 2024.¹

Es ist kein staatliches Gesetz und kein Zertifikat für die Wand. Es ist ein Standard, geschrieben und gepflegt vom PCI Security Standards Council, einem Gremium, das 2006 von den fünf großen Kartenmarken gegründet wurde: American Express, Discover, JCB International, Mastercard und Visa, die zu gleichen Teilen daran beteiligt sind.² Der Council entwickelt den Standard, schult und listet die Prüfer und Scan Anbieter und veröffentlicht die begleitenden Dokumente. Über sich selbst sagt er klar, dass er die Umsetzung des Standards nicht überwacht.²

PCI DSS verstehst du also am besten als das eigene Regelwerk der Kartenbranche für den sicheren Umgang mit ihren Karten. Willst du Visa oder Mastercard akzeptieren, verpflichtest du dich irgendwo in der Vertragskette, es einzuhalten. Diese Kette ist das Nächste, das du verstehen solltest, denn sie gibt dem Standard seine Zähne.

Wer es durchsetzt: die Kartenmarken und deine Bank, nicht der Council

PCI DSS wird über Verträge durchgesetzt, nicht über ein Gesetz. Wenn du Kartenzahlungen annimmst, hast du eine Beziehung zu einer Acquiring Bank (deinem Acquirer, der Bank, die Kartenumsätze auf dein Konto abrechnet), und der Acquirer wiederum ist den Kartenmarken verpflichtet. Deine Pflicht, PCI DSS einzuhalten und das nachzuweisen, kommt aus diesen Verträgen.

Der Council stellt ausdrücklich klar, dass die Frage, ob ein bestimmtes Unternehmen überhaupt einhalten oder nachweisen muss, im Ermessen der Organisationen liegt, die die Compliance Programme betreiben, etwa einer Kartenmarke, eines Acquirers oder einer ähnlichen Stelle.² Der Standard selbst wiederholt das: Ob eine Einrichtung einhalten oder nachweisen muss, entscheiden die Organisationen, die die Compliance Programme führen, also die Kartenmarken und Acquirer, und du sollst sie nach den Kriterien fragen, die für dich gelten.¹

Das ist in der Praxis wichtig. Es gibt keinen PCI Inspektor, der an deiner Tür klingelt. Stattdessen verlangt dein Acquirer meist einmal im Jahr, dass du die Einhaltung bestätigst, oft über einen Selbsteinschätzungsfragebogen und, wo nötig, einen bestandenen Netzwerkscan. Erleidest du einen Vorfall mit Kartendaten, können die Marken über deinen Acquirer Strafen verhängen, und der Acquirer kann sie an dich weitergeben, deine Gebühren erhöhen oder dir am Ende die Kartenabwicklung entziehen. Die Durchsetzung ist kommerziell, und sie ist real.

Was als Kartendaten zählt

Der ganze Standard dreht sich um einen Begriff: Kontodaten. Der Standard teilt sie in zwei Arten.¹

Karteninhaberdaten sind die primäre Kontonummer (die lange Nummer auf der Vorderseite der Karte, meist als PAN abgekürzt) und daneben der Name der Karteninhaberin, das Ablaufdatum und der Servicecode. Sensible Authentifizierungsdaten sind das gefährlichere Material: die vollständigen Spurdaten vom Magnetstreifen oder Chip, der Kartenprüfwert (die drei oder vier Ziffern, die beweisen, dass die Karte vorliegt) und PINs sowie PIN Blöcke.¹

Die Regeln unterscheiden sich scharf. Karteninhaberdaten darfst du speichern, wenn du sie schützt, sensible Authentifizierungsdaten aber darfst du nach der Autorisierung einer Zahlung niemals speichern.¹ Die praktische Lehre für einen Entwickler ist nüchtern: Je weniger von diesen Daten deine Systeme überhaupt sehen, desto kleiner dein Problem. Jedes Feld, das du nicht anfassen musst, ist ein Feld, das du nicht schützen, protokollieren, verschlüsseln, scannen und dessen Schutz du nicht nachweisen musst.

Die sechs Ziele und die zwölf Anforderungen

PCI DSS ordnet seine Details unter sechs Zielen an, die zusammen zwölf grundlegende Anforderungen tragen. In v4.0.1 lauten sie so.¹

Ziel	Anforderungen
Ein sicheres Netzwerk und sichere Systeme aufbauen und erhalten	1. Netzwerksicherheitskontrollen installieren und pflegen. 2. Sichere Konfigurationen auf alle Systemkomponenten anwenden.
Kontodaten schützen	3. Gespeicherte Kontodaten schützen. 4. Karteninhaberdaten bei der Übertragung über offene, öffentliche Netze mit starker Kryptografie schützen.
Ein Programm zum Schwachstellenmanagement führen	5. Alle Systeme und Netze vor Schadsoftware schützen. 6. Sichere Systeme und Software entwickeln und pflegen.
Starke Zugriffskontrollen umsetzen	7. Zugriff auf Systemkomponenten und Karteninhaberdaten nach dem Prinzip der notwendigen Kenntnis beschränken. 8. Benutzer identifizieren und den Zugriff auf Systemkomponenten authentifizieren. 9. Den physischen Zugang zu Karteninhaberdaten beschränken.
Netze regelmäßig überwachen und testen	10. Jeden Zugriff auf Systemkomponenten und Karteninhaberdaten protokollieren und überwachen. 11. Die Sicherheit von Systemen und Netzen regelmäßig testen.
Eine Informationssicherheitsrichtlinie pflegen	12. Informationssicherheit mit organisatorischen Richtlinien und Programmen unterstützen.

Unter diesen zwölf Überschriften liegen Hunderte von Detailpunkten, aber die zwölf selbst haben sich im Kern seit Beginn des Standards nicht verändert. Als schlichte Technik gelesen beschreiben sie ein ordentlich geführtes System: ein Netz hinter einer Firewall, keine Standardpasswörter, verschlüsselte Daten bei der Übertragung, gepatchte Software, Zugriff nach dem Prinzip der minimalen Rechte, starke Authentifizierung, Protokolle, die jemand tatsächlich liest, regelmäßige Tests und schriftliche Richtlinien, die festhalten, wer was tut. Das meiste davon macht eine sorgfältige Umsetzung ohnehin. Die Kosten von PCI DSS sind selten die Ideen. Es ist der Nachweis, Kontrolle für Kontrolle, dass du sie umsetzt, und der Umfang dieses Nachweises hängt davon ab, wie viel von der Kartendatenumgebung dir gehört.

Die Händlerstufen eins bis vier

Die Kartenmarken sortieren Händler nach der Zahl der Kartentransaktionen pro Jahr in vier Stufen, und die Stufe legt fest, wie aufwändig du den Nachweis führen musst. Die Schwellen und die Nachweispflichten setzen die Marken, und die folgenden Zahlen sind die von Visa.³ Mastercard führt ein vergleichbares vierstufiges Schema.⁴

Stufe	Wen sie erfasst (Visa)	Erforderlicher Nachweis
1	Mehr als 6 Millionen Visa Transaktionen pro Jahr über alle Kanäle, oder jeder Händler, den Visa als Stufe 1 einstuft	Jährlicher Report on Compliance durch einen Qualified Security Assessor, ein vierteljährlicher Netzwerkscan durch einen Approved Scanning Vendor und eine Attestation of Compliance.
2	1 Million bis 6 Millionen Visa Transaktionen pro Jahr	Jährlicher Selbsteinschätzungsfragebogen, ein vierteljährlicher Scan durch einen Approved Scanning Vendor und eine Attestation of Compliance.
3	20.000 bis 1 Million Visa eCommerce Transaktionen pro Jahr	Jährlicher Selbsteinschätzungsfragebogen, ein vierteljährlicher Scan und eine Attestation of Compliance.
4	Weniger als 20.000 Visa eCommerce Transaktionen pro Jahr, und alle übrigen Händler bis 1 Million pro Jahr	Ein Selbsteinschätzungsfragebogen und, wo zutreffend, ein Scan, wobei die genaue Anforderung dein Acquirer festlegt.

Zwei Punkte lohnt es hervorzuheben. Erstens ist fast jedes kleine und mittlere Unternehmen ein Händler der Stufe 4, manchmal Stufe 3, was bedeutet, dass der übliche Weg ein Selbsteinschätzungsfragebogen ist und kein externer Prüfer. Zweitens kann dich ein schwerer Vorfall mit Kartendaten unabhängig vom Volumen eine Stufe hochsetzen, denn die Marken können dich nach einer Kompromittierung als Stufe 1 einstufen.³ Im PCI Sinn klein zu bleiben hängt also teils am Volumen und teils daran, keinen Vorfall zu haben.

Die SAQ Typen, und wie dein Checkout einen davon für dich auswählt

Das ist der Kern der Sache. Ein Selbsteinschätzungsfragebogen, kurz SAQ, ist das Formular, mit dem ein Händler ohne vollen externen Prüfbedarf die Einhaltung bestätigt. Es gibt mehrere Fassungen, und welche für dich infrage kommt, hängt fast ausschließlich davon ab, wie deine Zahlungen gebaut sind. Kurz gesagt: Je mehr Kartendaten deine eigenen Systeme berühren, desto länger und härter der Fragebogen. Die üblichen Typen sind diese.⁵

SAQ	Für wen er gilt	Ungefähre Größe
A	Händler ohne physische Karte (eCommerce oder Bestellung per Post und Telefon), die jede Verarbeitung von Kartendaten vollständig an geprüfte Dritte ausgelagert haben und deren eigene Systeme sie nie speichern, verarbeiten oder übertragen.	Am kleinsten.
A EP	eCommerce Händler, deren Website die Kartendaten nicht auf ihren eigenen Servern empfängt, deren Seiten die Sicherheit der Zahlung aber dennoch beeinflussen können, etwa ein Formular, das Kartendaten direkt an einen Anbieter schickt, aber mit Code, der von der Seite des Händlers geladen wird.	Deutlich größer als A.
B	Händler, die nur eigenständige Wählterminals oder Abdruckgeräte nutzen, ohne elektronische Speicherung von Kartendaten.	Klein, für den physischen Handel.
C	Händler mit einer mit dem Internet verbundenen Zahlungsanwendung, bei denen keine Kartendaten elektronisch gespeichert werden.	Mittel bis groß.
D	Jeder andere Händler, einschließlich aller, die Kartendaten elektronisch speichern. Der volle Standard.	Am größten.

Nun der technische Punkt, der das meiste Geld spart. Bei einem Onlineshop wird die Linie zwischen SAQ A und allem Schwereren von einer einzigen Entscheidung gezogen: Erreicht jemals eine rohe Kartennummer deine Server?

Übergibt dein Checkout die Kundin vollständig an den Anbieter, indem er auf dessen eigene gehostete Zahlungsseite weiterleitet oder dessen Zahlungsformular in einem iframe einbettet, sodass die Felder dem Anbieter gehören und nicht dir, dann wandern die Kartendaten von der Kundin direkt zu einem geprüften Dritten. Deine Server sehen sie nie. Das ist die SAQ A Position, die leichteste, und sie hält den weitaus größten Teil der technischen Anforderungen des Standards aus deinem Geltungsbereich heraus.

Baust du stattdessen die Kartenfelder in deine eigenen Seiten und berührt dein eigener Code die Nummer, bevor er sie weiterreicht, auch wenn du sie nie speicherst, dann beeinflusst deine Website jetzt die Sicherheit der Zahlung. Das ist die SAQ A EP Position, die einen großen Teil des Standards wieder auf deine Systeme zieht. Und speicherst du Kartennummern irgendwo, bist du bei SAQ D, dem Ganzen.

Ein Vorbehalt lohnt sich, weil er neu ist. Seit dem 1. April 2025 müssen sogar Händler mit einem eingebetteten Anbieterformular (einem iframe) bestätigen, dass ihre Seite nicht anfällig für Skripte ist, die die Zahlungsseite angreifen könnten, weshalb es nun selbst in den leichteren Fällen darauf ankommt, wie du die Skripte auf deinem Checkout verwaltest und überwachst.⁶ Die Richtung ist dieselbe wie die Überschrift: Halte die Zahlung von deinem eigenen Code fern und deine Checkout Seiten sauber.

Der Entscheidungsbaum ist kurz, und es lohnt sich, ihn vor der ersten Zeile Checkout Code vor Augen zu haben.

Erreicht jemals eine rohe Kartennummer deine Server? Wenn nein, bist du im SAQ A Bereich. Wenn ja, bist du mindestens bei SAQ A EP, wahrscheinlich mehr.
Speicherst du überhaupt Kartennummern? Wenn ja, bist du bei SAQ D, und die ehrliche Frage lautet: warum.
Könnte sich der Entwurf so ändern, dass beide Antworten nein werden? Meist ja, und das ist die Arbeit, die zuerst zu tun ist.

Wer prüft und testet

Drei Rollen umgeben den Nachweis, und keine davon bin ich.

Ein Qualified Security Assessor (QSA) ist eine Person oder Firma, die der Council geschult und lizenziert hat, um formale Prüfungen durchzuführen und den Report on Compliance zu schreiben, den ein Händler der Stufe 1 braucht.² Sie ist unabhängig von dir, aus demselben Grund wie ein Wirtschaftsprüfer: damit das Urteil etwas bedeutet.

Ein Approved Scanning Vendor (ASV) ist ein vom Council zugelassenes Unternehmen, das die externen Schwachstellenscans deiner zum Internet gewandten Systeme durchführt, die die meisten Stufen vierteljährlich verlangen.²

Für alle unterhalb von Stufe 1 ist das übliche Instrument der Selbsteinschätzungsfragebogen, den du selbst ausfüllst und unterschreibst, gestützt auf den Scan, wo er verlangt wird. In allen Fällen ist es dein Acquirer, der den Kartenmarken folgt und dir sagt, in welcher Stufe du bist, welcher SAQ gilt und welche Nachweise du schickst.²³ Ich kann die Systeme so bauen, dass die Antworten ehrlich sind und die Nachweise vorliegen, und ich kann dir helfen zu klären, für welchen SAQ dein Entwurf qualifiziert, aber ich setze die Anforderung nicht und ich bestätige die Einhaltung nicht. Diese Trennung ist Absicht, und es ist dieselbe Trennung, die ich in jedem Qualitätsstandard einhalte.

Was es kostet, und warum der Geltungsbereich der eigentliche Preis ist

PCI DSS hat keine eigene Gebühr. Der Council verlangt von Händlern nichts für die Einhaltung. Die Kosten sind alles drumherum: die Technik, um die Kontrollen zu erfüllen, etwaige Werkzeuge und Scans, das Honorar eines QSA, wenn du groß genug bist, um einen zu brauchen, und die Gebühren, die dein Acquirer ansetzt. Veröffentlichte Zahlen schwanken stark, weil sie ganz vom Geltungsbereich abhängen, also nimm diese als Planungsbereiche, nicht als Angebote.

Ein kleiner Onlineshop auf SAQ A, mit vollständig ausgelagerter Zahlung, kann für seine direkten PCI Kosten mit einigen Hundert bis einigen Tausend Euro im Jahr rechnen, vor allem für Scans und die Zeit zum Ausfüllen des Fragebogens.⁷ Ein Unternehmen, das SAQ D ausfüllt, mit Kartendaten im Geltungsbereich und oft einem QSA, ist in einer anderen Welt: Schätzungen von Anbietern für ein mittelgroßes SAQ D Programm mit einem QSA erreichen häufig den Bereich von mehreren Zehntausend, und ein Report on Compliance der Stufe 1 für einen großen Händler kann sechsstellig und mehr werden.⁷⁸ Ein viel zitierter Fachanbieter merkt an, dass der größte Hebel auf die Rechnung der Geltungsbereich ist: Ein Callcenter oder ein Speichersystem aus dem Geltungsbereich zu nehmen kann eine Prüfung um den Großteil ihrer Kosten senken.⁸

Das ist das ganze Argument in Geld. Der Unterschied zwischen SAQ A und SAQ D ist nicht in erster Linie der Fragebogen. Es sind die Technik, das Scannen, der mögliche Prüfer und der laufende Nachweis, und die Lücke dazwischen ist oft der Unterschied zwischen ein paar Tausend im Jahr und einem Programm, das eine eigene Budgetzeile braucht. Eine gehostete, tokenisierte Einbindung ist weniger aufwändig, weil sie von vornherein kleiner ist, nicht weil jemand gepfuscht hätte.

PCI DSS im Vergleich zu SOC 2 und ISO 27001

Diese drei werden verwechselt, und das Falsche zu kaufen verschwendet echtes Geld, also lohnt sich Genauigkeit. Sie beantworten verschiedene Fragen, und du kannst mehr als eines brauchen.

Standard	Was es ist	Was es abdeckt	Wer es dir gibt
PCI DSS	Ein Datensicherheitsstandard der Kartenbranche, durchgesetzt per Vertrag	Speziell Zahlungskartendaten: sie sicher speichern, verarbeiten und übertragen	Du bestätigst per SAQ, oder ein QSA schreibt einen Report on Compliance; dein Acquirer setzt die Anforderung
SOC 2	Ein Prüfbericht nach amerikanischen Rechnungslegungsstandards	Deine Kontrollen gegen gewählte Trust Services Kriterien, zum Lesen für eine Kundin	Eine lizenzierte Wirtschaftsprüfungsfirma, die du beauftragst
ISO 27001	Eine internationale Zertifizierung	Ob du ein anerkanntes Informationssicherheits Managementsystem betreibst	Eine akkreditierte Zertifizierungsstelle

PCI DSS ist schmal und tief: Es geht nur um Kartendaten, aber darüber ist es sehr vorschreibend. SOC 2 und ISO 27001 sind breiter und betreffen dein Sicherheitsmanagement als Ganzes. Ein SaaS Unternehmen, das an große oder amerikanische Käufer verkauft, wird meist nach einem SOC 2 Type II Bericht gefragt, ein europäischer Großkunde erwartet oft eine ISO 27001 Zertifizierung, ein Onlineshop mit Kartenzahlung braucht PCI DSS, was immer er sonst hält. Sie überschneiden sich in der Technik, bei Zugriffskontrolle, Verschlüsselung, Protokollierung und Tests, sodass einmal gut zu bauen bei allen hilft, aber keines ersetzt ein anderes. Wie das ganze Set zusammenpasst, lege ich in meiner Übersicht über die Qualitätsstufen für geschäftskritische Software dar, der richtige Startpunkt, wenn du nicht sicher bist, welches davon du wirklich brauchst.

Ein durchgerechnetes Beispiel: ein Linzer Shop, der auf SAQ A bleibt

Donaukost ist ein erfundenes Unternehmen in Linz mit 14 Mitarbeitenden und einem Umsatz von rund € 3 Millionen, das sein eigenes Sortiment an Kaffee und Küchenwaren auf donaukost.example verkauft. Es nimmt etwa 60.000 Kartenbestellungen im Jahr entgegen, alle online, also ist es nach den Visa Bändern ein Händler der Stufe 3 oder 4, und sein Acquirer erwartet einen jährlichen Selbsteinschätzungsfragebogen.³ Die Frage der Gründerin an mich ist einfach: welcher Fragebogen, und wie halten wir ihn klein?

Die Antwort entscheidet der Bau. Der Shop läuft auf Solidus, und der Checkout ist so verdrahtet, dass bei der Zahlung die Kartenfelder in einem iframe von einem geprüften Zahlungsanbieter geliefert werden, und am Handy wird die Kundin auf die gehostete Seite des Anbieters weitergeleitet. Kartennummer, Ablaufdatum und Prüfwert wandern vom Browser der Kundin zum Anbieter. Donaukosts eigene Server empfangen sie nie, protokollieren sie nie und speichern sie nie. Zurück kommt ein Token, eine bedeutungslose Referenz, mit der der Shop die Zahlung einziehen und Rückerstattungen auslösen kann, die aber für eine Diebin wertlos ist.

Weil keine Kartendaten die Systeme von Donaukost erreichen, ist der Shop für SAQ A berechtigt, den kürzesten Fragebogen.⁵ Die Arbeit, um dort zu bleiben, ist real, aber überschaubar. Ich bestätige, dass der Anbieter selbst PCI DSS geprüft ist, und lege seine Bestätigung ab, denn die Berechtigung von Donaukost ruht darauf. Ich sorge dafür, dass der Checkout überall die gehosteten Felder des Anbieters nutzt, ohne ein verirrtes Karteneingabefeld in Donaukosts eigenen Formularen. Ab April 2025 verwalte und überwache ich außerdem die Skripte auf der Checkout Seite, damit Donaukost ehrlich bestätigen kann, keinem Skriptangriff auf die Zahlung ausgesetzt zu sein, was SAQ A nun verlangt.⁶ Die jährliche Bestätigung an den Acquirer dauert dann einen Nachmittag, kein Projekt.

Stell dir den nicht gegangenen Weg vor. Hätte Donaukost ein eigenes Kartenformular im Hausdesign gebaut und die Nummern durch sein eigenes Backend geschickt, um das Erlebnis zu steuern, dann wäre es auf SAQ A EP gefallen, mit einem weit längeren Fragebogen, externem Scannen seiner Zahlungssysteme und einer echten laufenden Compliance Last, alles für Daten, die es nie hätte halten müssen. Das durch den gehosteten Entwurf gesparte Geld ist kein Rabatt. Es ist Geltungsbereich, der nie entstanden ist.

Wie ich dafür baue

Meine Aufgabe hier ist klar umrissen, und ich halte sie ehrlich. Ich entwerfe und baue die Zahlungseinbindung so, dass der Kartendatenbereich des Händlers so klein wie möglich ist, was in fast jedem Onlineshop einen gehosteten oder tokenisierten Checkout bedeutet, der rohe Kartennummern vollständig von den Servern des Händlers fernhält und das Unternehmen auf SAQ A bringt. Diese eine Entscheidung, am Anfang getroffen, tut mehr für die PCI Position eines Shops als jede spätere Papierarbeit.

Darum herum baue ich die gewöhnlichen Kontrollen, die der Standard beschreibt, denn sie sind gute Technik, egal wie: starke Authentifizierung auf jedem Admin Pfad und der Hosting Konsole, minimale Rechte in der Solidus oder Rails Verwaltung, Verschlüsselung bei jeder Verbindung, gepatchte Abhängigkeiten, zentrale Protokolle, die ein Mensch liest, und ein schriftliches Vorgehen bei Vorfällen statt guter Absichten. Jedes System, das ich ausliefere, bekommt vor dem ersten Kontakt mit dem Internet einen Penetrationstest mit dem Kali Linux Werkzeugkasten, mit Werkzeugen wie Nmap, Burp Suite und OWASP ZAP, und die Funde werden nach Schwere und Behebung dokumentiert. Dieser Nachweis, und der saubere, tokenisierte Zahlungsentwurf dahinter, ist genau das, wofür ein Selbsteinschätzungsfragebogen dich einstehen lässt.

Was ich nicht tue, ist deine Einhaltung zu prüfen oder zu zertifizieren, denn das kann und soll ich nicht. Dein Acquirer, den Kartenmarken folgend, setzt, welche Stufe und welcher SAQ gelten, und für einen großen Händler schreibt ein unabhängiger Qualified Security Assessor den Report on Compliance.²³ Ich baue die Einbindung, die die ehrliche Antwort klein macht, und ich bereite dich auf die Bestätigung vor. Diese Rollen getrennt zu halten ist das, was mein Wort zu deiner Sicherheit überhaupt etwas wert macht.

Was jetzt zu tun ist

Arbeite diese der Reihe nach ab.

Finde bei deinem Acquirer heraus, welche Händlerstufe du bist und welchen SAQ er erwartet. Die Anforderung zu setzen ist seine Sache.
Schau dir an, wohin Kartennummern in deinem Checkout heute tatsächlich gehen. Erreicht eine davon deine eigenen Server, ist das das Erste, was sich ändern muss.
Wechsle zu einem gehosteten oder tokenisierten Zahlungsentwurf, falls noch nicht geschehen, damit der Shop für SAQ A berechtigt ist und der größte Teil des Standards deinen Geltungsbereich verlässt.
Lege die eigene PCI DSS Prüfung deines Zahlungsanbieters ab, denn dein leichtester Fragebogen hängt davon ab.
Verwalte die Skripte auf deinen Checkout Seiten, was SAQ A nun erwartet, und baue die gewöhnlichen Kontrollen der zwölf Anforderungen in den Rest des Systems.
Erst dann füll den Fragebogen aus, mit den Nachweisen bereits vorhanden statt in Panik zusammengesucht.

PCI DSS wirkt von außen schwer, und für ein Unternehmen, das Kartendaten speichert, ist es das. Für die meisten Onlineshops muss es das nicht sein, und der Weg, es leicht zu machen, ist eine Entwurfsentscheidung, die du vor dem Schreiben des Checkouts triffst, kein Zertifikat, dem du danach nachjagst.

Du bist nicht sicher, für welchen SAQ dein Shop qualifiziert, oder ob dein Checkout leise Kartendaten in einen Geltungsbereich zieht, den er nicht braucht? Buch den kostenlosen Workshop, und ich geh es mit dir durch. Die ersten zwei Wochen Arbeit gehen auf meine Rechnung.

PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1, Juni 2024, Abschnitte zur Anwendbarkeit, die zwölf Anforderungen (Table 1) und Kontodaten (Table 2), verfügbar über die PCI SSC Document Library, https://www.pcisecuritystandards.org/document_library/?category=pcidss ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
PCI Security Standards Council, About us (Governance, Gründungsmitglieder und die Rolle des Council, einschließlich dass er die Umsetzung der Standards nicht überwacht und die Nachweispflicht im Ermessen der Kartenmarken und Acquirer liegt), pcisecuritystandards.org, abgerufen am 13. November 2026, https://www.pcisecuritystandards.org/about_us/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Visa, PCI DSS compliance validation and merchant levels (Transaktionsschwellen für die Stufen 1 bis 4 und der jeweils verlangte Nachweis), visa.com, abgerufen am 13. November 2026, https://www.visa.com.tt/run-your-business/small-business/information-security/compliance-validation.html ↩ ↩² ↩³ ↩⁴ ↩⁵
Mastercard, Security recommendations, what merchants need to know (Mastercard Händlerstufen), mastercard.com, abgerufen am 13. November 2026, https://www.mastercard.us/en-us/business/overview/safety-and-security.html ↩
PCI Security Standards Council, Self Assessment Questionnaire Instructions and Guidelines (die SAQ Typen und ihre Berechtigungskriterien), verfügbar über die PCI SSC Document Library, abgerufen am 13. November 2026, https://www.pcisecuritystandards.org/document_library/?category=saqs ↩ ↩²
PCI Security Standards Council, FAQ clarifies new SAQ A eligibility criteria for eCommerce merchants (das Kriterium zum Skriptschutz und das Inkrafttreten am 1. April 2025), PCI Perspectives Blog, abgerufen am 13. November 2026, https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants ↩ ↩²
Scrut Automation, Calculating your actual PCI compliance cost (jährliche Kostenbereiche für Händler der Stufe 4, die per SAQ nachweisen), scrut.io, abgerufen am 13. November 2026, https://www.scrut.io/post/calculating-your-actual-pci-compliance-cost-expert-guide-for-2026 ↩ ↩²
Paytia, The cost of PCI compliance (Kostenbereiche nach Händlerstufe und SAQ und die Wirkung einer Verkleinerung des Geltungsbereichs), paytia.com, abgerufen am 13. November 2026, https://www.paytia.com/us/resources/blog/cost-of-pci-compliance ↩ ↩²