Ein umfassender Leitfaden zum Erreichen und Aufrechterhalten der PCI DSS-Konformität

Veröffentlicht: 16. Dezember 2024. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Wenn ein Kunde seine Karte übergibt, vertraut er nicht nur Ihrem Unternehmen, sondern auch Ihren Systemen die Sicherheit dieser Daten an. Allein im Jahr 2024 wurden weltweit über 26 Milliarden Datensätze durch Datenlecks offengelegt , und Zahlungskartendaten gehören nach wie vor zu den wertvollsten Zielen für Angreifer, da sie direkt zu Betrug führen. PCI DSS soll diese Lücke zwischen „Wir verarbeiten Karten“ und „Wir können nachweisen, dass unsere Systeme sicher genug sind, um ihnen anvertraut zu werden“ schließen.

Dieser Leitfaden erläutert die Anforderungen des PCI DSS-Standards, insbesondere die kryptografischen Kontrollen, die vielen Unternehmen Schwierigkeiten bereiten: die Wahl zwischen Verschlüsselung und Tokenisierung, die richtige TLS-Version, die Änderungen der MFA-Anforderungen ab 2025 und der Aufbau eines Schlüsselmanagementsystems, das den Fragen eines Prüfers standhält. Abschließend wird der konkrete, nummerierte Weg zur Zertifizierung sowie die wichtigsten Einschränkungen aufgezeigt, die Sie vor Beginn kennen sollten.

Was ist PCI-DSS-Konformität und für wen gilt sie?

PCI-DSS-Konformität bedeutet, dass ein Unternehmen die vom Payment Card Industry Data Security Standard geforderten technischen und betrieblichen Kontrollen implementiert hat und nachweisen kann , um Karteninhaberdaten während ihres gesamten Lebenszyklus – Erfassung, Übertragung, Speicherung und Löschung – zu schützen. Der Standard wird vom PCI Security Standards Council (PCI SSC) gepflegt, einem Gremium, das 2006 von Visa, Mastercard, American Express, Discover und JCB gegründet wurde, um die zuvor bestehenden, uneinheitlichen Sicherheitsprogramme einzelner Kartenanbieter zu ersetzen.

PCI DSS gilt für alle Unternehmen, die Karteninhaberdaten oder sensible Authentifizierungsdaten speichern, verarbeiten oder übermitteln oder deren Sicherheit beeinträchtigen könnten – unabhängig vom Transaktionsvolumen oder der Unternehmensgröße. Sowohl ein Café mit Kartenterminal als auch eine multinationale E-Commerce-Plattform fallen unter den Geltungsbereich; der Unterschied liegt im jeweiligen Validierungsaufwand, nicht in der Anwendbarkeit des Standards.

Einige Begriffe tauchen in diesem Leitfaden und in jeder PCI-DSS-Bewertung immer wieder auf, daher lohnt es sich, sie einmal klar zu definieren:

• CDE (Cardholder Data Environment)Die Personen, Prozesse und Technologien, die Karteninhaberdaten oder sensible Authentifizierungsdaten speichern, verarbeiten oder übertragen, sowie alle verbundenen Systeme, die die Sicherheit dieser Daten beeinträchtigen könnten. Die Reduzierung des Umfangs der CDE-Daten durch Netzwerksegmentierung ist der wichtigste Hebel zur Verringerung des Bewertungsumfangs und der Kosten.
• QSA (Qualifizierter Sicherheitsgutachter): eine vom PCI SSC zertifizierte Person, die PCI DSS-Prüfungen vor Ort für Organisationen durchführt, typischerweise für Händler und Dienstleister der Stufe 1.
• SAQ (Selbstbeurteilungsfragebogen)Ein Validierungstool, mit dem Händler ihre Konformität selbst melden können, anstatt sich einem vollständigen, von einem QSA durchgeführten Audit zu unterziehen. Welcher SAQ-Typ angewendet wird, hängt davon ab, wie der Händler Kartendaten akzeptiert und verarbeitet.
• ROC (Bericht über die Einhaltung der Vorschriften)Der detaillierte Bericht, den ein QSA nach einer Vor-Ort-Prüfung erstellt und der dokumentiert, wie jede Anforderung geprüft und validiert wurde. Erforderlich für Händler der Stufe 1 und die meisten Dienstleister.
• AOC (Konformitätsbescheinigung)Eine unterzeichnete Zusammenfassung mit dem Ergebnis der Bewertung, die der akquirierenden Bank oder dem Zahlungsanbieter als formeller Nachweis des Konformitätsstatus vorgelegt wird. Jeder Händler und Dienstleister reicht eine solche Zusammenfassung ein, unabhängig davon, ob sie einem ROC oder einem SAQ folgt.

Die Einhaltung des PCI DSS ist keine bloße Formalität. Es handelt sich um eine vertragliche Verpflichtung, die von der Acquirer-Bank und den Kartenanbietern im Rahmen der Händlervereinbarung durchgesetzt wird. Wird ein Verstoß festgestellt, führt dies in der Regel zu Bußgeldern, erhöhten Transaktionsgebühren und in schwerwiegenden Fällen zum vollständigen Verlust der Berechtigung, Kartenzahlungen zu akzeptieren.

Was sind die 12 PCI-DSS-Anforderungen?

PCI DSS v4.0.1 gliedert seine Kontrollen in zwölf Anforderungen, die sechs Kontrollzielen zugeordnet sind: Aufbau und Aufrechterhaltung eines sicheren Netzwerks, Schutz von Kontodaten, Durchführung eines Schwachstellenmanagementprogramms, Implementierung einer strengen Zugriffskontrolle, regelmäßige Überwachung und Prüfung von Netzwerken sowie Aufrechterhaltung einer Informationssicherheitsrichtlinie. Jede Bewertung, ob SAQ oder vollständiges QSA-Audit, wird anhand dieser zwölf Anforderungen bewertet.

