TL;DR

Wenn Sie mit Kreditkartendaten umgehen, ist PCI DSS Pflicht. Punkt. Er umfasst die Sicherung von Karteninhaberdaten (CHD) und sensiblen Zugangsdaten (SAD) - Verschlüsselung, Firewalls, Zugangskontrolle, Protokollierung, Scannen, das ganze Paket.

Wenn Sie das nicht tun, riskieren Sie Geldstrafen, Datenschutzverletzungen, Gerichtsverfahren und den Ausschluss von Zahlungsdienstleistern. Compliance ist nicht optional - es geht ums Überleben.

PCI DSS Scorecard Zusammenfassung:

• Entwickelnde Aufwand: Mäßig bis hoch (Erfordert sichere Kodierung, sichere Konfiguration, sorgfältigen Umgang mit Karteninhaberdaten, Einhaltung von Zugangskontrollen, Unterstützung von Schwachstellen-Scans/Protokollierung).
• Tooling-Kosten: Mäßig bis hoch (Firewalls, Schwachstellen-Scanner (ASV-Scans), Überwachung der Dateiintegrität, Protokollierung/SIEM, Verschlüsselungstools, möglicherweise Tokenization/P2PE-Lösungen).
• Auswirkungen auf den Markt: Kritisch (obligatorisch für alle Unternehmen, die mit Zahlungskartendaten umgehen;compliance kann dazu führen, dass Kartenzahlungen nicht mehr verarbeitet werden können).
• Flexibilität: Gering bis mäßig (Die Kernanforderungen sind präskriptiv, aber die spezifischen Umsetzungsmethoden können variieren; v4.0 führt mit dem "maßgeschneiderten Ansatz" mehr Flexibilität ein).
• Intensität der Prüfung: Hoch (Erfordert eine jährliche Validierung durch einen Fragebogen zur Selbsteinschätzung (SAQ) oder einen formellen Bericht über die Compliance (ROC) durch einen qualifizierten Sicherheitsgutachter (QSA) sowie vierteljährliche Schwachstellen-Scans).

Was ist PCI DSS?

Der Payment Card Industry Data Security Standard (PCI DSS) ist ein globaler Informationssicherheitsstandard, der Kreditkartenbetrug durch verstärkte Kontrollen der Datenverarbeitung und -speicherung verhindern soll. Er gilt für jede Organisation, unabhängig von Größe oder Standort, die Karteninhaberdaten (CHD) oder sensible Authentifizierungsdaten (SAD) annimmt, verarbeitet, speichert oder überträgt.

CHD enthält die primäre Kontonummer (PAN), den Namen des Karteninhabers, das Ablaufdatum und den Servicecode. Das SAD umfasst vollständige Track-Daten, Kartenprüfcodes (CVV2, CVC2 usw.) und PINs - das SAD darf niemals nach der Autorisierung gespeichert werden.

PCI DSS wurde von den großen Zahlungskartenherstellern (Visa, Mastercard, American Express, Discover, JCB) geschaffen, die zur Verwaltung des Standards das PCI Security Standards Council (PCI SSC) gegründet haben. Die Compliance wird von den einzelnen Kartenmarken und Acquiring-Banken durchgesetzt, nicht direkt vom PCI SSC.

Der Standard gliedert sich in 6 Ziele, die in 12 Kernanforderungen umgesetzt werden (diese bleiben im Konzept des neueren PCI DSS v4.0 konsistent):

1. Aufbau und Pflege eines sicheren Netzwerks und sicherer Systeme:
   
   • Anforderung 1: Installation und Wartung von Netzsicherheitskontrollen (Firewalls).
   • Anforderung 2: Anwendung sicherer Konfigurationen auf alle Systemkomponenten.
2. Kontodaten schützen:
   
   • Anforderung 3: Schutz der gespeicherten Kontodaten (z. B. Verschlüsselung der PAN).
   • Anforderung 4: Schutz der Karteninhaberdaten durch starke Verschlüsselung bei der Übertragung über offene, öffentliche Netze.
3. Aufrechterhaltung eines Programms zur Verwaltung von Schwachstellen:
   
   • Anforderung 5: Schutz aller Systeme und Netze vor bösartiger Software.
   • Anforderung 6: Entwicklung und Wartung sicherer Systeme und Software (Patches, sichere Kodierung).
