PCI DSS: Die 12 Sicherheitsanforderungen im Detail

Die wichtigsten Stichtage für PCI DSS 4.0 und 4.0.1

Für IT-Teams sind neben den fachlichen Änderungen vor allem die Übergangsfristen entscheidend. Seit dem 31. März 2024 ist PCI DSS 3.2.1 offiziell zurückgezogen; seitdem orientieren sich Assessments an PCI DSS 4.x.

Ein großer Teil der neuen Vorgaben war future-dated definiert. Diese Anforderungen galten bis zum 31. März 2025 als Best Practice und sind seit dem verbindlich. Der Wechsel von Version 4.0 auf Version 4.0.1 war auch operativ relevant. Laut PCI Security Standards Council (PCI SSC) ist PCI DSS 4.0 zum 31. Dezember 2024 ausgelaufen und nun PCI DSS 4.0.1 die aktuelle Referenz.

Die zwölf PCI-DSS-Anforderungen im Überblick

Die bekannte Struktur mit den zwölf PCI-DSS-Kernanforderungen bleibt bestehen, wurde jedoch an moderne Betriebsmodelle angepasst. Die Anforderungen decken weiterhin Netzwerk- und Systemschutz, Datenschutz, Schwachstellenmanagement, Zugriffskontrolle, Monitoring sowie Governance ab.

Im Folgenden fassen wir die Anforderungen aus der Praxisperspektive zusammen, das heißt, wir betrachten, welche technischen und organisatorischen Nachweise typischerweise erforderlich sind.

Anforderung 1: Netzsicherheitskontrollen und Segmentierung

Anforderung 1 adressiert die Absicherung und Abgrenzung der CDE. Der Standard spricht dabei ausdrücklich von Netzsicherheitskontrollen, um neben klassischen Firewalls auch Cloud-Sicherheitsgruppen, virtuelle Appliances und SDN-Kontrollen abzudecken.

Für die Umsetzung sind vor allem diese Punkte relevant:

• Dokumentierte Netzwerkdiagramme und Datenflussdiagramme für Systeme und Verbindungen der CDE.
• Regelsätze mit explizit erlaubten Diensten, Ports und Protokollen samt Begründung.
• Regelmäßige Überprüfungszyklen für Regeln und Ausnahmen.
• Netzwerksegmentierung kann den PCI-DSS-Geltungsbereich deutlich verkleinern und muss regelmäßig durch Segmentierungstests nachgewiesen werden.

Anforderung 2: Sichere Konfigurationen und Abschalten von Standardwerten

Hier geht es um Hardening über alle Systemkomponenten hinweg. Standardpasswörter, unnötige Services und unsichere Protokolle sind klassische Einfallstore, die PCI DSS ausdrücklich adressiert.

In der Praxis sollten Sie folgende Themen abdecken:

• Baselines für Betriebssysteme, Netzkomponenten, Container-Plattformen und Cloud-Workloads.
• Deaktivierung nicht benötigter Funktionen, Dienste und Zugänge.
• Ein Inventar der in den Anwendungsbereich fallenden Systemkomponenten.
• Sichere Remote-Administration und gehärtete Managementschnittstellen.

Anforderung 3: Schutz gespeicherter Kontodaten

Anforderung 3 folgt dem Prinzip So wenig wie möglich speichern. Wo eine Speicherung unvermeidbar ist, verlangt PCI DSS eine starke Verschlüsselung, ein belastbares Schlüsselmanagement sowie klare Aufbewahrungs- und Löschregeln.

Typische Nachweise umfassen:

• Datenklassifizierung.
• Retention-Regeln und Löschprozesse für CHD.
• Verbot der Speicherung von SAD nach Autorisierung.
• Kryptografische Verfahren und Schlüsselmanagement über den gesamten Lebenszyklus.
• Zusätzliche Kontrollen sind erforderlich, wenn nur Festplattenverschlüsselung genutzt wird.

Anforderung 4: Kryptografischer Schutz bei der Übertragung

Übertragene Karteninhaberdaten müssen durch starke Kryptografie geschützt sein, wenn sie über offene, öffentliche Netze übertragen werden. Unsichere Altprotokolle sind dabei nicht akzeptabel, der Fokus liegt auf robusten Konfigurationen und Zertifikatsmanagement.