1. Installieren und warten Sie NetzwerksicherheitskontrollenFirewalls und gleichwertige Kontrollmechanismen trennen die CDE von nicht vertrauenswürdigen Netzwerken und beschränken den Datenverkehr auf das, was für Geschäftsprozesse erforderlich ist.
2. Wenden Sie sichere Konfigurationen auf alle Systemkomponenten an.: Die Standardpasswörter, -konten und -einstellungen des Anbieters werden geändert, bevor irgendein System mit dem CDE in Berührung kommt.
3. Gespeicherte Kontodaten schützenDie gespeicherten Karteninhaberdaten werden durch starke Verschlüsselung oder Tokenisierung unlesbar gemacht, und die Aufbewahrungsdauer ist auf das geschäftlich notwendige Maß beschränkt. Weitere Details finden Sie unten.
4. Schützen Sie Karteninhaberdaten während der Übertragung über offene, öffentliche Netzwerke mit starker VerschlüsselungTLS 1.2 oder höher sichert jede Übertragung von Karteninhaberdaten über das Internet oder andere nicht vertrauenswürdige Netzwerke. Weitere Details finden Sie unten.
5. Schützen Sie alle Systeme und Netzwerke vor Schadsoftware: Auf allen relevanten Systemen werden Anti-Malware-Kontrollen eingesetzt, stets auf dem neuesten Stand gehalten und aktiv überwacht.
6. Entwickeln und warten Sie sichere Systeme und SoftwareRegelmäßige Patch-Einsätze, sichere Entwicklungsmethoden und Änderungskontrolle verhindern, dass bekannte Schwachstellen in der Produktionsumgebung verbleiben.
7. Beschränken Sie den Zugriff auf Systemkomponenten und Karteninhaberdaten auf das geschäftlich notwendige Maß.: Zugriffsmodelle mit minimalen Berechtigungen beschränken den Zugriff auf Karteninhaberdaten auf diejenigen Rollen, die dies benötigen.
8. Identifizieren Sie Benutzer und authentifizieren Sie den Zugriff auf SystemkomponentenJeder Benutzer und Administrator wird eindeutig identifiziert, und für den Zugriff auf die CDE wird eine Multi-Faktor-Authentifizierung erzwungen. Weitere Details finden Sie unten.
9. Beschränken Sie den physischen Zugriff auf KarteninhaberdatenEinrichtungen, Medien und Geräte, die Karteninhaberdaten speichern, sind physisch gesichert und der Zugriff wird protokolliert.
10. Protokollieren und überwachen Sie sämtliche Zugriffe auf Systemkomponenten und Karteninhaberdaten: Audit-Trails erfassen, wer wann auf was zugegriffen hat, und die Protokolle werden regelmäßig auf Anomalien überprüft.
11. Testen Sie regelmäßig die Sicherheit von Systemen und Netzwerken.: Vierteljährliche ASV-Schwachstellenscans, jährliche Penetrationstests und laufende Überprüfungen des Geltungsbereichs bestätigen, dass die Kontrollen tatsächlich wirksam sind.
12. Unterstützen Sie die Informationssicherheit mit organisatorischen Richtlinien und ProgrammenEine dokumentierte und kommunizierte Informationssicherheitspolitik sowie ein Notfallplan bilden das Governance-Gerüst für die übrigen 11 Anforderungen.

Die Anforderungen 3, 4 und 8 betreffen die technischen Entscheidungen im Bereich Kryptografie und Authentifizierung. Hier geben die meisten Organisationen entweder zu viel Geld für die falschen Kontrollmaßnahmen aus oder lassen eine wichtige Sicherheitslücke ungelöst. Der Rest dieses Leitfadens konzentriert sich auf diese Bereiche.

Welche kryptografischen Anforderungen stellt PCI DSS?

Die kryptografischen Anforderungen des PCI DSS umfassen drei unterschiedliche Problemstellungen: die Unlesbarkeit gespeicherter Karteninhaberdaten (Anforderung 3), den Schutz von Karteninhaberdaten während der Übertragung (Anforderung 4) und die Verwaltung der Schlüssel, die diese beiden Kontrollmechanismen vertrauenswürdig machen (Anforderungen 3.6 und 3.7). Jede dieser Anforderungen hat ihr eigenes Bedrohungsmodell. Werden sie als eine einzige allgemeine „Alles verschlüsseln“-Maßnahme behandelt, erhalten Unternehmen zwar Kontrollen, die ein Audit bestehen, in der Praxis jedoch versagen.

Anforderung 3: Verschlüsselung vs. Tokenisierung für gespeicherte Karteninhaberdaten

Anforderung 3 verlangt, dass die primäre Kontonummer (PAN) überall dort, wo sie gespeichert wird, unlesbar gemacht wird. Dies kann durch starke Kryptografie, Kürzung, Indextoken mit einem sicher gespeicherten Pad oder durch Einweg-Hashing der vollständigen PAN erfolgen. In der Praxis bedeutet dies die Wahl zwischen der Verschlüsselung der PAN direkt oder deren Ersetzung durch ein Token und der Speicherung des tatsächlichen Werts an einem völlig anderen Ort.

Bedrohungsmodell. Gespeicherte Karteninhaberdaten werden durch Datenbankkompromittierung, Missbrauch durch Insider, Offenlegung von Backups und Protokollen sowie durch laterale Ausbreitung von einem weniger sensiblen System in den Datenspeicher angegriffen. Die Kontrollmechanismen müssen einem Angreifer standhalten, der bereits Lesezugriff auf die Speicherschicht hat. Daher ist die Aussage „Die Datenbank verfügt über Zugriffskontrollen“ allein nie ausreichend.

Algorithmusauswahl. Wo Verschlüsselung eingesetzt wird, ist AES-256 der De-facto-Standard für PCI-DSS-Umgebungen. Es ist hardwareseitig schnell, weist bei dieser Schlüssellänge keine bekannten praktischen kryptanalytischen Schwächen auf und wird vom PCI SSC ausdrücklich als starke Kryptografie anerkannt. AES-256-GCM wird bei neuen Implementierungen im Allgemeinen dem CBC-Modus vorgezogen, da es authentifizierte Verschlüsselung bietet, Manipulationen erkennt und die Daten verschleiert – und das bei vergleichbarem Leistungsaufwand auf modernen CPUs mit AES-NI-Beschleunigung.

