PCI DSS v4.0.1,
verständlich erklärt

PCI DSS (der Payment Card Industry Data Security Standard) ist der Sicherheitsstandard, der für jede Organisation gilt, die Zahlungskartendaten speichert, verarbeitet oder übermittelt. Er wird vom PCI Security Standards Council (PCI SSC) gepflegt, einem von den grossen Kartenmarken gegründeten Gremium, und legt fest, was Sie tun müssen, um Cardholder Data überall dort zu schützen, wo sie Ihre Systeme berührt.

Ein Punkt, den man früh richtig fassen sollte: PCI DSS wird nicht von einem Staat durchgesetzt. Durchgesetzt wird es von den Kartenmarken sowie den Banken und Prozessoren, die zwischen Ihnen und ihnen stehen, über Ihre Verträge. Das prägt auch die Sprache. Im Gespräch sagt man «PCI certified», doch genau genommen validieren Sie Compliance und erstellen eine Attestation of Compliance. Ein staatliches Zertifikat gibt es nicht, und hier präzise zu sein erspart später Verwirrung.

Die aktuelle Version ist v4.0.1, veröffentlicht im Juni 2024. Sie ist eine begrenzte Überarbeitung von v4.0, die korrigiert und klärt, statt neue Anforderungen hinzuzufügen. Wenn man also von «was sich in Version 4 geändert hat» spricht, meint man die grössere v4.0, die v4.0.1 aufräumt. Die Vorgängerversion v3.2.1 wurde am 31. März 2024 zurückgezogen, und die umfangreicheren neuen Anforderungen aus v4.x wurden am 31. März 2025 verbindlich.

PCI DSS gilt weit breiter, als man erwartet. Wenn Ihre Organisation Cardholder Data speichert, verarbeitet oder übermittelt oder die Sicherheit einer Umgebung beeinflussen kann, die das tut, sind Sie im Scope. Das umfasst Händler, die Kartenzahlungen annehmen, aber auch Service Provider, Payment Gateways und jeden in der Kette, der im Auftrag eines anderen mit Kartendaten umgeht.

Wie streng Sie validieren müssen, hängt von Ihrem Merchant Level ab, das die Kartenmarken nach dem jährlichen Transaktionsvolumen festlegen. Die Stufen reichen von 1 bis 4, wobei Level 1 die umsatzstärksten Händler erfasst und Level 4 die kleinsten. Der Standard, den Sie erfüllen müssen, ist auf jeder Stufe derselbe; was sich ändert, ist, wie Sie es nachweisen.

In der Praxis heisst das, ein kleiner Onlineshop und ein grosser Prozessor unterliegen denselben 12 Anforderungen, doch der kleinere Händler beurteilt sich in der Regel selbst, während der grösste ein unabhängiges Assessment durchlaufen muss. Ihr Level zu kennen ist der erste Schritt, denn es sagt Ihnen, welcher der folgenden Validierungswege für Sie gilt.

PCI DSS ist um 12 Anforderungen herum aufgebaut, geordnet unter 6 übergeordnete Ziele. Die Ziele sind: ein sicheres Netzwerk und sichere Systeme aufbauen und unterhalten; Account Data schützen; ein Vulnerability-Management-Programm unterhalten; starke Massnahmen zur Zugriffssteuerung umsetzen; Netzwerke regelmässig überwachen und testen; und eine Informationssicherheitsrichtlinie unterhalten. Jede einzelne Anforderung ordnet sich unter eines davon ein.

Die Anforderungen umfassen die naheliegenden technischen Controls (Firewalls und Netzwerksicherheit, sichere Konfigurationen, Verschlüsselung von Cardholder Data bei Übertragung und im Ruhezustand, Anti-Malware, sichere Softwareentwicklung, Zugriff nach dem Need-to-know-Prinzip, eindeutige IDs und starke Authentisierung) sowie die operativen, die man leichter schleifen lässt: jeden Zugriff auf Kartendaten protokollieren und überwachen, Sicherheit regelmässig testen und eine schriftliche Informationssicherheitsrichtlinie führen, an die sich die Leute auch wirklich halten.

Der Sinn dieser Struktur ist, dass es sich nicht um unabhängige Kästchen zum Abhaken handelt. Starke Zugriffssteuerung ist wertlos ohne Logging, das sie belegt; Verschlüsselung zählt nur, wenn Ihr Scope korrekt definiert ist. PCI DSS gut zu betreiben heisst, die 12 als ein zusammenhängendes System zu behandeln, und genau deshalb ist es wichtig, sie an einem Ort zugeordnet und aktuell zu halten.

