PCI DSS ist ein Sicherheitsstandard für alle, die Kreditkartendaten speichern, verarbeiten oder übertragen. Er stammt nicht von einem Normungsgremium, sondern von den großen Kartenorganisationen, die ihn gemeinsam über den PCI Security Standards Council pflegen. Verbindlich wird er nicht durch Gesetz, sondern durch Vertrag: Wer Kartenzahlungen akzeptiert oder als Dienstleister im Zahlungsverkehr arbeitet, verpflichtet sich gegenüber seinem Acquirer zur Einhaltung.
Der Standard unterscheidet sich in seinem Charakter deutlich von einer ISO-Norm. Er beschreibt kein Managementsystem, sondern rund dreihundert einzelne technische und organisatorische Anforderungen, gebündelt in zwölf Hauptforderungen. Die Umsetzung ist überwiegend nicht verhandelbar. Wo eine ISO-Norm sagt, dass Risiken zu bewerten und angemessene Maßnahmen zu treffen sind, sagt PCI DSS, welche Maßnahme zu treffen ist.
Die aktuelle Fassung ist Version 4, die die Vorgängerversion abgelöst hat. Sie hat den Standard an zwei Stellen geöffnet und an vielen verschärft: Neu ist ein maßgeschneiderter Ansatz, bei dem eine Organisation ein Sicherheitsziel auf eigenem Weg erreichen darf, wenn sie das mit einer zielgerichteten Risikoanalyse begründet und der Prüfer es akzeptiert. Verschärft wurden unter anderem Authentisierung, die Überwachung von Skripten auf Zahlungsseiten und die Pflicht, den Geltungsbereich regelmäßig neu zu bestimmen.
Was der Standard verlangt
Die zwölf Hauptforderungen sind sechs Zielbereichen zugeordnet.
| Zielbereich | Anforderungen | Kern |
|---|---|---|
| Sicheres Netzwerk aufbauen und erhalten | 1, 2 | Netzsegmentierung und Firewallregeln, keine Standardpasswörter und Standardkonfigurationen |
| Kontodaten schützen | 3, 4 | Speicherung nur, wenn nötig, Kartennummer unlesbar machen, Verbot der Speicherung von Prüfziffer und Magnetstreifendaten, starke Verschlüsselung bei Übertragung über öffentliche Netze |
| Schwachstellenmanagement betreiben | 5, 6 | Schutz vor Schadsoftware, sichere Entwicklung, Einspielen von Sicherheitsupdates, Steuerung von Skripten auf Zahlungsseiten |
| Zugriff wirksam beschränken | 7, 8, 9 | Rechte nach Notwendigkeit, eindeutige Kennungen und Mehrfaktorauthentisierung, physische Sicherung von Räumen und Datenträgern |
| Netze überwachen und testen | 10, 11 | Protokollierung und Auswertung, wiederkehrende Schwachstellenscans, Penetrationstests, Prüfung der Segmentierung |
| Sicherheitsleitlinien pflegen | 12 | Richtlinien, Schulung, Risikoanalysen, Dienstleistersteuerung, Vorfallreaktionsplan |
Drei Begriffe entscheiden über den gesamten Aufwand.
Der Geltungsbereich. Erfasst sind alle Systeme, die Kartendaten verarbeiten, speichern oder übertragen — und zusätzlich alle Systeme, die mit diesen verbunden sind oder deren Sicherheit beeinflussen. Der zweite Halbsatz ist der teure: Ein Administrationsserver, ein Verzeichnisdienst oder ein Monitoring-System ohne Netztrennung zieht die halbe Infrastruktur in den Geltungsbereich.
Die Einstufung. Die Kartenorganisationen legen selbst fest, ab welchem Transaktionsvolumen eine externe Prüfung vor Ort erforderlich ist und wo eine Selbstauskunft genügt. Diese Schwellen unterscheiden sich zwischen den Marken und ändern sich. Verbindlich ist deshalb immer die Auskunft des eigenen Acquirers, nicht eine allgemeine Übersicht.
Der richtige Fragebogen. Für die Selbstauskunft gibt es mehrere Varianten, die sich stark im Umfang unterscheiden. Die Auswahl ist die folgenreichste Einzelentscheidung im ganzen Verfahren.
| Variante | Typische Situation | Umfang |
|---|---|---|
| A | Zahlung vollständig ausgelagert, Kartendaten berühren eigene Systeme nie | am kleinsten |
| A-EP | eigener Shop steuert die Zahlungsseite, Daten fließen zum Dienstleister | deutlich größer als A |
| B | Terminal ohne Anbindung an ein Netz, Abdrucke auf Papier | klein |
| B-IP | eigenständiges Terminal mit Netzanbindung | mittel |
| C | Kassensystem mit Internetanbindung, kein Speichern von Kartendaten | mittel |
| P2PE | Terminal mit durchgehender Verschlüsselung aus einer freigegebenen Lösung | klein |
| D | alle übrigen Fälle sowie Dienstleister | vollständig |
Für wen der Standard gilt und wo Aufwand vermeidbar ist
Der Standard gilt für jeden, der Kartendaten berührt — unabhängig von der Unternehmensgröße. Die Frage ist deshalb nicht, ob er gilt, sondern wie groß der Aufwand ausfällt. Und der ist gestaltbar.
Für Onlinehändler ist die Auslagerung der Zahlungsseite der wirksamste Schritt. Wenn die Kartennummer ausschließlich in einem vom Dienstleister betriebenen Eingabefeld oder auf dessen Seite eingegeben wird, sinkt der Nachweisaufwand erheblich. Wichtig ist die technische Ausgestaltung: Sobald der eigene Shop das Eingabefeld selbst aufbaut oder die Daten zunächst an den eigenen Server gehen, gilt der deutlich umfangreichere Fragebogen.
Im stationären Handel leistet ein Terminal mit durchgehender Verschlüsselung dasselbe. Die Kartendaten sind ab dem Lesevorgang verschlüsselt und werden erst beim Dienstleister wieder lesbar. Voraussetzung ist, dass die eingesetzte Lösung als solche anerkannt ist — ein Terminal, das lediglich verschlüsselt überträgt, genügt dafür nicht.
Der aufwendige Fall ist die telefonische Zahlungsannahme. Sobald Beschäftigte Kartennummern entgegennehmen, sind Arbeitsplätze, Telefonanlage und Gesprächsaufzeichnung im Geltungsbereich. Hier lohnt der Blick auf Verfahren, bei denen die Anruferin die Nummer selbst über die Tastatur eingibt und die Töne aus der Aufzeichnung herausgehalten werden.
Nicht vermeidbar ist der Aufwand für Dienstleister im Zahlungsumfeld: Zahlungsdienstleister, Hoster von Shopsystemen, Anbieter von Kassensoftware. Für sie gilt der vollständige Katalog, und ihre Kunden fragen die Konformitätserklärung regelmäßig ab.
Der Weg zur Konformitätserklärung
Anders als bei ISO-Normen gibt es kein Stufe-1- und Stufe-2-Audit und keinen Dreijahreszyklus. Der Ablauf sieht anders aus.
Geltungsbereich bestimmen. Zuerst wird dokumentiert, wo Kartendaten entstehen, wohin sie fließen, wo sie liegen und wer sie sieht. Grundlage ist ein Datenflussdiagramm mit allen Systemen und Schnittstellen. Version 4 verlangt, diese Bestimmung regelmäßig zu wiederholen und zu dokumentieren.
Lücken schließen. Aus dem Abgleich mit den Anforderungen entsteht ein Maßnahmenplan. Typische Brocken sind Netzsegmentierung, Mehrfaktorauthentisierung für alle Zugänge zur Kartendatenumgebung, zentrale Protokollierung und die Bereinigung von Altsystemen, in denen Kartennummern im Klartext liegen.
Technische Prüfungen durchführen. Von außen erreichbare Systeme werden vierteljährlich durch einen zugelassenen Scandienstleister geprüft. Hinzu kommen interne Scans, Penetrationstests und der Nachweis, dass die Segmentierung tatsächlich wirkt.
Bewertung und Erklärung. Je nach Einstufung folgt die Selbstauskunft oder die Prüfung durch einen Qualified Security Assessor mit Bericht. Beides mündet in die Konformitätserklärung, die an Acquirer oder Auftraggeber geht und zwölf Monate gilt.
Betrieb aufrechterhalten. Die Anforderungen gelten dauerhaft, nicht zum Stichtag. Scans, Rechteüberprüfungen, Protokollauswertungen und Schulungen laufen im Jahresrhythmus weiter. Ein Vorgehen dafür beschreibt der Beitrag zur risikobasierten Auditprogrammplanung.
Woran Projekte scheitern
Der falsche Fragebogen. Ein Shop nutzt ein eigenes Formular und sendet die Daten an den Dienstleister weiter, füllt aber die kleinste Variante aus. Das fällt spätestens nach einem Vorfall auf — und dann rückwirkend, weil die Erklärung dann als unzutreffend gilt.
Skripte auf der Zahlungsseite sind unbekannt. Analyse-, Chat- und Marketingskripte werden über einen Tag-Manager eingebunden, den das Marketing verwaltet. Niemand führt ein Verzeichnis, niemand prüft Änderungen. Genau dieser Weg wird für das Abgreifen von Kartendaten im Browser genutzt, weshalb Version 4 hier ausdrückliche Anforderungen stellt.
Verbotene Daten liegen in Protokollen. Die Anwendung schreibt bei Fehlern die vollständige Anfrage mit — inklusive Prüfziffer. Oder das Callcenter zeichnet Gespräche vollständig auf. Beides ist unzulässig, und beides wird bei der ersten Datenträgerprüfung gefunden.
Die Segmentierung existiert nur im Diagramm. Auf dem Netzplan sind die Zonen getrennt, in den Firewallregeln stehen historisch gewachsene Freigaben, die das aushebeln. Der Test der Segmentierung deckt das auf und zieht den Geltungsbereich schlagartig auf das gesamte Netz aus.
Scans werden gestartet, aber nicht abgeschlossen. Vierteljährlich läuft ein Scan, es bleiben offene Befunde, ein bestandener Scan wird nie nachgezogen. Nachgewiesen werden muss aber der bestandene Scan, nicht der Versuch.
Dienstleister werden nicht gesteuert. Es fehlt ein Verzeichnis aller Dienstleister mit Kartendatenbezug, deren aktueller Konformitätserklärungen und einer Aufteilung, wer welche Anforderung erfüllt. Diese Aufteilung ist ausdrücklich gefordert und lässt sich nicht durch einen Standardvertrag ersetzen. Wie sich Dienstleister ohne Bürokratie bewerten lassen, zeigt der Beitrag zur Lieferantenbewertung.
Änderungen erfolgen ohne erneute Prüfung des Geltungsbereichs. Ein neues Kassensystem, ein zusätzlicher Standort, ein Wechsel des Zahlungsdienstleisters — und niemand prüft, ob sich der Geltungsbereich verschoben hat.
Rechte werden nie überprüft. Konten ausgeschiedener Beschäftigter bestehen weiter, geteilte Administrationskonten existieren trotz Verbot eindeutiger Zuordnung. Das ist die häufigste organisatorische Feststellung überhaupt und betrifft ISO-27001-Audits genauso.
Abgrenzung zu Normen und anderen Nachweisen
| Standard oder Nachweis | Gegenstand | Ergebnis |
|---|---|---|
| PCI DSS | konkrete technische Anforderungen für Kartendaten | Konformitätserklärung, zwölf Monate gültig |
| ISO 27001 | Managementsystem für Informationssicherheit, risikobasiert | Zertifikat einer akkreditierten Stelle, drei Jahre |
| ISO 27002 | Maßnahmenkatalog als Auslegungshilfe | kein Zertifikat |
| SOC 2 | Prüfbericht über Kontrollen eines Dienstleisters | Bericht eines Prüfers, kein Zertifikat |
| BSI C5 | Kriterienkatalog für Cloud-Dienste, deutscher Ursprung | Prüfbericht, im öffentlichen Sektor verbreitet |
| DORA | aufsichtsrechtliche Vorgaben für den Finanzsektor | gesetzliche Pflicht, keine Zertifizierung |
| PCI PIN, PCI 3DS und weitere | Spezialstandards für einzelne Verfahren im Zahlungsverkehr | eigene Bewertungen, jeweils eigener Anwenderkreis |
Die häufigste Fehlannahme betrifft das Verhältnis zu ISO 27001. Beide Systeme parallel zu betreiben ist verbreitet und sinnvoll, aber sie ersetzen einander nicht. ISO 27001 liefert die Organisation: Rollen, Risikoverfahren, Dokumentenlenkung, internes Audit, Managementbewertung. PCI DSS liefert die Pflichtmaßnahmen für ein eng umgrenztes Feld. In der Praxis ist der wirtschaftliche Weg, die Kartendatenumgebung als klar abgegrenzten Teil des Geltungsbereichs des Informationssicherheitssystems zu führen und die PCI-Anforderungen dort als verbindliche Vorgaben zu verankern. Die gemeinsamen Elemente — Protokollierung, Rechteverwaltung, Schwachstellenmanagement, Vorfallbehandlung — lassen sich dann einmal aufbauen und für beide Nachweise verwenden.