Es gilt , Kompromisse zwischen Leistung und Interoperabilität zu finden. Die Verschlüsselung erhält das Format der PAN (Permanent Account Number) und sorgt für deren Umkehrbarkeit. Dies ist hilfreich, wenn nachgelagerte Systeme (z. B. Kundenbindungsprogramme, Rückbuchungen, wiederkehrende Zahlungen) den ursprünglichen Wert wiederherstellen müssen. Die Tokenisierung entfernt die echte PAN vollständig aus Ihrer Umgebung, wodurch der Geltungsbereich von PCI DSS reduziert wird. Allerdings ist hierfür ein externer oder zentraler Tokenisierungs-Tresor erforderlich, der für jedes System, das eine Detokenisierung durchführen muss, verfügbar und erreichbar ist. Formatbewahrende Tokenisierung vermeidet Änderungen an nachgelagerten Anwendungen, führt aber bei jedem Detokenisierungsaufruf zu einem zusätzlichen Netzwerk-Roundtrip, was insbesondere bei hohem Transaktionsvolumen relevant ist.

Beispiele für die Implementierung. Ein Zahlungsgateway tokenisiert die PAN typischerweise bei der Erfassung und speichert nur das Token in seiner eigenen Datenbank. Der Token-Tresor selbst ist somit das einzige System, das vollständig den PCI-DSS-Standards unterliegt. Ein älteres, lokal betriebenes Abrechnungssystem, das die echte PAN für wiederkehrende Gebühren benötigt, verwendet häufiger eine spaltenbasierte oder transparente Datenverschlüsselung (TDE) mit AES-256, die durch einen HSM-geschützten Schlüssel abgesichert ist. Der Grund dafür ist, dass das Ersetzen der PAN durch ein Token die Abrechnungslogik beeinträchtigen würde.

Abhängigkeit vom Schlüsselmanagement. Ohne die in den Anforderungen 3.6 und 3.7 beschriebenen Schlüsselmanagement-Kontrollen (siehe unten) ist keiner der beiden Ansätze sicher. Eine mit AES-256 verschlüsselte Datenbankspalte, deren Schlüssel in einer benachbarten Konfigurationsdatei gespeichert ist, bietet praktisch keinen Schutz und ist ein häufiges Ergebnis fehlgeschlagener Sicherheitsüberprüfungen.

Entscheidungsfaktor	Wählen Sie die Verschlüsselung (AES-256)	Tokenisierung auswählen
Nachgelagerte Systeme benötigen die reale PAN (wiederkehrende Abrechnung, Rückbelastungen).	Ja, die Verschlüsselung sorgt dafür, dass der Wert wiederhergestellt werden kann.	Nein, es sei denn, jedes System kann den Detokenisierungsdienst aufrufen.
Ziel ist es, den Umfang der PCI-DSS-Bewertung zu reduzieren.	Verschlüsselte Datenspeichersysteme bleiben typischerweise im Geltungsbereich	Ja, das Entfernen des eigentlichen PAN kann Systeme aus dem Geltungsbereich herausnehmen.
Hohes Transaktionsvolumen bei gleichzeitig hoher Latenzempfindlichkeit	Lokale Entschlüsselung, minimale zusätzliche Latenz	Netzwerk-Roundtrip pro Detokenisierungsaufruf hinzugefügt
Legacy-Anwendungen, die nicht neu architektonisch gestaltet werden können	Einfacher nachrüstbar auf der Speicherebene	Oft sind Anwendungsänderungen erforderlich, um den Tresor aufzurufen.
Mehrere Geschäftsbereiche oder Dritte benötigen Zugriff.	Erfordert Schlüsselverteilung und Zugangskontrolle pro Verbraucher	Zentralisiert die Kontrolle in einem Tresor, vereinfacht die Prüfung.

Anforderung 4: TLS für Karteninhaberdaten während der Übertragung

Anforderung 4 verlangt, dass Karteninhaberdaten bei der Übertragung über offene, öffentliche Netzwerke stets durch starke Kryptografie geschützt werden. PCI DSS legt im Standardtext keine bestimmte Protokollversion als obligatorisch fest, doch die eigenen Richtlinien und das Bulletin „ Migrating from SSL and Early TLS“ des PCI SSC stellen klar, dass SSL und frühe TLS-Versionen (TLS 1.0 und 1.1) die Definition starker Kryptografie nicht erfüllen. In der Praxis bedeutet dies, dass TLS 1.2 als Mindeststandard vorgeschrieben ist, wobei TLS 1.3 für Neuimplementierungen empfohlen wird.

Bedrohungsmodell. Datenübertragungen sind anfällig für Man-in-the-Middle-Angriffe, Protokoll-Downgrade-Attacken und bekannte Sicherheitslücken auf Verschlüsselungsebene wie POODLE und BEAST, die speziell SSL und frühe TLS-Versionen angreifen. Ein Prüfer, der diese Kontrollmaßnahme testet, sucht nach allen Listenern, die noch eine veraltete Protokollversion akzeptieren, und prüft nicht nur, ob TLS aktiviert ist.

Hinweise zur Protokollauswahl: Deaktivieren Sie SSL 2.0, SSL 3.0, TLS 1.0 und TLS 1.1 auf allen Systemkomponenten, die auf die CDE zugreifen, einschließlich interner Load Balancer und älterer POS-Integrationen. Konfigurieren Sie die Cipher-Suite-Präferenz so, dass Forward-Secrecy-Suites (ECDHE-basiert) gegenüber statischem RSA-Schlüsselaustausch bevorzugt werden, und vermeiden Sie symmetrische Verschlüsselungsverfahren mit Blockgrößen unter 128 Bit. Der PCI SSC verweist auf NIST SP 800-52 als Referenz für die Härtung der TLS-Konfiguration.

