PCI DSS verstehen: Zweck, Geltung und Verbindlichkeit

Problem in der Praxis

In vielen Organisationen wird PCI DSS missverstanden. Mal gilt er als reines IT-Thema, das die Zahlungsdienstleister schon erledigen, mal wird er mit einer gesetzlichen Pflicht verwechselt. Beide Sichtweisen führen zu Fehlsteuerung. Wer PCI DSS als reines IT-Thema behandelt, übersieht, dass der Geltungsbereich von Geschäftsprozessen, Verträgen und Dienstleisterketten bestimmt wird, nicht von Technik allein. Wer ihn als Gesetz missversteht, sucht nach einer Aufsichtsbehörde, statt den eigentlichen Vertragspartner zu adressieren: den Acquirer beziehungsweise das jeweilige Card Scheme.

Das zeigt sich, sobald gefragt wird, wer betroffen ist und in welchem Umfang. Händler, Payment-Dienstleister, Acquirer und kartenausgebende Institute (Issuer) haben unterschiedliche Rollen, Nachweispflichten und Validierungswege. Ohne klare Einordnung entstehen Lücken, doppelte Arbeit oder falsche Annahmen über die Verantwortung des Dienstleisters.

CISO-Einordnung

Für den CISO sind vorab drei Fragen zu beantworten, bevor über einzelne Maßnahmen gesprochen wird:

• Wer gibt die Verbindlichkeit vor? Nicht der Staat, sondern der Vertrag mit Acquirer und Card Scheme. Die konkreten Pflichten ergeben sich aus dieser Vertragskette.
• Wen trifft es? Jede Stelle, die Karteninhaberdaten speichert, verarbeitet oder überträgt oder deren Sicherheit beeinflusst. Praktisch sind das Händler und Service Provider; Acquirer und Issuer agieren zusätzlich als durchsetzende beziehungsweise verarbeitende Parteien im Kartensystem.
• Worauf bezieht sich der Standard? Auf die Cardholder Data Environment (CDE), also alle Systeme, Prozesse und Personen, die Karteninhaberdaten verarbeiten, sowie damit verbundene und sicherheitsbeeinflussende Systeme.

Wichtig ist die Unterscheidung der Datenarten. Karteninhaberdaten mit der Kartennummer (PAN) als Kern sind unter Schutzauflagen verarbeitbar. Sensible Authentifizierungsdaten (Sensitive Authentication Data) dürfen nach der Autorisierung grundsätzlich nicht gespeichert werden. Diese Trennung ist häufig der erste Hebel, um Risiko und Geltungsbereich zu reduzieren.

PCI DSS ist deutlich präskriptiver und enger gefasst als ein klassisches ISMS. Er ersetzt kein ISO/IEC 27001 und wird umgekehrt durch eine ISO-Zertifizierung nicht ersetzt. Sinnvoll ist, ihn als zahlungsbezogene Kontrollschicht in die vorhandene Sicherheitssteuerung zu integrieren.

Umsetzungsperspektive

Der erste Schritt ist nicht die Maßnahmenliste, sondern die saubere Bestimmung des Geltungsbereichs. Der Scope-Anker ist die CDE. Je präziser definiert wird, welche Systeme und Prozesse Karteninhaberdaten berühren, desto gezielter lässt sich der Aufwand steuern.

Ein wirksamer Hebel ist die Reduktion des Geltungsbereichs durch Netzsegmentierung und durch Vermeidung unnötiger Datenhaltung. Was nicht gespeichert wird und was technisch sauber vom Rest getrennt ist, fällt aus dem teuersten Teil der Prüfung heraus.

Der Umfang der Nachweisführung hängt von der Rolle und vom Transaktionsvolumen ab. PCI DSS kennt Merchant- beziehungsweise Compliance-Level, die sich am jährlichen Kartentransaktionsvolumen orientieren, von Level 1 (höchstes Volumen) absteigend. Für das Management gilt: Die konkreten Schwellenwerte und die jeweils geforderten Validierungspflichten werden von den einzelnen Card Schemes festgelegt und weichen je Marke voneinander ab. Die verbindliche Einstufung ist daher immer beim eigenen Acquirer beziehungsweise beim jeweiligen Card Scheme zu erfragen und nicht pauschal anzunehmen.

Zur Validierung dienen abgestufte Instrumente, die je nach Zahlungsumgebung und Level zum Einsatz kommen: der Self-Assessment Questionnaire (SAQ) als Selbstbewertung in mehreren Varianten je nach Zahlungsumgebung, der Report on Compliance (ROC) als umfassender Prüfbericht (in der Regel durch einen Qualified Security Assessor, intern durch einen Internal Security Assessor) sowie die Attestation of Compliance (AOC) als formale Bestätigung. Ergänzend kommen externe Schwachstellen-Scans durch einen Approved Scanning Vendor und Penetrationstests hinzu. Welches Instrument greift, ergibt sich aus Rolle, Umgebung und Level.