Der Scope ist die Entscheidung, die im Stillen bestimmt, wie schwer Ihr PCI-DSS-Programm wird. Alles, was Cardholder Data speichert, verarbeitet oder übermittelt, ist im Scope, und ebenso alles damit Verbundene, das ihre Sicherheit beeinflussen könnte. Unkontrolliert wuchert der Scope: Ein flaches Netzwerk kann Ihren gesamten Bestand ins Assessment ziehen, sodass jedes System alle 12 Anforderungen erfüllen muss.

Der wichtigste Hebel dagegen ist Netzwerksegmentierung. Indem Sie die Systeme, die Cardholder Data verarbeiten, vom Rest Ihres Netzwerks abtrennen und belegen, dass diese Trennung hält, halten Sie die Umgebung im Scope klein. Ein kleinerer Scope bedeutet weniger Systeme zu sichern, weniger zu prüfen und eine spürbar leichtere Validierung Jahr für Jahr.

Der andere grosse Hebel ist, keine Kartendaten zu halten, die Sie nicht brauchen. Die Zahlungsabwicklung an einen compliant Anbieter auszulagern, die PAN zu tokenisieren oder schlicht keine Daten zu speichern, für die es keinen geschäftlichen Grund gibt, verkleinert alles den Scope. Die günstigsten Cardholder Data im Schutz sind die, die Sie nie berühren. Den Scope von Anfang an richtig zu setzen ist mehr wert als jeder Control, den Sie später anschrauben.

Wie Sie Compliance nachweisen, hängt von Ihrem Merchant Level ab. Die meisten Organisationen validieren mit einem Self-Assessment Questionnaire (SAQ), einem strukturierten Fragenkatalog, den Sie zu Ihrer Umgebung beantworten. Es gibt mehrere SAQ-Typen, jeder darauf abgestimmt, wie Sie tatsächlich mit Kartendaten umgehen: Ein Händler, der die Zahlungsseiten vollständig ausgelagert hat, füllt einen ganz anderen, viel kürzeren SAQ aus als einer, der PANs in eigenen Systemen speichert. Den richtigen SAQ-Typ für Ihr Setup zu wählen ist selbst eine wichtige Entscheidung.

Weiter oben können sich Level-1-Händler und viele Service Provider nicht selbst beurteilen. Sie brauchen einen Report on Compliance (ROC), ein ausführliches unabhängiges Assessment, das in der Regel ein Qualified Security Assessor (QSA) erstellt, also eine Person oder Firma, die der PCI SSC für die Prüfung gegen den Standard qualifiziert hat. Der ROC ist weit gründlicher als ein SAQ, und der Prüfer testet Nachweise quer durch Ihre Umgebung, statt Ihre Antworten für bare Münze zu nehmen.

Welchen Weg Sie auch nehmen, das Ergebnis ist eine Attestation of Compliance (AOC): das unterzeichnete Dokument, das bescheinigt, dass Sie PCI DSS erfüllen, und das Sie Ihrer Bank, Ihrem Prozessor oder Ihren Kunden geben. Der SAQ oder ROC ist das eigentliche Assessment; das AOC ist die Bescheinigung, die Sie aushändigen. Zu wissen, auf welchem Weg Sie sind und welche Nachweise er verlangt, sagt Ihnen, wie viel des Jahres das Programm tatsächlich beanspruchen wird.

Eine der bedeutendsten Neuerungen von v4.0 ist ein zweiter Weg, den Standard zu erfüllen. Die traditionelle Route ist der Defined Approach: Sie setzen jede Anforderung genau wie geschrieben um, mit den vorgeschriebenen Controls, und Ihr Prüfer kontrolliert Sie gegen die angegebene Methode. Das nutzen die meisten Teams, und es bleibt vollumfänglich gültig.

Daneben hat v4.0 den Customized Approach ergänzt. Hier erfüllen Sie das zugrunde liegende Ziel einer Anforderung mit Controls eigener Gestaltung statt mit der vorgeschriebenen Methode. Er ist für reife Sicherheitsteams gedacht, die einen besseren oder moderneren Weg zum selben Ergebnis haben, doch er bringt eine schwerere Last mit sich: Sie müssen das Ziel dokumentieren, Ihren Control entwerfen und testen und von einem QSA validieren lassen, dass er die Absicht wirklich erfüllt. Der Customized Approach ist keine Abkürzung; er ist eine bewusste Option für Organisationen, deren Sicherheit dem vorgeschriebenen Text voraus ist.