Kompromisse zwischen Leistung und Interoperabilität. TLS 1.3 beseitigt mehrere veraltete Handshake-Roundtrips und verzichtet auf die Unterstützung bekanntermaßen schwacher Verschlüsselungssammlungen. Dadurch werden sowohl die Verbindungslatenz als auch das Risiko von Fehlkonfigurationen reduziert. Der Nachteil besteht darin, dass einige ältere Kassenterminals, Zahlungs-SDKs und eingebettete Geräte weiterhin nur TLS 1.2 aushandeln. Daher bleibt TLS 1.2 die praktische Mindestvoraussetzung und nicht TLS 1.3. Ein schrittweiser Upgrade-Pfad, der TLS-1.2-Hardware nach einem festgelegten Zeitplan außer Betrieb nimmt, ist realistischer als eine sofortige Umstellung.

Beispiel für die Bereitstellung. Ein gängiges Muster ist die TLS-Terminierung an einem Load Balancer oder API-Gateway, das für TLS 1.2 (mindestens) und TLS 1.3 (vorzugsweise) konfiguriert ist, mit erneuter Verschlüsselung (nicht Klartext) im internen Segment zwischen Gateway und Anwendungsschicht, sodass Karteninhaberdaten niemals unverschlüsselt übertragen werden, selbst nicht innerhalb des eigenen Netzwerks der Organisation.

Anforderungen 3.6 und 3.7: Der Schlüsselmanagement-Lebenszyklus

Die Sicherheit einer Verschlüsselung hängt von den verwendeten Schlüsseln ab. Daher widmet PCI DSS dem Schlüsselschutz und dem Lebenszyklusmanagement zwei eigene Anforderungsgruppen. Anforderung 3.6 beschreibt den Schutz von Schlüsseln während ihrer Verwendung, und Anforderung 3.7 definiert den Lebenszyklus eines Schlüssels von der Erstellung bis zur Löschung.

Anforderung 3.6 verlangt, dass die zum Schutz gespeicherter Kontodaten verwendeten kryptografischen Schlüssel selbst geschützt werden. Dies kann entweder durch Verschlüsselung mit einem separaten Schlüssel, durch Speicherung in einem sicheren kryptografischen Gerät wie einem HSM oder durch Aufteilung in Komponenten unter Vier-Augen-Prinzip erfolgen. Der Zugriff auf Klartext-Schlüsselkomponenten ist auf das absolute Minimum an Verwaltern beschränkt, und die Anzahl der Speicherorte für die Schlüssel wird minimiert.

Anforderung 3.7 verlangt dokumentierte Verfahren für den gesamten Schlüssellebenszyklus: die Erzeugung sicherer Schlüssel, deren sichere Verteilung und Speicherung, die Rotation nach Ablauf einer definierten Kryptoperiode sowie die Außerbetriebnahme, den Austausch oder die Vernichtung kompromittierter, außer Betrieb genommener oder sich dem Ende ihrer Kryptoperiode nähernder Schlüssel. Sie erfordert zudem geteiltes Wissen und Vier-Augen-Prinzip bei allen manuellen Schlüsselverwaltungsvorgängen, die Verhinderung unautorisierter Schlüsselsubstitutionen sowie eine formelle, unterzeichnete Bestätigung der Schlüsselverwalter, dass sie ihre Verantwortlichkeiten verstehen und akzeptieren.

In der Praxis wird diese Anforderung am häufigsten vernachlässigt. Eine zwar dokumentierte, aber von den Tools nicht durchgesetzte Richtlinie zur Schlüsselrotation oder eine nie formal definierte Kryptoperiode sind typische Befunde bei QSA-Prüfungen. Die zentrale Verwaltung des Schlüssellebenszyklus über eine dedizierte Zertifikats- und Schlüssellebenszyklusplattform wie CertSecure Manager bietet Unternehmen verbindliche Rotationspläne, Verantwortlichkeit der Verwahrer und revisionssichere Berichte anstelle der manuellen Erfassung der Schlüsselalter in Tabellenkalkulationen.

HSM-Bereitstellung für die Schlüsselspeicherung

Ein Hardware-Sicherheitsmodul (HSM) ist die gängigste Methode, mit der die meisten konformen Organisationen die Anforderungen von Requirement 3.6 hinsichtlich „sicherer kryptografischer Geräte“ erfüllen: ein manipulationssicheres, dediziertes Gerät, das kryptografische Schlüssel generiert, speichert und verwendet, ohne sie jemals im Klartext an die Host-Anwendung oder das Betriebssystem weiterzugeben. FIPS 140-3 ist der aktuelle Validierungsstandard, anhand dessen HSMs bewertet werden, und QSAs erwarten zunehmend FIPS-validierte Schlüsselspeicher anstelle von softwarebasierten Schlüsselspeichern für sensible Umgebungen.

Unternehmen entscheiden sich in der Regel zwischen lokalen HSMs, die maximale Kontrolle bieten und häufig dort eingesetzt werden, wo regulatorische oder vertragliche Anforderungen dies erfordern, und Cloud-basierten HSM-as-a-Services . Letztere eliminieren die Investitionskosten und den Aufwand für die physische Schlüsselverwaltung und bieten dennoch FIPS-konforme Schlüsselspeicherung. Ein typisches Beispiel: Der Tokenisierungs-Vault eines Zahlungsabwicklers speichert seinen Master-Verschlüsselungsschlüssel in einem HSM-Cluster. Jeder Aufruf zur Token-Generierung oder -Detokenisierung wird innerhalb des HSM signiert bzw. entschlüsselt, sodass der Schlüssel selbst die validierte Hardware niemals verlässt.

Was fordert PCI DSS für die Multi-Faktor-Authentifizierung?

PCI DSS v4.0.1 hat die Anforderungen an die Multi-Faktor-Authentifizierung (MFA) gemäß Anforderung 8.4 deutlich erweitert. Die wichtigste Änderung, die MFA für jeden Benutzer, der auf die Karteninhaberdaten zugreift, ist seit dem 31. März 2025 vollständig in Kraft . Drei damit zusammenhängende Unteranforderungen sind hervorzuheben, da sie in kurzen Zusammenfassungen oft vermischt werden:

• Voraussetzung 8.4.1Für alle administrativen Zugriffe auf die CDE (Credential Development Environment) außerhalb der Konsole ist eine Multi-Faktor-Authentifizierung (MFA) erforderlich. Diese Anforderung wurde aus PCI DSS v3.2.1 übernommen und ist seit Jahren in Kraft.
• Voraussetzung 8.4.2Die Multi-Faktor-Authentifizierung (MFA) ist für alle Zugriffe auf die CDE erforderlich, nicht nur für administrative. Dies ist die wichtigste Neuerung in Version 4.0, die die MFA auf alle Benutzer und nicht nur auf Administratoren ausweitet und seit dem 1. Januar 2019 verpflichtend ist. 31. März 2025.
• Voraussetzung 8.4.3Die Multi-Faktor-Authentifizierung (MFA) ist für alle Fernzugriffe von außerhalb des Unternehmensnetzwerks erforderlich, die auf die zentrale Entwicklungsumgebung (CDE) zugreifen oder diese beeinträchtigen könnten. Dies gilt gleichermaßen für Mitarbeiter sowie für Fernzugriffe von Drittanbietern oder Lieferanten. Diese Anforderung bestand bereits vor Version 4.0 und wurde lediglich präzisiert, nicht neu eingeführt.

Anforderung 8.5.1 ergänzt 8.4.2 und ist seit dem 31. März 2025 ebenfalls verpflichtend: Sie verlangt, dass MFA-Systeme so implementiert werden, dass sie nur durch ein dokumentiertes, risikobewertetes Ausnahmeverfahren umgangen werden können, dass mindestens zwei unabhängige Authentifizierungsfaktoren verwendet werden, dass alle Faktoren erfolgreich sein müssen, bevor der Zugriff gewährt wird, und dass die Implementierung Replay-Angriffen widersteht. Eine MFA-Einführung, die zwar technisch einen zweiten Faktor anfordert, aber eine Umgehung durch „Gerät 30 Tage lang speichern“ ohne entsprechende Kontrollmechanismen ermöglicht, erfüllt 8.5.1 nicht.

Für die meisten Organisationen besteht die praktische Aufgabe hier darin, die MFA von der Administratorengruppe, die bereits unter 8.4.1 abgedeckt wurde, auf jeden Anwendungsbenutzer, Auftragnehmer und jede Drittanbieterintegration auszudehnen, die mit dem CDE in Berührung kommt, und dann die Anti-Bypass-Kontrollen zu dokumentieren, deren Nachweis ein Prüfer explizit verlangen wird.

Wie gelangt man zur PCI-DSS-Konformität und -Zertifizierung?

Die Erreichung der PCI-DSS-Konformität folgt unabhängig von der Händlergröße einem einheitlichen Ablauf, wobei der Umfang der Validierung in den einzelnen Phasen variiert. Hier ist der Weg Schritt für Schritt:

1. Bestätigen Sie Ihren CDE-Bereich. Erfassen Sie jedes System, jeden Prozess und jedes Netzwerksegment, das Karteninhaberdaten speichert, verarbeitet oder überträgt oder deren Sicherheit beeinträchtigen könnte. Die Netzwerksegmentierung ist der mit Abstand effektivste Weg, diesen Umfang einzugrenzen und die Kosten der Bewertung zu senken.
2. Ermitteln Sie Ihr Händlerlevel und finden Sie den richtigen Validierungspfad. Das Transaktionsvolumen bestimmt, ob Sie einen Selbstbewertungsfragebogen ausfüllen oder eine von einem QSA durchgeführte Vor-Ort-Prüfung benötigen und welcher SAQ-Typ zutrifft. Siehe die Tabelle der Compliance-Stufen unten.
3. Führen Sie eine Lückenanalyse hinsichtlich aller 12 Anforderungen durch. Prüfen Sie die aktuellen Kontrollmaßnahmen, insbesondere Verschlüsselung, Tokenisierung, TLS-Konfiguration, MFA-Abdeckung und Schlüsselverwaltung, anhand der tatsächlichen Anforderungen des PCI DSS und nicht nur anhand dessen, was sich „sicher anfühlt“.
4. Die festgestellten Lücken beheben. Schließen Sie zunächst die kryptografischen Lücken (unverschlüsselte gespeicherte PAN, veraltete TLS-Versionen, fehlende MFA beim CDE-Zugriff), da dies in den meisten Bewertungen die schwerwiegendsten Mängel sind. Gehen Sie anschließend die Lücken bei Protokollierung, Zugriffskontrolle und Dokumentation an.
5. Vollständige formale Validierung: SAQ- oder QSA-Bewertung. Händler mit geringerem Umsatzvolumen füllen den entsprechenden SAQ aus; Händler der Stufe 1 und die meisten Dienstleister unterziehen sich einer von einem QSA geleiteten Vor-Ort-Bewertung, die einen Bericht über die Einhaltung der Vorschriften (Report on Compliance, ROC) erstellt.
6. Reichen Sie die Konformitätsbescheinigung (AOC) ein. Die unterzeichnete AOC, die durch die SAQ oder ROC abgesichert ist, geht an Ihre Acquirer-Bank und, falls erforderlich, an die Kartenmarken als formeller Nachweis Ihres Compliance-Status.
7. Gewährleisten Sie die kontinuierliche Einhaltung der Vorschriften. Vierteljährliche ASV-Schwachstellenscans, jährliche Penetrationstests, laufende Protokollprüfungen und eine jährliche Überprüfung des Geltungsbereichs (Anforderung 12.5.2) verhindern, dass die Kontrollen zwischen den formalen Bewertungen unbemerkt außer Kraft gesetzt werden.

Dieser letzte Schritt wird von Unternehmen am häufigsten vernachlässigt. Ein ROC oder AOC ist eine Stichtagsbescheinigung. PCI-DSS-Compliance ist eine ganzjährige, operative Disziplin, keine einmalige Angelegenheit.

Welche Compliance-Stufe und welcher SAQ-Typ treffen auf Ihr Unternehmen zu?

PCI DSS teilt Händler anhand ihres jährlichen Kartentransaktionsvolumens in vier Stufen ein. Die Stufe bestimmt, wie die Einhaltung der Vorschriften überprüft wird, nicht ob die zwölf Anforderungen gelten. Jeder Händler, der Kartendaten verarbeitet, muss unabhängig von seiner Stufe alle zwölf Anforderungen erfüllen.