Für die technische Umsetzung sind diese Bausteine zentral:

• TLS-basierte Transportabsicherung mit aktueller Konfiguration,
• Verbot unverschlüsselter PAN-Übertragung über Messaging-Kanäle wie E-Mail oder Messenger.
• Ein Zertifikats- und Schlüssel-Inventar inklusive Laufzeiten und Zuständigkeiten ist ebenfalls erforderlich.
• Anforderungen an Dienstleister-Schnittstellen und Partnerstrecken.

Anforderung 5: Schutz vor bösartiger Software

PCI DSS verlangt Schutzmaßnahmen gegen Malware auf allen gefährdeten Systemen. In Version 4.x wird stärker betont, dass Häufigkeiten und Maßnahmen risikobasiert festgelegt und begründet werden können.

Wichtige Punkte für Audits sind üblicherweise:

• Antimalware-Kontrollen, Updates und Manipulationsschutz.
• Zentrale Protokollierung der Schutzlösung.
• Maßnahmen gegen Phishing und Social Engineering in der technischen Kette.
• Scans von Wechselmedien und kontrollierte Gerätelandschaften.

Anforderung 6: Sichere Systeme und Anwendungen

Diese Anforderung verbindet Patch-Management mit einem sicheren Entwicklungsprozess (Secure Development). Für öffentlich erreichbare Anwendungen sind zusätzliche Schutzmechanismen erforderlich. Außerdem rücken Skripte auf Zahlungsseiten stärker in den Fokus.

Für die Praxis bedeutet das in der Regel:

• Patch-Prozesse mit Fristen, Priorisierung und Nachweisführung,
• Secure Software Development Lifecycle (SSDLC), Code-Reviews und Security-Tests erforderlich.
• Für Tests dürfen nur Testdaten oder anonymisierte bzw. tokenisierte Daten genutzt werden, keine echten CHD.
• Kontrollen für Payment-Page-Skripte zur Erkennung von Web-Skimming.

Anforderung 7: Zugriff nach dem Need-to-know-Prinzip

Anforderung 7 fordert rollenbasierte Zugriffskonzepte, die den Zugang auf Systeme und Daten auf das notwendige Minimum beschränken. Dadurch wird das Schadenspotenzial bei kompromittierten Konten und bei Insider-Risiken reduziert.

Im Audit werden oft folgende Nachweise geprüft:

•  Rollen- und Rechtekonzept mit Genehmigungsprozess.
• Regelmäßige Rezertifizierung von Berechtigungen.
• Strikte Kontrolle privilegierter Konten und administrative Trennung.
• Standardmäßig verweigerter Zugriff, Freigaben nur bei Bedarf.

Anforderung 8: Identifizierung und Authentifizierung inklusive MFA

PCI DSS 4.x verschärft die Authentifizierungsvorgaben deutlich. Multifaktor-Authentifizierung (MFA) ist für Zugriffe in die CDE wesentlich breiter gefasst als in Version 3.2.1.

Ein zentraler future-dated Punkt war die Passwortlänge. Die Zusammenfassung der Änderungen nennt eine Erhöhung auf mindestens 12 Zeichen als verbindliche Vorgabe, es sei denn, die Systeme unterstützen keine 12 Zeichen.

In der Umsetzung sollten Sie insbesondere Folgendes absichern:

• Eindeutige Benutzer-IDs, keine geteilten Accounts.
• MFA für alle relevanten Zugriffe auf die Karteninhaberdatenumgebung und entlang der jeweiligen Zugriffspfade.
• Passwortrichtlinien, Lockout-Regeln und sichere Wiederherstellungsprozesse.
• Schutz vor Umgehung und Wiederholungsangriffen auf Authentifizierungsflüsse.

Anforderung 9: Physische Sicherheit

Der physische Zugriff stellt einen realistischen Angriffsvektor dar, insbesondere bei POS-Geräten und Medien mit Kontodaten. PCI DSS verlangt deshalb kontrollierten Zugang, Besuchersteuerung und sichere Entsorgung.

Für die Umsetzung sind typischerweise folgende Maßnahmen erforderlich:

• Zutrittskontrollen und nachvollziehbare Besucherprozesse.
• Schutz und Inventarisierung von Datenträgern.
• Regelmäßige Inspektion von POS-Geräten gegen Manipulation.
• Sichere Vernichtung von Medien nach definierten Verfahren.