4. Implementierung strenger Zugangskontrollmaßnahmen:
   
   • Anforderung 7: Beschränkung des Zugriffs auf Systemkomponenten und Karteninhaberdaten nach dem Kriterium "Kenntnis erforderlich".
   • Anforderung 8: Identifizierung von Benutzern und Authentifizierung des Zugangs zu Systemkomponenten.
   • Anforderung 9: Beschränkung des physischen Zugangs zu Karteninhaberdaten.
5. Regelmäßige Überwachung und Prüfung der Netze:
   
   • Anforderung 10: Protokollierung und Überwachung aller Zugriffe auf Systemkomponenten und Karteninhaberdaten.
   • Anforderung 11: Regelmäßige Überprüfung der Sicherheit von Systemen und Netzen (Schwachstellen-Scans, Penetrationstests).
6. Beibehaltung einer Informationssicherheitspolitik:
   
   • Anforderung 12: Unterstützung der Informationssicherheit durch organisatorische Richtlinien und Programme.

Die Validierung der Compliance hängt vom Umfang der jährlich verarbeiteten Transaktionen ab (Händlerstufen 1-4, Dienstleisterstufen 1-2) und reicht von jährlichen Fragebögen zur Selbsteinschätzung (Self-Assessment Questionnaires, SAQs) bis hin zu formellen Vor-Ort-Prüfungen durch einen qualifizierten Sicherheitsgutachter (Qualified Security Assessor, QSA), die zu einem Compliance (Report on Compliance , ROC) führen. Vierteljährliche externe Schwachstellen-Scans durch einen zugelassenen Scanning-Anbieter (ASV) sind in der Regel erforderlich. PCI DSS v4.0 ist die aktuelle Version, deren Anforderungen bis zum 31. März 2025 verbindlich werden.

Warum ist sie wichtig?

Für jedes Unternehmen, das mit Zahlungskartendaten in Berührung kommt, ist die compliance PCI DSS unerlässlich:

• Für die Kartenakzeptanz erforderlich: Sie wird von den großen Kartenmarken durch Verträge mit den akquirierenden Banken vorgeschrieben. Die compliance kann dazu führen, dass Kartenzahlungen nicht mehr akzeptiert werden.
• Verhindert Datenverletzungen: Durch die Implementierung von PCI DSS-Kontrollen wird das Risiko von kostspieligen Verstößen gegen Karteninhaberdaten erheblich reduziert.
• Vermeidet schwerwiegende Strafen: Die compliance von Vorschriften kann zu erheblichen monatlichen Geldstrafen seitens der erwerbenden Banken/Kartenmarken führen (zwischen 5.000 und 100.000 $ pro Monat), selbst wenn kein Verstoß vorliegt.
• Reduziert die Auswirkungen eines Verstoßes: Wenn es zu einem Verstoß kommt, beweist die Einhaltung des PCI DSS die gebotene Sorgfalt und kann möglicherweise Geldstrafen, rechtliche Haftung und Entschädigungskosten (z. B. Gebühren für die Neuausstellung von Karten) reduzieren.
• Stärkt das Vertrauen der Kunden: Compliance zeigt den Kunden, dass Sie die Sicherheit ihrer Zahlungsdaten ernst nehmen, und fördert das Vertrauen und die Loyalität.
• Schützt den Ruf der Marke: Eine Verletzung der Kartendaten schadet dem Ruf eines Unternehmens erheblich. PCI DSS hilft, dies zu verhindern.
• Bietet eine Sicherheits-Basislinie: Bietet einen soliden Basis-Sicherheitsrahmen, der nicht nur für Zahlungsdaten, sondern für die gesamte Sicherheitslage des Unternehmens von Vorteil ist.

PCI DSS zu ignorieren ist für Unternehmen, die Zahlungskarten akzeptieren wollen, einfach keine Option.

Was und wie umsetzen (technisch und politisch)

Die Umsetzung von PCI DSS beinhaltet die Erfüllung aller 12 Kernanforderungen durch technische Kontrollen und dokumentierte Richtlinien/Verfahren. Zu den Schlüsselbereichen mit Auswirkungen auf Entwicklung und Betrieb gehören:

1. Sicheres Netz (Anforderung 1 und 2):
   
   • Implementierung und Wartung von Firewalls, um das Cardholder Data Environment (CDE) von anderen Netzwerken zu trennen.
   • Verwenden Sie sichere Konfigurationen: Ändern Sie die Standardeinstellungen des Herstellers, deaktivieren Sie unnötige Dienste/Ports, härten Sie Systeme ab. Nachweise: Firewall-Regelsätze, Konfigurationsstandards, Netzwerkdiagramme.