Niveau	Jährliches Transaktionsvolumen	Validierung erforderlich	Typische Beispiele
Level 1	Mehr als 6 Millionen	Jährliches QSA/ISA-Audit vor Ort, ROC, vierteljährliche ASV-Scans, jährlicher Penetrationstest, AOC	Große E-Commerce-Plattformen, große Einzelhändler, Zahlungsdienstleister
Level 2	1 zu 6 Millionen	Jährliche SAQ-Prüfung (oder QSA-Prüfung, falls vom Erwerber gefordert), vierteljährliche ASV-Scans, jährlicher Penetrationstest, AOC	Mittelgroße Einzelhandelsketten, regionale Dienstleister
Level 3	20,000 bis 1 Million (E-Commerce)	Jährliche SAQ-, vierteljährliche ASV-Scans, AOC	Wachsende E-Commerce-Händler, Nischen-Abonnementdienste
Level 4	Weniger als 20,000 (E-Commerce) oder bis zu 1 Million (alle Kanäle)	SAQ vom Acquirer empfohlen oder vorgeschrieben, Scans gegebenenfalls, AOC	Lokale Einzelhändler, kleine Cafés, kleine Websites

Bei den Stufen 2 bis 4 hängt der spezifische SAQ-Typ davon ab, wie der Händler Karteninhaberdaten akzeptiert und verarbeitet, und nicht nur vom Transaktionsvolumen:

• SAQ A: für Händler, die die Verarbeitung von Karteninhaberdaten vollständig an einen PCI DSS-konformen Drittanbieter auslagern, wie z. B. eine E-Commerce-Website, die auf eine externe Zahlungsseite weiterleitet.
• SAQ B: für Händler, die eigenständige, per Wählverbindung arbeitende Zahlungsterminals verwenden, die keine Karteninhaberdaten elektronisch speichern.
• SAQ C: für Händler, die internetbasierte Zahlungsanwendungen nutzen, ohne elektronische Speicherung von Karteninhaberdaten.
• SAQ DFür Händler und Dienstleister, die Karteninhaberdaten außerhalb der oben genannten engeren Szenarien speichern, verarbeiten oder übermitteln; dies ist der umfassendste SAQ und deckt alle 12 Anforderungen ab.

Wie lassen sich die 12 Anforderungen praktischen Kontrollmaßnahmen zuordnen?

Die nachstehende Tabelle ordnet jede Anforderung dem jeweiligen Kontrollbereich und einer repräsentativen Umsetzung zu und dient als praktische Checkliste bei der Erstellung eines Sanierungsplans.

Anforderung	Kontrollbereich	Repräsentative Umsetzung
1	Netzwerksicherheitskontrollen	Firewalls, Netzwerksegmentierung zur Isolierung des CDE
2	Sichere Konfiguration	Gehärtete Baselines, keine Standardanmeldeinformationen des Anbieters.
3	Gespeicherte Kontodaten schützen	AES-256-Verschlüsselung oder Tokenisierung, HSM-gestützte Schlüssel
4	Daten während der Übertragung verschlüsseln	Mindestens TLS 1.2, TLS 1.3 bevorzugt, kein SSL/frühes TLS
5	Anti-Malware	Endpunktschutz mit aktiver Überwachung
6	Sichere Entwicklung und Patching	Änderungskontrolle, definierte Patch-SLAs, sicherer Softwareentwicklungszyklus
7	Zugangskontrolle (Kenntnis nur für Personen mit besonderem Interesse)	Zugriff nach dem Prinzip der minimalen Berechtigungen
8	Identifizierung und Authentifizierung	Eindeutige IDs, MFA für alle CDE-Zugriffe (8.4.2/8.5.1)
9	Physische Sicherheit	Kontrollierter Zugang für Einrichtungen und Medien
10	Protokollierung und Überwachung	Zentralisierte Prüfprotokolle, regelmäßige Protokollprüfung
11	Sicherheitstests	Vierteljährliche ASV-Scans, jährliche Penetrationstests
12	Sicherheitspolitik und Governance	Dokumentierte Richtlinien, Notfallplan, jährliche Überprüfung des Geltungsbereichs

Eine kurze Geschichte von PCI DSS

PCI DSS entstand als Reaktion auf den Anstieg von Betrug im E-Commerce Ende der 1990er-Jahre. CyberSource berichtete, dass die Gewinne aus Online-Betrug bis zum Ende des Jahrzehnts 1.5 Milliarden US-Dollar erreichten, und Visa und Mastercard meldeten zwischen 1988 und 1999 zusammen Verluste von über 750 Millionen US-Dollar durch Online-Diebstahl. Visa reagierte Anfang der 2000er-Jahre mit dem Cardholder Information Security Program (CISP), doch konkurrierende, teils widersprüchliche markenspezifische Programme erschwerten die Einhaltung der Vorschriften für Händler. Die großen Zahlungsanbieter bündelten ihre Bemühungen und veröffentlichten am 15. Dezember 2004 PCI DSS Version 1.0.

• PCI DSS v2.0 (Oktober 2010): Präzisierte Implementierungsrichtlinien und reduzierte Unklarheiten bei uneinheitlichen Händlerimplementierungen.
• PCI DSS v3.0 (November 2013): Verstärktes Schwachstellenmanagement und erhöhte Passwortanforderungen als Reaktion auf ausgefeiltere Hacking-Techniken.
• PCI DSS v4.0 (März 2022): Einführung erweiterter Anforderungen an die Multi-Faktor-Authentifizierung, kundenspezifischer Implementierungsoptionen und stärkerer Schutzmaßnahmen für E-Commerce und Phishing.
• PCI DSS v4.0.1 (Juni 2024)Eine eingeschränkte Überarbeitung, die Formatierungsfehler korrigiert und die bestehenden Anforderungen präzisiert, ohne neue oder gelöschte Anforderungen. Sie ist seit der Abschaltung von Version 4.0 am 31. Dezember 2024 die einzig aktive Version und bleibt auch nach diesem Update der aktuelle Standard.