Anforderung 10: Protokollierung und Überwachung

Logs sind Pflicht, aber PCI DSS 4.x betont die Wirksamkeit stärker. Für die Forensik und Vorfallserkennung sind automatisierte Auswertung und manipulationssichere Log-Ketten entscheidend.

Achten Sie vor allem auf diese Punkte:

• Vollständige Audit Trails für Zugriffe und privilegierte Aktionen,
•  Zeitsynchronisation und Integritätsschutz für Logs.
• Aufbewahrungsfristen und Online-Verfügbarkeit für Analysen.
• utomatisierte Alarme auf Basis definierter Erkennungsregeln, meist über SIEM- oder XDR-Plattformen.

Anforderung 11: Regelmäßige Tests und Scans

Anforderung 11 verlangt wiederkehrende Scans und Penetrationstests sowie Tests der Segmentierung. Das Ziel besteht darin, Schwachstellen zu finden, bevor Angreifer sie ausnutzen können.

Diese Testarten gehören in der Regel zum Pflichtprogramm:

• Externe und interne Schwachstellenscans in festgelegten Intervallen.
• Penetrationstests mindestens jährlich und nach wesentlichen Änderungen.
• Segmentierungstests als Nachweis, dass die Netzwerktrennung zur Kartenumgebung wirksam ist.
• Nachweis der Behebung und Priorisierung identifizierter Schwachstellen.

Anforderung 12: Governance, Richtlinien und Risikomanagement

PCI DSS 4.x fordert eine höhere Nachweisbarkeit bei Prozessen, Verantwortlichkeiten und Risikobegründungen. Eine gezielte Risikoanalyse erlaubt es, bestimmte Frequenzen risikobasiert festzulegen, sie muss jedoch sauber dokumentiert sein.

In der Praxis gehören dazu:

• Sicherheitsrichtlinien, Rollenmodelle und Verantwortliche pro Anforderung.
• Security-Awareness-Programm inklusive Phishing.
• Dienstleistermanagement mit klaren Verantwortungsgrenzen.
• Vorfallreaktionsplan einschließlich regelmäßiger Tests und systematischer Nachbereitung.

Defined Approach und kundenspezifischer Ansatz

In PCI DSS 4.x wird zwischen dem Defined Approach als klassischem Vorgehen und dem kundenspezifischen Ansatz unterschieden. Letzterer erlaubt alternative Kontrollen, sofern das jeweilige Sicherheitsziel erreicht wird. Der PCI SSC beschreibt den kundenspezifischen Ansatz explizit als Alternative mit Fokus auf das jeweilige Sicherheitsziel.

Für IT-Organisationen bedeutet das: Der kundenspezifische Ansatz ist bei Cloud-Native-Architekturen oder abweichenden technischen Kontrollen attraktiv, erhöht aber den Dokumentations- und Nachweisaufwand gegenüber dem Auditor deutlich.

Compliance-Level und Validierungspflichten

Das Compliance-Level und die Nachweise richten sich nach den Vorgaben der Kartenmarke und der Händlerbank beziehungsweise des Zahlungsdienstleisters (dem Acquirern), der die Kartenakzeptanz abwickelt.

Die Einstufung nach Transaktionsvolumen ist nicht weltweit einheitlich, sondern wird von Kartenmarken und Acquirern konkretisiert. Visa stuft Händler beispielsweise ab einem Transaktionsvolumen von mehr als 6 Millionen Visa-Transaktionen pro Jahr als Level 1 ein, Mastercard verwendet ähnliche Schwellen und definiert Level 1 bis 4 mit konkreten Validierungsanforderungen. American Express verwendet andere Grenzwerte und ordnet Händler bereits ab 2,5 Millionen Transaktionen pro Jahr als Level 1 ein.

Fazit

Mit PCI DSS 4.x wurde der Schwerpunkt von punktueller Audit-Erfüllung zu nachweisbar wirksamen, kontinuierlich betriebenen Sicherheitskontrollen verschoben. Insbesondere die Bereiche IAM, Protokollierung, Webanwendungs- und Skriptkontrollen sowie das Risikomanagement werden strenger bewertet.

You can find editorially independent, English-language information on this topic here.