2. Schutz von Karteninhaberdaten (Anforderung 3 und 4):
   
   • Minimieren Sie die Speicherung: Speichern Sie Karteninhaberdaten nur, wenn es unbedingt notwendig ist. Speichern Sie SAD niemals nach der Autorisierung.
   • PAN maskieren: Maskieren Sie die Primary Account Number (PAN), wenn sie angezeigt wird (nur die ersten 6/letzten 4 Ziffern sind sichtbar).
   • PAN verschlüsseln: Das gespeicherte PAN mit starker Kryptographie (z.B. AES-256) und robuster Schlüsselverwaltung unlesbar machen.
   • Verschlüsseln Sie die Übertragung: Verschlüsseln Sie CHD während der Übertragung über offene/öffentliche Netze (verwenden Sie starke TLS-Versionen, sichere Protokolle). Beweise: Datenaufbewahrungspolitik, Datenflussdiagramme, Verschlüsselungskonfiguration, Schlüsselverwaltungsverfahren.
3. Schwachstellenmanagement (Anforderung 5 und 6):
   
   • Anti-Malware: Einsatz und regelmäßige Aktualisierung von Anti-Malware-Lösungen auf Systemen, die häufig von Malware betroffen sind.
   • Patching: Implementierung eines Verfahrens zur zeitnahen Identifizierung und Anwendung von Sicherheits-Patches (innerhalb festgelegter Zeitrahmen für kritische Patches).
   • Sichere Kodierung: Entwicklung von Softwareanwendungen (intern oder kundenspezifisch) auf der Grundlage von Richtlinien für sichere Kodierung (z. B. OWASP), Schulung von Entwicklern, Behebung allgemeiner Kodierungsschwachstellen (Injektion, XSS usw.). Nachweise: Aufzeichnungen zum Patch-Management, Richtlinien zur sicheren Kodierung, Aufzeichnungen zur Entwicklerschulung, SAST/DAST-Ergebnisse.
4. Zugangskontrolle (Anforderung 7, 8, 9):
   
   • Geringste Rechte/Need-to-Know: Beschränkung des Zugriffs auf CHD- und Systemkomponenten auf der Grundlage der Arbeitsrolle und der erforderlichen Mindestberechtigungen.
   • Eindeutige IDs und Authentifizierung: Vergeben Sie eindeutige IDs für den Zugang; implementieren Sie eine starke Authentifizierung (komplexe Passwörter/Passphrasen, MFA - insbesondere für den CDE-Zugang).
   • Physische Sicherheit: Sicherer physischer Zugang zu Systemen, die CHD speichern/verarbeiten. Nachweise: Zugangskontrollrichtlinien, RBAC-Konfiguration, MFA-Einstellungen, Passwortrichtlinien, Protokolle über den physischen Zugang.
5. Überwachung und Prüfung (Anforderung 10 und 11):
   
   • Protokollierung: Implementierung einer detaillierten Audit-Protokollierung für alle Systemkomponenten; Verfolgung des Zugriffs auf Netzressourcen und CHD. Schützen Sie die Protokolle vor Manipulationen. Verwenden Sie Zeitsynchronisation (NTP).
   • Überprüfung der Protokolle: Überprüfen Sie die Protokolle regelmäßig auf verdächtige Aktivitäten.
   • Scannen auf Schwachstellen: Führen Sie vierteljährlich externe ASV-Scans und interne Schwachstellen-Scans durch. Behebung von Schwachstellen.
   • Penetrationstests: Führen Sie jährlich interne/externe Penetrationstests durch (und nach wesentlichen Änderungen).
   • Intrusion Detection/Prevention: IDS/IPS implementieren.
   • Erkennung von Änderungen: Verwenden Sie die Dateiintegritätsüberwachung (FIM) für kritische Dateien. Beweise: Protokollprüfungsverfahren, SIEM-Konfiguration, ASV-Scan-Berichte, Pentest-Berichte, FIM-Protokolle.
6. Politik der Informationssicherheit (Anforderung 12):
   
   • Beibehaltung einer umfassenden Informationssicherheitspolitik, jährliche Überprüfung und Verteilung an das zuständige Personal.
   • Festlegung von Sicherheitsverantwortlichkeiten, Durchführung von Sensibilisierungsmaßnahmen.
   • Implementierung eines Reaktionsplans für Zwischenfälle und dessen Überprüfung. Beweise: InfoSec-Richtliniendokument, Schulungsunterlagen, Plan für die Reaktion auf Zwischenfälle und Testergebnisse.