Das PCI SSC hat bestätigt, dass sich eine zukünftige Version, PCI DSS v5.0 , mit Stand 2026 in der frühen Planungsphase befindet, ein Veröffentlichungsdatum jedoch noch nicht feststeht. Branchenberichte aus dem eigenen Prüfernetzwerk des PCI SSC gehen von mindestens einem Jahr Verzögerung aus. Organisationen sollten v4.0.1 als geltenden Standard betrachten und auf einen formellen Entwurf warten, bevor sie architektonische Änderungen im Hinblick auf v5.0 vornehmen.

Einschränkungen

Die Einhaltung der PCI-DSS-Standards ist zwar notwendig, aber nicht ausreichend für die Zahlungssicherheit, und es ist wichtig, klar zu benennen, was sie nicht garantiert:

• Konform ist nicht dasselbe wie sicher. Ein ROC oder AOC spiegelt die Kontrollen zum Zeitpunkt der Bewertung wider. Organisationen wurden kurz nach Bestehen einer Bewertung kompromittiert, weil sich eine Konfiguration geändert hatte oder ein neues System zur CDE hinzugefügt wurde, ohne in den Geltungsbereich einbezogen zu werden.
• Die Genauigkeit des Umfangs hängt davon ab, dass die Segmentierung validiert und nicht nur behauptet wird. Die unbestätigte Annahme, dass ein Netzwerksegment vom CDE isoliert ist, ist eine der häufigsten Ursachen für Kartendatenpannen in ansonsten „konformen“ Organisationen.
• Kompensationskontrollen erfordern Strenge, nicht Bequemlichkeit. PCI DSS erlaubt kompensatorische Kontrollen, wenn eine Anforderung nicht genau wie formuliert erfüllt werden kann. Jede dieser Kontrollen erfordert jedoch eine dokumentierte Risikoanalyse und die Genehmigung durch einen QSA; bei laxer Anwendung werden sie zu einer Möglichkeit, die eigentliche Lücke nicht zu schließen.
• Der Standard ist versionsspezifisch und entwickelt sich ständig weiter. Die in diesem Artikel enthaltenen Hinweise beziehen sich auf PCI DSS v4.0.1 (Stand: August 2026). Eine zukünftige Revision v5.0 kann spezifische Anforderungen, Fristen oder Schwellenwerte ändern. Organisationen sollten daher vor Entscheidungen zur Einhaltung der Vorschriften die jeweils aktuelle veröffentlichte Norm überprüfen.
• Die Interpretation von QSA kann variieren. Zwei Gutachter können bei Grenzfragen zur Abgrenzung oder zu Ausgleichsmaßnahmen durchaus zu unterschiedlichen Schlussfolgerungen gelangen; die frühzeitige Einbindung Ihres QSA in eine Architekturentscheidung vermeidet spätere Nacharbeiten.

Was würde Encryption Consulting empfehlen?

Nach der Durchführung von PCI-DSS-Compliance-Prüfungen für Organisationen vom regionalen Händler bis zur nationalen Bank sind wir der Ansicht, dass die meisten PCI-DSS-Programme nicht aufgrund fehlender Kontrollen scheitern, sondern weil die kryptografische Schicht und das Schlüsselmanagement nachträglich hinzugefügt und nicht von Anfang an in die Architektur integriert wurden. Im Folgenden beschreiben wir unsere Vorgehensweise.

Beginnen Sie mit einem vollständigen kryptografischen Inventar, nicht mit Annahmen. Was man nicht kennt, kann man nicht schützen. Bevor Sie sich zwischen Verschlüsselung und Tokenisierung entscheiden oder TLS-Konfigurationen prüfen, erstellen Sie ein genaues Inventar aller Cipher Suites, Protokolle, Zertifikate und Schlüssel in Ihrer CDE. Dies deckt sich direkt mit der Anforderung 12.3.3 bezüglich der kryptografischen Materialliste (CBOM) , die wir in einem separaten Abschnitt ausführlich behandeln, falls diese Anforderung für Sie Priorität hat.

Zentralisieren Sie das Schlüssel- und Zertifikatslebenszyklusmanagement. Wir setzen CertSecure Manager ein , um Unternehmen verbindliche Rotationspläne, Verantwortlichkeit der Verwalter und zentrale Transparenz über alle relevanten Schlüssel und Zertifikate zu ermöglichen. Damit beheben wir direkt die in den Anforderungen 3.6/3.7 am häufigsten festgestellten Mängel bei fehlgeschlagenen Bewertungen. Für die Hauptschlüssel, die Tokenisierungs-Vaults oder Massenverschlüsselung schützen, empfehlen wir in der Regel FIPS 140-3-konforme Speicherung über lokale HSMs oder HSM-as-a-Service , abhängig vom Reifegrad des Betriebs und der bestehenden Infrastruktur des Unternehmens.

Die Multi-Faktor-Authentifizierung (MFA) sollte bewusst und nicht nur technisch erweitert werden. Die formale Erfüllung von Anforderung 8.4.2 ist unkompliziert; die Umsetzung der Umgehungsabsicht von Anforderung 8.5.1 erfordert mehr Disziplin. Wir unterstützen unsere Kunden dabei, jede legitime Ausnahme von der MFA zu dokumentieren, sie mit einer kompensierenden Kontrollmaßnahme zu verknüpfen und die im Laufe der Zeit entstehenden informellen Umgehungen zu beseitigen.

Compliance wird als kontinuierlicher Prozess und nicht als jährlicher Prozess betrachtet. Unsere Compliance-Beratungsleistungen verknüpfen die Arbeit mit PCI DSS mit dem breiteren regulatorischen Umfeld, dem viele unserer Kunden gegenüberstehen, darunter DORA, NIS2 und NIST CSF. So werden kryptografische Kontrollen, die für PCI DSS entwickelt wurden, so konzipiert, dass sie sich überschneidende Vorgaben erfüllen, anstatt für jede einzelne neu entwickelt zu werden.