PCI DSS v4.x kam nicht auf einen Schlag, und die Daten zu kennen lohnt sich. Version 3.2.1, der frühere Standard, wurde am 31. März 2024 zurückgezogen, danach mussten alle Assessments gegen v4.x erfolgen. Viele der wirklich neuen Anforderungen in v4.0 waren «future-dated»: für eine Übergangszeit Best Practice, dann ab 31. März 2025 verbindlich.

Dieser gestaffelte Rollout war gewollt. Die neuen Anforderungen (etwa zu stärkerer Authentisierung, strengerem Umgang mit Skripten auf Zahlungsseiten und häufigeren Reviews) brauchten Zeit zur Umsetzung, deshalb gab das Council den Organisationen Anlauf. Inzwischen ist v4.x vollständig in Kraft; die zukünftig datierten Anforderungen sind schlicht Anforderungen.

Version 4.0.1, veröffentlicht im Juni 2024, ist die begrenzte Überarbeitung, die v4.0 aufräumt: Errata behebt und die Absicht klärt, ohne zu ändern, was verlangt ist. Wenn Sie heute starten, prüfen Sie also gegen v4.0.1, und alles, was einst zukünftig datiert war, gilt bereits. Die Kernaussage betrifft weniger einzelne Daten als die Richtung: Der Standard hat sich klar hin zu fortlaufender, aktueller Sicherheit bewegt statt zum einmaligen Kraftakt pro Jahr.

Die grösste Verschiebung in PCI DSS v4.0 betrifft die Haltung mehr als irgendeine einzelne Anforderung: Es erwartet Sicherheit als fortlaufende, business-as-usual-Tätigkeit, nicht als etwas, das Sie in den Wochen vor einem Assessment zusammenstückeln. Die Validierung ist ein Kontrollpunkt eines Programms, das Sie das ganze Jahr betreiben, nicht das Programm selbst.

Konkret heisst das laufende Arbeit zwischen den Assessments. Vulnerability Scans laufen vierteljährlich, und interne Scans sowie erneute Scans nach jeder wesentlichen Änderung gehören zum Rhythmus. Access Reviews, Log-Monitoring, Change Control und das Sammeln von Nachweisen müssen alle weiterlaufen. Teams, die PCI DSS als jährliches Ereignis behandeln, spüren die Kosten in jedem Zyklus, wenn sie ein Jahr an Nachweisen aus dem Gedächtnis und verstreuten Laufwerken rekonstruieren.

Hier steckt der grösste Teil des echten Aufwands, und hier geht er am leichtesten verloren. Ihren Scope, Ihre 12 Anforderungen, Ihre Scans und Ihre Nachweise an einem aktuellen, verknüpften Ort zu halten, statt in einem Ordner, der vor jedem Assessment neu aufgebaut wird, ist das meiste daran, unter v4.0.1 compliant zu bleiben.

Teams fragen oft, wie sich PCI DSS zu ISO 27001 verhält, weil sich die beiden überschneiden und häufig gemeinsam verfolgt werden. Der einfachste Unterschied ist die Reichweite des Zwecks: PCI DSS ist eng und vorschreibend, es schützt gezielt Zahlungskartendaten und sagt Ihnen im Detail, was zu tun ist. ISO 27001 ist breit und risikobasiert: Es zertifiziert ein Managementsystem zum Schutz all Ihrer Informationen und lässt Sie entscheiden, welche Controls zu Ihren Risiken passen.

Sie unterscheiden sich auch darin, wer dahintersteht. PCI DSS wird vertraglich von den Kartenmarken durchgesetzt und über einen SAQ oder ROC validiert; ISO 27001 ist ein internationaler Standard, gegen den Sie sich über eine akkreditierte Stelle zertifizieren. Das eine führt zu einer Attestation of Compliance, das andere zu einem Zertifikat.

Die gute Nachricht: Die Arbeit überschneidet sich stark. Zugriffssteuerung, Logging, Verschlüsselung, sichere Entwicklung und Vulnerability Management tauchen in beiden auf. Wenn Sie Controls und Nachweise für das eine pflegen, lässt sich vieles davon direkt auf das andere übertragen. Deshalb ist jedes in einer eigenen Tabelle zu führen der teure Weg, und eine einzige, beiden zugeordnete Quelle zu halten der günstige.