PCI DSS v4.0 führt Aktualisierungen wie strengere Passwort-/MFA-Anforderungen, eine breitere Anwendbarkeit von Kontrollen, neue Anforderungen für Phishing-Prävention und Skriptsicherheit auf Zahlungsseiten ein und erlaubt neben dem traditionellen "definierten Ansatz" auch einen "maßgeschneiderten Ansatz" zur Erfüllung der Anforderungen unter bestimmten Bedingungen.

Häufig zu vermeidende Fehler

Das Erreichen und Aufrechterhalten der PCI compliance ist oft eine Herausforderung. Vermeiden Sie diese häufigen Fehler:

1. Falsches Scoping: Es werden nicht alle Systeme, Netze und Anwendungen genau identifiziert, die CHD speichern, verarbeiten oder übermitteln oder die Sicherheit des ZDE beeinträchtigen könnten. Dies ist der kritischste Fehler.
2. Speicherung von sensiblen Authentifizierungsdaten (SAD): Illegale Speicherung von CVV2, vollständigen Trackdaten oder PIN-Daten nach der Autorisierung.
3. Unzureichender Schutz der Daten: Speicherung unverschlüsselter PANs, Verwendung schwacher Verschlüsselung/Schlüsselverwaltung oder Übermittlung von CHD über unsichere Kanäle.
4. Schwache Zugangskontrolle: Verwendung gemeinsamer/standardmäßiger Anmeldeinformationen, fehlende MFA für den CDE-Zugang, fehlende Durchsetzung der geringsten Berechtigung, nicht rechtzeitiger Entzug des Zugangs.
5. Unzureichende Protokollierung und Überwachung: Keine Protokollierung relevanter Ereignisse, keine regelmäßige Überprüfung der Protokolle oder kein Schutz der Protokolle vor Manipulationen.
6. Vernachlässigung des Schwachstellenmanagements: Überspringen der vierteljährlichen ASV-Scans, Versagen bei internen Scans, nicht rechtzeitige Behebung kritischer Sicherheitslücken.
7. Unzureichende Praktiken der sicheren Kodierung: Entwicklung von Anwendungen mit häufigen Sicherheitslücken (SQLi, XSS), die CHD aufdecken.
8. Vernachlässigung von Grundsätzen und Verfahren: Fehlen von dokumentierten Richtlinien, Verfahren oder einem Plan zur Reaktion auf Zwischenfälle oder Versäumnis, die Mitarbeiter zu schulen.
9. Compliance durch die Anbieter: Die Annahme, dass Drittanbieter die Vorschriften einhalten, ohne dies zu überprüfen oder entsprechende vertragliche Vereinbarungen zu treffen.
10. Behandlung der Compliance als jährlich: Betrachtung von PCI DSS als ein jährliches Audit/SAQ anstelle eines kontinuierlichen Sicherheitsprozesses.

Was Prüfer/QSAs fragen könntenEntwickelnde Focus)

Ein qualifizierter Sicherheitsbewerter (QSA), der für PCI DSS auditiert, wird die Entwicklungspraktiken in Bezug auf Anforderung 6 (sichere Systeme und Software) untersuchen:

• (Anforderung 6.2) "Beschreiben Sie Ihre Prozesse für den sicheren Softwareentwicklungszyklus (SSDLC)".
• (Anforderung 6.2.1) "Wie werden kundenspezifische und maßgeschneiderte Software auf der Grundlage von Industriestandards und/oder PCI DSS (z. B. sichere Codierungsrichtlinien wie OWASP) entwickelt?"
• (Anforderung 6.2.2) "Wie werden Entwickler in sicheren Kodierungstechniken geschult?" (Schulungsunterlagen zeigen)
• (Anforderung 6.2.3) "Wie werden Codeänderungen vor der Freigabe auf Sicherheitsschwachstellen überprüft?" (Beschreiben Sie den Prozess der Codeüberprüfung)
• (Req 6.2.4) "Wie stellen Sie die Aufgabentrennung zwischen Entwicklungs-/Test- und Produktionsumgebung sicher?"
• (Anforderung 6.3) "Wie identifizieren und inventarisieren Sie maßgeschneiderte und kundenspezifische Software?"
• (Req 6.4 - v4.0) "Wie verwalten Sie Skripte für Zahlungsseiten, um die Integrität sicherzustellen und Skripte zu autorisieren?" (Relevant für Webentwickler)
• (Req 6.5 - v3.2.1 / diverse in v4.0) "Wie schützen Sie sich gegen allgemeine Schwachstellen in der Programmierung wie Injektionsfehler, Pufferüberläufe, unsichere kryptografische Speicherung, XSS usw.?" (Erfordert das Zeigen von Codebeispielen, Verwendung von Tools - SAST/DAST)
• (Req 3) "Zeigen Sie, wie sensible Daten (PAN) bei der Speicherung in der Anwendung geschützt werden (Verschlüsselung, Hashing, Trunkierung)."
• (Anforderung 4) "Zeigen Sie, wie sensible Daten während der Übertragung verschlüsselt werden."
• (Anforderung 8) "Wie setzt die Anwendung die Komplexität von Passwörtern und MFA-Anforderungen durch?"

