Das Wichtigste in Kürze (Stand: Oktober 2026)
- PCI DSS ist ein Branchenstandard des PCI Security Standards Council, kein Gesetz; verbindlich wird er über Verträge mit Acquirern und Kartenorganisationen.
- Aktiv ist allein Version 4.0.1 vom 11. Juni 2024; Version 4.0 wurde am 31. Dezember 2024 zurückgezogen.
- Die mit Version 4.0 eingeführten zukunftsdatierten Anforderungen sind seit dem 31. März 2025 verpflichtend, etwa die Kontrolle von Skripten auf Zahlungsseiten (6.4.3).
- Ein Zertifikat stellt das Council nicht aus; nachgewiesen wird per Selbstbewertungsfragebogen (SAQ) oder Prüfbericht (ROC), jeweils mit Konformitätsbestätigung (AOC).
Was ist PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) ist der Sicherheitsstandard der Kartenzahlungsbranche zum Schutz von Kontodaten, also von Karteninhaberdaten und sensiblen Authentifizierungsdaten. Herausgeber ist das PCI Security Standards Council, das den Standard entwickelt und pflegt, seine Einhaltung aber nicht selbst überwacht.
Für wen gilt PCI DSS?
PCI DSS gilt für jede Organisation, die Kartendaten speichert, verarbeitet oder überträgt, und für jede, deren Umgebung die Sicherheit dieser Daten beeinträchtigen kann. Das Council nennt ausdrücklich Händler, Zahlungsabwickler, Acquirer, kartenausgebende Institute und sonstige Dienstleister.
Karteninhaberdaten und sensible Authentifizierungsdaten
Geschützt werden zwei Gruppen von Daten, die PCI DSS zusammen als Kontodaten (account data) bezeichnet:
| Datengruppe | Bestandteile | Was gilt |
|---|---|---|
| Karteninhaberdaten (cardholder data) | Kartennummer (PAN), Name des Karteninhabers, Ablaufdatum, Service-Code | Dürfen gespeichert werden, wenn sie geschützt sind. Bestimmendes Merkmal ist die PAN: Die übrigen Angaben fallen unter den Schutz, sobald sie zusammen mit ihr vorliegen. |
| Sensible Authentifizierungsdaten (sensitive authentication data) | Vollständige Magnetstreifen- oder Chipdaten, Kartenprüfnummer, PIN und PIN-Block | Dürfen nach der Autorisierung nicht gespeichert werden, auch nicht verschlüsselt (Anforderung 3.3.1). |
Wer Zahlungsvorgänge an einen Dienstleister auslagert, bleibt nach dem Standard dafür verantwortlich, dass der Dienstleister die Kontodaten nach den anwendbaren Anforderungen schützt.
PCI DSS in Deutschland: vertragliche, keine gesetzliche Pflicht
PCI DSS ist ein Branchenstandard, keine Norm einer staatlichen Stelle. Ob eine Organisation den Standard einhalten und dies nachweisen muss, entscheiden nach Angaben des Councils die Stellen, die Compliance-Programme führen, also Kartenorganisationen und Acquirer. Für Händler entsteht die Pflicht deshalb über den Akzeptanzvertrag mit dem Acquirer oder Zahlungsdienstleister.
Unabhängig davon gilt die Verordnung (EU) 2016/679 (DSGVO), Art. 32. Kartendaten mit Bezug zu einer Person sind personenbezogene Daten, und Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen für ein dem Risiko angemessenes Schutzniveau. Steht eine Anforderung aus PCI DSS im Widerspruch zu nationalem Recht, geht nach dem Standard das Recht vor.
Die 12 Hauptanforderungen von PCI DSS
PCI DSS gliedert sich in 12 Hauptanforderungen, die sechs Zielen zugeordnet sind.
| Ziel | Nr. | Hauptanforderung (sinngemäß) |
|---|---|---|
| Sicheres Netz und sichere Systeme | 1 | Netzwerksicherheitskontrollen einrichten und pflegen |
| Sicheres Netz und sichere Systeme | 2 | Alle Systemkomponenten sicher konfigurieren |
| Schutz der Kontodaten | 3 | Gespeicherte Kontodaten schützen |
| Schutz der Kontodaten | 4 | Karteninhaberdaten bei Übertragung über offene, öffentliche Netze stark verschlüsseln |
| Schwachstellenmanagement | 5 | Systeme und Netze vor Schadsoftware schützen |
| Schwachstellenmanagement | 6 | Sichere Systeme und Software entwickeln und pflegen |
| Zugriffskontrolle | 7 | Zugriff auf Systeme und Karteninhaberdaten auf das geschäftlich Notwendige beschränken |
| Zugriffskontrolle | 8 | Benutzer identifizieren und Zugriffe authentifizieren |
| Zugriffskontrolle | 9 | Physischen Zugang zu Karteninhaberdaten beschränken |
| Überwachung und Tests | 10 | Alle Zugriffe auf Systeme und Karteninhaberdaten protokollieren und überwachen |
| Überwachung und Tests | 11 | Sicherheit von Systemen und Netzen regelmäßig testen |
| Sicherheitsrichtlinie | 12 | Informationssicherheit durch Richtlinien und Programme der Organisation verankern |
Was hat sich mit PCI DSS 4.0 und 4.0.1 geändert?
Version 4.0 erschien im März 2022. Am 11. Juni 2024 folgte Version 4.0.1 als begrenzte Überarbeitung: Sie korrigiert Fehler und präzisiert Absicht und Hinweise, fügt aber keine Anforderungen hinzu und streicht keine. Version 4.0 wurde am 31. Dezember 2024 zurückgezogen; seitdem ist allein Version 4.0.1 aktiv.
Mit Version 4.0 kamen zahlreiche neue Anforderungen hinzu, die zunächst als bewährte Praxis galten.
Seit dem 31. März 2025 verpflichtend: vier Beispiele
Seit dem 31. März 2025 sind diese Anforderungen verpflichtend und werden in jeder Prüfung bewertet. Vier Beispiele:
- Skripte auf Zahlungsseiten (6.4.3): Jedes Skript, das auf der Zahlungsseite im Browser geladen wird, muss autorisiert, auf Integrität geprüft und mit Begründung inventarisiert sein.
- Manipulationserkennung (11.6.1): Unautorisierte Änderungen an HTTP-Headern und Inhalten der Zahlungsseite, wie sie im Browser ankommen, müssen erkannt und gemeldet werden, mindestens alle sieben Tage oder in dem Rhythmus, den eine gezielte Risikoanalyse festlegt.
- MFA für jeden Zugang zur Kartendatenumgebung (8.4.2): Jeder Zugang in die Kartendatenumgebung, der nicht an der Konsole erfolgt, verlangt bis auf wenige Ausnahmen Multi-Faktor-Authentifizierung, nicht mehr nur administrative und Fernzugriffe.
- Gezielte Risikoanalysen (12.3.1): Wo eine Anforderung eine gezielte Risikoanalyse verlangt, etwa weil sie die Häufigkeit einer Tätigkeit der Organisation überlässt, ist diese Analyse zu dokumentieren und mindestens alle zwölf Monate zu überprüfen.
Angepasster Ansatz und Kommentierungsphase 2026
Neu ist außerdem der angepasste Ansatz (customized approach). Statt eine Anforderung wörtlich umzusetzen, kann eine Organisation eigene Kontrollen einsetzen, die das ausgewiesene Ziel der Anforderung nachweislich erreichen. Wer per Selbstbewertungsfragebogen nachweist, kann diesen Weg nicht nutzen.
Vom 3. Juni bis 20. Juli 2026 hat das Council berechtigte Stakeholder in einer Kommentierungsphase um Rückmeldungen zu Version 4.0.1 gebeten. Damit beginnt nach Angaben des Councils die Arbeit an der nächsten Fassung des Standards; einen Termin für eine neue Version nennt es nicht (Stand: Oktober 2026).
Gibt es ein PCI-DSS-Zertifikat?
Nicht im Sinne eines ISO-Zertifikats. Das Council stellt kein Zertifikat aus. Nachgewiesen wird die Einhaltung über einen der beiden Berichtswege, jeweils mit einer Konformitätsbestätigung:
| Nachweis | Wer ihn erstellt | Was er enthält |
|---|---|---|
| Selbstbewertungsfragebogen (SAQ) | Die Organisation selbst | Selbstauskunft zu den anwendbaren Anforderungen; es gibt mehrere SAQ-Typen für bestimmte Zahlungsumgebungen, jeweils mit eigenen Zulassungskriterien |
| Bericht über die Einhaltung (ROC) | In der Regel ein Qualified Security Assessor (QSA) | Prüfbericht nach einer Bewertung durch den Prüfer, auf der verbindlichen Vorlage des Councils |
| Konformitätsbestätigung (AOC) | Organisation, beim ROC zusammen mit dem Prüfer | Erklärung über das Ergebnis aus SAQ oder ROC; sie geht an die anfordernde Stelle, bei Händlern an Acquirer oder Kartenorganisation |
| Externe Schwachstellenscans | Ein Approved Scanning Vendor (ASV) | Mindestens alle drei Monate, mit bestandenem Ergebnis nach dem ASV-Programmleitfaden (Anforderung 11.3.2) |
Welcher Weg gilt, legen Kartenorganisationen und Acquirer fest. Maßgeblich sind die offiziellen Formulare und Vorlagen des Councils, also ROC, SAQ, AOC und die Bestätigung über ASV-Scans, nicht ein Zertifikat eines Dienstleisters. Wie sich ein Zertifikat grundsätzlich von einem Prüfbericht unterscheidet, zeigt der Vergleich ISO 27001 vs. SOC 2.
Geltungsbereich: Kartendatenumgebung und verbundene Systeme
Der Geltungsbereich umfasst die Kartendatenumgebung (cardholder data environment, CDE) und alle Systeme, die mit ihr verbunden sind oder ihre Sicherheit beeinflussen können. Zwei Anforderungen machen daraus eine laufende Pflicht:
- Inventar (12.5.1): Alle Systemkomponenten im Geltungsbereich werden mit Funktion und Verwendungszweck inventarisiert und aktuell gehalten.
- Bestätigung des Geltungsbereichs (12.5.2): Mindestens alle zwölf Monate und bei wesentlichen Änderungen bestätigt die Organisation den Geltungsbereich. Dazu gehören die Datenflüsse aller Zahlungsphasen und Akzeptanzkanäle, alle Speicherorte einschließlich Backups und alle Komponenten, die mit der CDE verbunden sind.
Netzsegmentierung verkleinert den Prüfumfang, wenn der Prüfer sie bestätigt
Netzsegmentierung ist nach dem Standard keine Pflicht, wird aber ausdrücklich empfohlen, weil sie den Prüfumfang verkleinern kann. Wirksam ist das nur, wenn der Prüfer die Segmentierung als ausreichend bestätigt. Als Voraussetzung für einen kleineren Geltungsbereich nennt der Standard, Kontodaten auf möglichst wenige Orte zu beschränken und nicht benötigte Daten zu entfernen.
PCI DSS, ISO 27001 und DSGVO im Vergleich
PCI DSS, ISO/IEC 27001 und DSGVO überschneiden sich beim Schutz von Daten, unterscheiden sich aber in Art, Gegenstand, Verbindlichkeit und Nachweis:
| Aspekt | PCI DSS | ISO/IEC 27001 | DSGVO |
|---|---|---|---|
| Art | Branchenstandard | Internationale Managementsystemnorm | EU-Verordnung |
| Gegenstand | Kontodaten von Zahlungskarten | Alle Informationen im Geltungsbereich | Personenbezogene Daten |
| Verbindlichkeit | Über Verträge mit Acquirer und Kartenorganisationen | Freiwillig, über Verträge und Ausschreibungen | Gesetzlich |
| Vorgaben | Detaillierte, prüfbare Einzelanforderungen | Risikobasierte Auswahl aus 93 Maßnahmen in Anhang A | Geeignete Maßnahmen nach Art. 32 |
| Nachweis | SAQ oder ROC mit AOC | Zertifikat einer akkreditierten Stelle | Rechenschaftspflicht des Verantwortlichen |
Ein ISMS nach ISO/IEC 27001 erleichtert die Arbeit an PCI DSS, ersetzt sie aber nicht: Die Prüfung nach PCI DSS fragt konkrete Einzelanforderungen ab, deren Auswahl nicht der eigenen Risikobeurteilung überlassen ist. Wie ein ISMS aufgebaut und zertifiziert wird, beschreibt der Ratgeber ISO-27001-Zertifizierung.