Befinden Sie sich noch in einer frühen Phase dieses Prozesses, ist der wirkungsvollste erste Schritt in der Regel eine Gap-Analyse, insbesondere hinsichtlich der Anforderungen 3, 4 und 8. Denn hier sind die Kosten für Fehler am höchsten und die Kosten für eine verspätete Korrektur am größten. Kontaktieren Sie uns, um den Umfang einer solchen Analyse zu besprechen.

Fazit

Die PCI-DSS-Konformität ist ein kontinuierlicher Prozess der Weiterentwicklung und Steuerung, der auf zwölf Anforderungen basiert. Die kryptografischen Kontrollen gemäß den Anforderungen 3, 4 und 8 bergen das größte Risiko und den größten Arbeitsaufwand. Die richtige Wahl zwischen Verschlüsselung und Tokenisierung, die Durchsetzung von TLS 12 oder höher für alle Datenübertragungen von Karteninhaberdaten, die Ausweitung der Multi-Faktor-Authentifizierung (MFA) auf alle CDE-Nutzer gemäß Anforderung 8.4.2 und die Anwendung eines disziplinierten Schlüsselmanagement-Lebenszyklus gemäß den Anforderungen 3.6 und 3.7 gewährleisten, dass ein Unternehmen den Großteil der QSA-Prüfungen erfolgreich besteht.

Nichts davon ersetzt die kontinuierliche Arbeit: vierteljährliche Scans, jährliche Penetrationstests, jährliche Überprüfung des Geltungsbereichs und die konsequente Einhaltung der Compliance-Vorgaben als ganzjährige Aufgabe und nicht als einmaliges Ereignis. Wenn Sie eine zweite Meinung darüber wünschen, wie Ihre Organisation im Hinblick auf PCI DSS v4.0.1 tatsächlich dasteht, helfen Ihnen unsere Beratungsleistungen im Bereich Verschlüsselung dabei, die Schwachstellen zu identifizieren, die Behebung zu priorisieren und ein Programm zu entwickeln, das sowohl Prüfungen als auch Angriffen standhält.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem SAQ und einem ROC? Ein SAQ (Selbstbewertungsfragebogen) ist ein Selbstauskunftsinstrument, das die meisten Händler unterhalb von Level 1 nutzen, um die Einhaltung von Vorschriften ohne Vor-Ort-Audit zu bestätigen. Ein ROC (Konformitätsbericht) ist der detaillierte Bericht, den ein qualifizierter Sicherheitsgutachter nach einer formellen Vor-Ort-Prüfung erstellt. Er ist für Händler der Stufe 1 und die meisten Dienstleister erforderlich. Beide Dokumente dienen letztendlich der Erstellung der Konformitätsbescheinigung (Attestation of Compliance, AOC), die der Acquirer-Bank vorgelegt wird.

Ist PCI DSS eine gesetzliche oder eine vertragliche Verpflichtung? PCI DSS ist keine staatliche Vorgabe, sondern eine vertragliche Verpflichtung, die durch die Händlervereinbarung zwischen einem Unternehmen und seiner Acquirer-Bank durchgesetzt und von den Kartenanbietern unterstützt wird. Verstöße können dennoch zu Bußgeldern, höheren Transaktionsgebühren und, nach einem Verstoß, zur Haftung für Betrugsverluste führen. Die praktischen Konsequenzen ähneln daher weitgehend einer gesetzlichen Verpflichtung, obwohl der Standard selbst branchenweit vorgeschrieben ist.

Führt die Verschlüsselung von Karteninhaberdaten automatisch zum Ausschluss aus dem PCI-DSS-Geltungsbereich? Nicht automatisch. Ein System, das verschlüsselte PAN-Daten speichert, bleibt in der Regel weiterhin im Geltungsbereich, da es – wenn auch in geschützter Form – Kontodaten speichert. Die Tokenisierung, bei der die echte PAN vollständig ersetzt und ausschließlich in einem separaten Datenspeicher abgelegt wird, führt typischerweise zum Ausschluss eines Systems aus dem Geltungsbereich, vorausgesetzt, der Token kann ohne den Datenspeicher nicht in die PAN zurückverwandelt werden.

Wie oft müssen Penetrationstests und Schwachstellenscans durchgeführt werden? PCI DSS schreibt vierteljährliche externe Schwachstellenscans durch einen zugelassenen Scan-Anbieter (ASV) vor und fordert für die meisten Unternehmen ab der niedrigsten Stufe einen jährlichen Penetrationstest, der sowohl die Netzwerk- als auch die Anwendungsschicht abdeckt. Zusätzliche Scans sind nach jeder wesentlichen Änderung der zentralen Entwicklungsumgebung (CDE) erforderlich, beispielsweise nach der Einführung eines neuen Systems, einer Netzwerkänderung oder eines größeren Anwendungsupdates.

Was geschieht, wenn mein Unternehmen nach einem Datenleck als nicht konform eingestuft wird? Zu den typischen Folgen gehören Bußgelder, die von den Kartenanbietern über die Acquirer-Bank verhängt werden, Kosten für obligatorische forensische Untersuchungen, Haftung für Verluste aus betrügerischen Transaktionen, erhöhte Transaktionsgebühren und, in schwerwiegenden oder wiederholten Fällen, der Entzug der Berechtigung zur Abwicklung von Kartenzahlungen. Der Nachweis der Konformität zum Zeitpunkt des Datenlecks – und nicht erst im Nachhinein – hat wesentlichen Einfluss auf die Anwendung dieser Konsequenzen.

Referenzen

• PCI DSS v4.0.1 Standarddokument, PCI Security Standards Council
• Neu erschienen: PCI DSS v4.0.1, PCI SSC Blog
• Jetzt ist es an der Zeit, die zukunftsorientierten Anforderungen von PCI DSS v4.x zu erfüllen (PCI SSC Blog).
• Migration von SSL und frühen TLS-Systemen, PCI SSC Informationsergänzung
• Definiert PCI DSS, welche TLS-Versionen verwendet werden müssen? (PCI SSC FAQ)
• PCI SSC-Dokumentenbibliothek