QSAs benötigen Nachweise über dokumentierte Prozesse, Entwicklerschulungen, die Einhaltung von Standards für sichere Kodierung, Code-Reviews, Ergebnisse von Sicherheitstests (SAST/DAST) und eine sichere Konfiguration innerhalb der Anwendung.

Quick Wins für Entwicklungsteams

Entwickler können wesentlich zur compliance PCI DSS beitragen:

1. NEVER Store SAD: Stellen Sie sicher, dass der Code niemals CVV2, Track-Daten oder PINs nach der Autorisierung protokolliert, speichert oder aufbewahrt.
2. Minimieren Sie die Handhabung von CHD: Verwenden Sie nach Möglichkeit Drittanbieter-Zahlungsabwickler/Gateways, die CHD vollständig von Ihren Systemen fernhalten (was den Umfang reduziert). Wenn Sie sie verarbeiten müssen, minimieren Sie den Ort, an dem sie fließen und gespeichert werden.
3. Grundlagen der sicheren Kodierung: Schwerpunkt auf der Vermeidung der OWASP Top 10 Schwachstellen, insbesondere Injektion (SQLi, Befehlsinjektion) und Cross-Site Scripting (XSS), durch Eingabevalidierung und Ausgabeverschlüsselung.
4. Parametrisieren Sie Datenbankabfragen: Verwenden Sie immer vorbereitete Anweisungen oder parametrisierte Abfragen, um SQL-Injection zu verhindern.
5. Verschlüsselung/Hash/Tokenisierung von PAN: Verwenden Sie bei der Speicherung von PAN eine starke Standardverschlüsselung (AES-256) mit angemessener Schlüsselverwaltung oder ziehen Sie Tokenisierungslösungen in Betracht. Entwickeln Sie nicht Ihre eigene Verschlüsselung.
6. Verwenden Sie starkes TLS: Stellen Sie sicher, dass alle CHD-Übertragungen aktuelle, sichere TLS-Versionen und starke Cipher Suites verwenden.
7. Eingabevalidierung implementieren: Strenge Validierung aller Eingaben von Benutzern oder externen Systemen.
8. Sicherheits-Header anwenden: Verwenden Sie HTTP-Sicherheits-Header (wie Content-Security-Policy), um XSS und andere clientseitige Angriffe abzuschwächen, besonders wichtig für Req 6.4 in v4.0.

Ignorieren Sie dies und... (Folgen der Compliance)

Die Nichtbeachtung von PCI DSS kann zu finanziellen Einbußen führen und den Ruf schädigen:

• Monatliche Geldbußen: Acquiring-Banken erheben beicompliance saftige Bußgelder, die in der Regel zwischen 5.000 und 100.000 $ pro Monat liegen und je nach Grad der compliance und Dauer dercompliance steigen.
• Erhöhte Transaktionsgebühren: Die Banken können die Transaktionsgebühren für nicht konforme Händler erhöhen.
• Sanktionen der Kartenmarke: Kartenmarken können direkt zusätzliche Sanktionen verhängen.
• Beendigung der Kartenverarbeitung: Die Banken können die Fähigkeit, Zahlungskarten zu akzeptieren, vollständig widerrufen, wodurch die Einnahmequellen für Kartenzahlungen praktisch zum Erliegen kommen.
• Kosten für Datenverletzungen: Wenncompliance zu einem Verstoß führt, steigen die Kosten in die Höhe. Dazu gehören forensische Untersuchungen, Kosten für den Ersatz von Karten ($3-5+ pro Karte), Kreditüberwachung für die Opfer, Anwaltskosten, Bußgelder (z. B. GDPR, falls zutreffend) und potenzielle Gerichtsverfahren.
• Schädigung des Rufs: Die öffentliche Bekanntgabe voncompliance oder einer Verletzung der Kartendaten schadet dem Vertrauen der Kunden und dem Image der Marke erheblich.
• Verstärkte Kontrolle: Nach einercompliance oder einer Sicherheitsverletzung werden die Unternehmen von Banken und Kartenherstellern intensiver geprüft.