Typische Fehler

1. PCI DSS wird als gesetzliche Pflicht missverstanden und nicht als vertragliche Verpflichtung gegenüber Acquirer und Card Scheme behandelt.
2. Der Geltungsbereich wird nicht sauber definiert, sodass die CDE entweder zu groß und damit teuer oder zu eng und damit unvollständig ist.
3. Verantwortung wird unkritisch an Dienstleister delegiert, ohne die Rollen- und Verantwortungsteilung vertraglich und nachweisbar zu klären.
4. Sensible Authentifizierungsdaten werden unbeabsichtigt gespeichert, weil Datenflüsse und Logs nicht durchleuchtet wurden.
5. Das eigene Compliance-Level und der passende Validierungsweg werden angenommen statt mit dem Acquirer verbindlich abgestimmt.

Risiken und Trade-offs

Die Folgen einer Nichteinhaltung sind vertraglicher Natur, aber wirtschaftlich erheblich: Vertragsstrafen, höhere Transaktionsgebühren und im Extremfall der Entzug der Kartenakzeptanz. Letzteres kann für ein Unternehmen mit kartenbasiertem Geschäft existenzbedrohend sein.

Der wesentliche Trade-off liegt zwischen Geltungsbereich und Aufwand. Ein breit gezogener Scope erhöht Prüf- und Betriebsaufwand dauerhaft. Eine aggressive Scope-Reduktion senkt Kosten, verlagert aber Anforderungen auf Segmentierung, Dienstleistersteuerung und saubere Datenvermeidung, die ihrerseits belastbar sein müssen.

Ein weiterer Trade-off betrifft das Verhältnis zu anderen Rahmenwerken. PCI DSS und regulatorische Pflichten wie NIS2 stehen nicht in einem Ersetzungsverhältnis. Ein Unternehmen kann beiden parallel unterliegen. Wer PCI DSS isoliert betreibt, riskiert Doppelarbeit gegenüber einem bestehenden ISMS.

Entscheidungspunkte

• Welche Geschäftsprozesse berühren Karteninhaberdaten, und wie wird die CDE bewusst klein gehalten?
• In welcher Rolle agiert das Unternehmen (Händler, Service Provider, gegebenenfalls mehrere Rollen), und welche Pflichten folgen daraus?
• Welches Compliance-Level und welcher Validierungsweg gelten laut Acquirer und Card Scheme verbindlich?
• Welche Anteile der Verantwortung liegen beim Dienstleister, und wie wird diese Teilung vertraglich und durch Nachweise abgesichert?
• Wie wird PCI DSS in die bestehende Sicherheits- und Compliance-Steuerung integriert, statt parallel betrieben zu werden?

Praktische Empfehlungen

1. Behandeln Sie PCI DSS als vertragliche Pflicht und klären Sie frühzeitig, welcher Acquirer und welches Card Scheme die verbindlichen Vorgaben setzen.
2. Definieren Sie zuerst den Geltungsbereich entlang der Datenflüsse und reduzieren Sie ihn bewusst durch Segmentierung und Datenvermeidung.
3. Lassen Sie das eigene Compliance-Level und den Validierungsweg vom Acquirer bestätigen, statt sie anzunehmen.
4. Prüfen Sie aktiv, dass keine sensiblen Authentifizierungsdaten nach der Autorisierung gespeichert werden.
5. Verankern Sie die Verantwortungsteilung mit Dienstleistern vertraglich und fordern Sie deren Konformitätsnachweise an.
6. Integrieren Sie PCI DSS als zahlungsbezogene Kontrollschicht in das vorhandene ISMS, statt eine isolierte Parallelwelt aufzubauen.

Relevante Normreferenzen

• PCI DSS v4.0.1 (PCI Security Standards Council): maßgebliche Referenz für Anforderungen, Geltungsbereich und Validierung. Verbindlicher Text und Vorlagen liegen ausschließlich beim PCI SSC.
• ISO/IEC 27001: Referenz für ein risikobasiertes ISMS mit breitem Geltungsbereich; hohe Control-Überschneidung, aber kein Ersetzungsverhältnis zu PCI DSS.
• NIST Cybersecurity Framework und NIST SP 800-53 / 800-63: konzeptionell anschlussfähige Referenzen, insbesondere für Authentifizierung und Zugriffssteuerung; kein offizielles 1:1-Mapping durch das PCI SSC.