FAQ

Wer muss PCI DSS-konform sein?

Jede Organisation, die Karteninhaberdaten der großen Kartenmarken (Visa, Mastercard, American Express, Discover, JCB) annimmt, verarbeitet, speichert oder überträgt. Dazu gehören Händler, Dienstleister (wie Zahlungsabwickler, Hosting-Anbieter) und Finanzinstitute.

Was ist der Unterschied zwischen PCI DSS v3.2.1 und v4.0?

PCI DSS v4.0 ist die neueste Version und ersetzt v3.2.1 (die am 31. März 2024 außer Kraft tritt, obwohl die neuen v4.0-Anforderungen bis zum 31. März 2025 als Best Practices gelten). Zu den wichtigsten Änderungen in Version 4.0 gehören aktualisierte Passwort-/MFA-Anforderungen, eine breitere Anwendbarkeit von Sicherheitskontrollen, neue Anforderungen, die auf Phishing- und E-Commerce-Skimming-Angriffe abzielen, klarere Anleitungen und die Einführung eines "maßgeschneiderten Ansatzes" als alternative Möglichkeit zur Erfüllung der Anforderungsziele neben dem traditionellen "definierten Ansatz".

Was sind Händler-/Dienstleisterebenen?

Diese kategorisieren die Unternehmen nach dem jährlichen Volumen der von ihnen verarbeiteten Kartentransaktionen. Stufe 1 (höchstes Volumen) hat die strengsten Validierungsanforderungen (jährliches ROC durch QSA, vierteljährliche ASV-Scans). Die Stufen 2, 3 und 4 weisen ein geringeres Volumen auf und werden in der Regel durch jährliche SAQs und vierteljährliche ASV-Scans validiert.

Was ist ein QSA und ein ASV?

Ein QSA (Qualified Security Assessor) ist eine Person, die vom PCI SSC für die Durchführung von PCI DSS-Bewertungen vor Ort und die Erstellung von Compliance (ROCs) für Händler/Dienstleister der Stufe 1 zertifiziert ist. Ein ASV (Approved Scanning Vendor) ist eine Organisation, die vom PCI SSC für die Durchführung der vorgeschriebenen vierteljährlichen externen Netzwerk-Schwachstellen-Scans zertifiziert ist.

Was ist das Cardholder Data Environment (CDE)?

Das CDE umfasst die Personen, Prozesse und Technologien, die Karteninhaberdaten oder sensible Authentifizierungsdaten speichern, verarbeiten oder übertragen. Die genaue Definition des Umfangs des CDE ist der entscheidende erste Schritt zur compliance PCI DSS, da die Anforderungen hauptsächlich in dieser Umgebung gelten. Durch Netzwerksegmentierung kann der Umfang des CDE reduziert werden.

Können wir den CVV2-Code speichern?

Nein. Sensible Authentifizierungsdaten (SAD), zu denen der drei- oder vierstellige Kartenprüfcode (CVV2, CVC2, CID, CAV2), die vollständigen Magnetstreifendaten und PINs gehören, dürfen niemals gespeichert werden, nachdem die Transaktionsautorisierung abgeschlossen ist. Die Speicherung von SAD ist ein schwerwiegender Verstoß gegen compliance .

Ist die compliance PCI DSS gesetzlich vorgeschrieben?

PCI DSS ist zwar ein von den Kartenmarken geschaffener Industriestandard, aber die compliance wird in der Regel vertraglich durch Vereinbarungen zwischen Händlern, akquirierenden Banken und den Kartenmarken vorgeschrieben. Bei Nichteinhaltung werden diese Verträge gebrochen, was zu den von den Banken/Marken verhängten Strafen führt. Außerdem kann es zu Überschneidungen mit rechtlichen Anforderungen wie der Datenschutz-Grundverordnung kommen, wenn personenbezogene Daten betroffen sind.