TL;DR

Wenn Sie Kreditkartendaten verarbeiten, ist PCI DSS zwingend erforderlich. Punkt. Es deckt ab, wie Karteninhaberdaten (CHD) und sensible Authentifizierungsdaten (SAD) gesichert werden – Verschlüsselung, Firewalls, Zugriffskontrolle, Protokollierung, Scanning, das volle Programm.

Wenn Sie darauf verzichten, riskieren Sie Bußgelder, Sicherheitsverletzungen, Klagen und den Ausschluss durch Zahlungsdienstleister. Compliance ist nicht optional – sie ist überlebenswichtig.

PCI DSS Scorecard-Zusammenfassung:

• Aufwand für Entwickelnde: Moderat bis Hoch (Erfordert sichere Programmierung, sichere Konfiguration, sorgfältigen Umgang mit Karteninhaberdaten, Einhaltung von Zugriffskontrollen und Unterstützung von Schwachstellenscans/Protokollierung).
• Tooling-Kosten: Moderat bis hoch (Firewalls, Schwachstellenscanner (ASV-Scans), Dateiintegritätsüberwachung, Protokollierung/SIEM, Verschlüsselungstools, potenziell Tokenisierungs-/P2PE-Lösungen).
• Marktauswirkungen: Kritisch (Obligatorisch für jede Entität, die Zahlungskartendaten verarbeitet; Nicht-Compliance kann zur Unfähigkeit führen, Kartenzahlungen zu verarbeiten).
• Flexibilität: Gering bis Moderat (Kernanforderungen sind präskriptiv, aber spezifische Implementierungsmethoden können variieren; v4.0 führt mehr Flexibilität mit dem „customized approach“ ein).
• Prüfungsintensität: Hoch (Erfordert jährliche Validierung mittels Self-Assessment Questionnaire (SAQ) oder formellem Report on Compliance (ROC) durch einen Qualified Security Assessor (QSA), plus vierteljährliche Schwachstellenscans).

Was ist PCI DSS?

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

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

PCI DSS wurde von den großen Zahlungskartenmarken (Visa, Mastercard, American Express, Discover, JCB) ins Leben gerufen, die den PCI Security Standards Council (PCI SSC) gründeten, um den Standard zu verwalten. Compliance von den einzelnen Kartenmarken und akquirierenden Banken durchgesetzt, nicht direkt vom PCI SSC.

Der Standard ist um 6 Ziele herum aufgebaut, die sich in 12 Kernanforderungen übersetzen (diese bleiben im Konzept für die neuere PCI DSS v4.0 konsistent):

1. Ein sicheres Netzwerk und Systeme aufbauen und pflegen:
   
   • Anforderung 1: Installieren und warten Sie Netzwerksicherheitskontrollen (Firewalls).
   • Anforderung 2: Wenden Sie sichere Konfigurationen auf alle Systemkomponenten an.
2. Kontodaten schützen:
   
   • Anforderung 3: Schützen Sie gespeicherte Kontodaten (z. B. PAN verschlüsseln).
   • Anforderung 4: Schützen Sie Karteninhaberdaten mit starker Kryptografie während der Übertragung über offene, öffentliche Netzwerke.
3. Ein Schwachstellenmanagement unterhalten:
   
   • Anforderung 5: Schützen Sie alle Systeme und Netzwerke vor bösartiger Software.
   • Anforderung 6: Entwickeln und warten Sie sichere Systeme und Software (Patching, sichere Codierung).
4. Starke Zugriffskontrollmaßnahmen implementieren:
   
   • Anforderung 7: Beschränken Sie den Zugriff auf Systemkomponenten und Karteninhaberdaten nach dem Prinzip der geschäftlichen Notwendigkeit (Need-to-know).
   • Anforderung 8: Identifizieren Sie Benutzer und authentifizieren Sie den Zugriff auf Systemkomponenten.
   • Anforderung 9: Beschränken Sie den physischen Zugriff auf Karteninhaberdaten.
5. Netzwerke regelmäßig überwachen und testen:
   
   • Anforderung 10: Protokollieren und überwachen Sie alle Zugriffe auf Systemkomponenten und Karteninhaberdaten.
   • Anforderung 11: Testen Sie die Sicherheit von Systemen und Netzwerken regelmäßig (Schwachstellenscans, Penetrationstests).
6. Eine Informationssicherheitsrichtlinie pflegen:
   
   • Anforderung 12: Unterstützen Sie die Informationssicherheit durch organisatorische Richtlinien und Programme.

Die Compliance-Validierung variiert je nach dem jährlich verarbeiteten Transaktionsvolumen (Händlerstufen 1-4, Dienstleisterstufen 1-2) und reicht von jährlichen Self-Assessment Questionnaires (SAQs) bis hin zu formellen Vor-Ort-Audits durch einen Qualified Security Assessor (QSA), die zu einem Report on Compliance (ROC) führen. Vierteljährliche externe Schwachstellenscans durch einen Approved Scanning Vendor (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 es wichtig?

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

• Erforderlich für die Kartenakzeptanz: Es wird von den großen Kartenmarken durch Verträge mit den Acquirer-Banken vorgeschrieben. Non-Compliance kann dazu führen, dass keine Kartenzahlungen akzeptiert werden können.
• Verhindert Datenschutzverletzungen: Die Implementierung von PCI DSS-Kontrollen reduziert das Risiko kostspieliger Kreditkartendaten-Verletzungen erheblich.
• Vermeidet hohe Strafen: Non-Compliance kann zu erheblichen monatlichen Geldstrafen von Acquirer-Banken/Kartenmarken führen (zwischen 5.000 $ und 100.000 $+ pro Monat), selbst wenn keine Sicherheitsverletzung auftritt.
• Reduziert die Auswirkungen von Sicherheitsverletzungen: Sollte es doch zu einer Sicherheitsverletzung kommen, zeigt die PCI-DSS-Compliance die gebotene Sorgfalt und kann potenziell Bußgelder, rechtliche Haftung und Entschädigungskosten (wie Gebühren für die Neuausstellung von Karten) reduzieren.
• Schafft Kundenvertrauen: Compliance zeigt Kunden, dass Sie die Sicherheit ihrer Zahlungsdaten ernst nehmen, was Vertrauen und Loyalität fördert.
• Schützt den Markenruf: Eine Kreditkartendatenpanne schädigt den Ruf eines Unternehmens erheblich. PCI DSS hilft, dies zu verhindern.
• Bietet Sicherheits-Baseline: Bietet ein robustes Sicherheits-Baseline-Framework, das der gesamten Sicherheitslage der Organisation zugutekommt, nicht nur den Zahlungsdaten.

Das Ignorieren von PCI DSS ist für Unternehmen, die Zahlungskarten akzeptieren möchten, schlichtweg keine Option.

Was und wie implementieren (Technisch & Policy)

Die Implementierung von PCI DSS beinhaltet die Erfüllung aller 12 Kernanforderungen durch technische Kontrollen und dokumentierte Richtlinien/Verfahren. Wichtige Bereiche, die Entwicklung und Betrieb betreffen, sind:

1. Sicheres Netzwerk (Anf. 1 & 2):
   
   • Firewalls implementieren und warten, um die Cardholder Data Environment (CDE) von anderen Netzwerken zu segmentieren.
   • Verwenden Sie sichere Konfigurationen: Ändern Sie Hersteller-Standardeinstellungen, deaktivieren Sie unnötige Dienste/Ports, härten Sie Systeme. Nachweis: Firewall-Regelsätze, Konfigurationsstandards, Netzwerkdiagramme.
2. Karteninhaberdaten schützen (Anforderung 3 & 4):
   
   • Speicherung minimieren: Speichern Sie keine Karteninhaberdaten, es sei denn, es ist absolut notwendig. Speichern Sie niemals SAD nach der Autorisierung.
   • PAN maskieren: Maskieren Sie die Primary Account Number (PAN) bei der Anzeige (nur die ersten 6/letzten 4 Ziffern sichtbar).
   • PAN verschlüsseln: Machen Sie gespeicherte PAN unlesbar unter Verwendung starker Kryptografie (z. B. AES-256) und robuster Schlüsselverwaltung.
   • Übertragung verschlüsseln: Verschlüsseln Sie CHD während der Übertragung über offene/öffentliche Netzwerke (verwenden Sie starke TLS-Versionen, sichere Protokolle). Nachweis: Datenaufbewahrungsrichtlinie, Datenflussdiagramme, Verschlüsselungskonfiguration, Schlüsselverwaltungsverfahren.
3. Schwachstellenmanagement Anforderung 5 & 6):
   
   • Anti-Malware: Anti-Malware-Lösungen auf Systemen bereitstellen und regelmäßig aktualisieren, die häufig von Malware betroffen sind.
   • Patching: Implementieren Sie einen Prozess, um Sicherheitspatches zeitnah zu identifizieren und anzuwenden (innerhalb definierter Fristen für kritische Patches).
   • Sichere Programmierung: Entwicklung von Softwareanwendungen (intern oder maßgeschneidert) auf der Grundlage von Richtlinien für sichere Programmierung (z. B. OWASP), Schulung von Entwicklern, Behebung häufiger Programmierfehler (Injection, XSS usw.). Nachweise: Aufzeichnungen zum Patch-Management, Richtlinien zur sicheren Programmierung, Aufzeichnungen zu Entwicklerschulungen,DAST
4. Zugriffskontrolle (Anforderung 7, 8, 9):
   
   • Least Privilege/Need-to-Know: Beschränken Sie den Zugriff auf CHD und Systemkomponenten basierend auf der Aufgabenrolle und den minimal erforderlichen Berechtigungen.
   • Eindeutige IDs & Authentifizierung: Weisen Sie eindeutige IDs für den Zugriff zu; implementieren Sie eine starke Authentifizierung (komplexe Passwörter/Passphrasen, MFA – insbesondere für den CDE-Zugriff).
   • Physische Sicherheit: Physischen Zugang zu Systemen sichern, die CHD speichern/verarbeiten. Nachweis: Zugriffsrichtlinien, RBAC-Konfiguration, MFA-Einstellungen, Passwortrichtlinie, physische Zugriffslogs.
5. Überwachung & Tests (Anforderung 10 & 11):
   
   • Logging: Detailliertes Audit-Logging für alle Systemkomponenten implementieren; Zugriffe auf Netzwerkressourcen und CHD verfolgen. Logs vor Manipulation schützen. Zeitsynchronisation (NTP) verwenden.
   • Log-Überprüfung: Überprüfen Sie regelmäßig Logs auf verdächtige Aktivitäten.
   • Schwachstellen-Scanning: Führen Sie vierteljährlich externe ASV-Scans und interne Schwachstellen-Scans durch. Beheben Sie Schwachstellen.
   • Penetrationstests: Führen Sie jährliche interne/externe Penetrationstests durch (und nach wesentlichen Änderungen).
   • Intrusion Detection/Prevention: Implementieren Sie IDS/IPS.
   • Änderungserkennung: Verwenden Sie File Integrity Monitoring (FIM) für kritische Dateien. Nachweis: Protokollüberprüfungsverfahren, SIEM-Konfiguration, ASV-Scan-Berichte, Pentest-Berichte, FIM-Protokolle.
6. Informationssicherheits-Policy (Anforderung 12):
   
   • Eine umfassende Informationssicherheitsrichtlinie pflegen, jährlich überprüfen und an relevantes Personal verteilen.
   • Definieren Sie Sicherheitsverantwortlichkeiten, führen Sie Sensibilisierungsschulungen durch.
   • Einen Incident-Response-Plan implementieren und testen. Nachweis: InfoSec-Richtliniendokument, Schulungsunterlagen, Incident-Response-Plan & Testergebnisse.

PCI DSS v4.0 führt Aktualisierungen ein, wie strengere Anforderungen an Passwörter/MFA, eine breitere Anwendbarkeit von Kontrollen, neue Anforderungen für die Phishing-Prävention und Skriptsicherheit auf Zahlungsseiten und ermöglicht unter bestimmten Bedingungen einen „maßgeschneiderten Ansatz“ zur Erfüllung der Anforderungen, zusätzlich zum traditionellen „definierten Ansatz“.

Häufige Fehler, die es zu vermeiden gilt

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

1. Falsche Scoping: Das Versäumnis, alle Systeme, Netzwerke und Anwendungen, die CHD speichern, verarbeiten oder übertragen oder die Sicherheit der CDE beeinträchtigen könnten, genau zu identifizieren. Dies ist der kritischste Fehler.
2. Speicherung sensibler Authentifizierungsdaten (SAD): Illegale Speicherung von CVV2, vollständigen Track-Daten oder PIN-Daten nach der Autorisierung.
3. Unzureichender Datenschutz: Speicherung unverschlüsselter PANs, Verwendung schwacher Verschlüsselung/Schlüsselverwaltung oder Übertragung von CHD über unsichere Kanäle.
4. Schwache Zugriffskontrolle: Verwendung von geteilten/Standard-Zugangsdaten, fehlende MFA für CDE-Zugriff, Nicht-Durchsetzung des Prinzips der geringsten Rechte, Versäumnis, Zugriffe umgehend zu entziehen.
5. Unzureichendes Logging & Monitoring: Relevante Ereignisse nicht protokollieren, Protokolle nicht regelmäßig überprüfen oder Protokolle nicht vor Manipulation schützen.
6. Ignorieren Schwachstellenmanagement: Überspringen der vierteljährlichen ASV-Scans, fehlgeschlagene interne Scans, nicht sofortiges Patchen kritischer Schwachstellen.
7. Mangelhafte Secure Coding Practices: Entwicklung von Anwendungen mit gängigen Schwachstellen (SQLi, XSS), die CHD offenlegen.
8. Vernachlässigung von Richtlinien & Verfahren: Fehlende dokumentierte Richtlinien, Verfahren oder ein Incident-Response-Plan, oder das Versäumnis, Mitarbeitende zu schulen.
9. Vendor Compliance: Annahme, dass Drittanbieter konform sind, ohne dies zu überprüfen oder entsprechende vertragliche Vereinbarungen zu treffen.
10. Compliance als jährlich betrachten: PCI DSS nur als jährliches Audit/SAQ ansehen, anstatt als kontinuierlichen Sicherheitsprozess.

Was Auditoren/QSAs fragen könnten (Fokus auf Entwickelnde)

Ein Qualified Security Assessor (QSA), der PCI DSS prüft, wird Entwicklungspraktiken im Zusammenhang mit Anforderung 6 (Sichere Systeme & Software) untersuchen:

• (Req 6.2) „Beschreiben Sie Ihre Prozesse für den sicheren Softwareentwicklungslebenszyklus (SSDLC).“
• (Req 6.2.1) „Wie werden kundenspezifische und maßgeschneiderte Software basierend auf Industriestandards und/oder PCI DSS (z. B. sichere Codierungsrichtlinien wie OWASP) entwickelt?“
• (Req 6.2.2) „Wie werden Entwickelnde in sicheren Codierungstechniken geschult?“ (Schulungsnachweise vorlegen)
• (Req 6.2.3) „Wie werden Codeänderungen vor der Freigabe auf Sicherheitslücken überprüft?“ (Beschreiben Sie den Code-Review-Prozess)
• (Req 6.2.4) „Wie stellen Sie die Aufgabentrennung zwischen Entwicklungs-/Test- und Produktionsumgebungen sicher?“
• (Req 6.3) „Wie identifizieren und inventarisieren Sie maßgeschneiderte und kundenspezifische Software?“
• (Req 6.4 - v4.0) „Wie verwalten Sie Skripte auf Zahlungsseiten, um deren Integrität zu gewährleisten und Skripte zu autorisieren?“ (Relevant für Web-Entwickelnde)
• (Anforderung 6.5 – v3.2.1 / verschiedene in v4.0) „Wie schützen Sie sich vor gängigen Schwachstellen in der Programmierung wie Injection-Schwachstellen, Pufferüberläufen, unsicherer kryptografischer Speicherung, XSS usw.?“ (Erfordert die Angabe von Code-Beispielen, Tool-Verwendung –DAST)
• (Req 3) „Zeigen Sie, wie sensible Daten (PAN) im Speicher (Verschlüsselung, Hashing, Truncation) innerhalb der Anwendung geschützt werden.“
• (Req 4) „Demonstrieren Sie, wie sensible Daten während der Übertragung verschlüsselt werden.“
• (Req 8) „Wie erzwingt die Anwendung Anforderungen an die Passwortkomplexität und MFA?“

QSAs benötigen Nachweise über dokumentierte Prozesse, Entwicklerschulungen, die Einhaltung sicherer Codierungsstandards, Codeüberprüfungen, Ergebnisse von Sicherheitstests (DAST) und eine sichere Konfiguration innerhalb der Anwendung.

Quick Wins für Entwicklungsteams

Entwickelnde können maßgeblich zur PCI DSS Compliance beitragen:

1. SAD niemals speichern: Sicherstellen, dass Code niemals CVV2, Track-Daten oder PINs nach der Autorisierung protokolliert, speichert oder aufbewahrt.
2. CHD-Verarbeitung minimieren: Wenn möglich, nutzen Sie Zahlungsdienstleister/Gateways von Drittanbietern, die CHD vollständig von Ihren Systemen fernhalten (wodurch der Umfang reduziert wird). Wenn Sie es verarbeiten müssen, minimieren Sie, wohin es fließt und wo es gespeichert wird.
3. Grundlagen der sicheren Programmierung: Konzentrieren Sie sich auf die Vermeidung OWASP Top 10 , insbesondere Injection (SQLi, Befehlsinjection) und Cross-Site-Scripting, durch Eingabevalidierung und Ausgabeverschlüsselung.
4. Datenbankabfragen parametrisieren: Verwenden Sie immer Prepared Statements oder parametrisierte Abfragen, um SQL-Injection zu verhindern.
5. PAN verschlüsseln/hashen/tokenisieren: Wenn PAN gespeichert wird, verwenden Sie eine starke, standardmäßige Verschlüsselung (AES-256) mit ordnungsgemäßer Schlüsselverwaltung oder ziehen Sie Tokenisierungslösungen in Betracht. Verwenden Sie keine eigene Kryptografie.
6. Starkes TLS verwenden: Stellen Sie sicher, dass alle CHD-Übertragungen aktuelle, sichere TLS-Versionen und starke Cipher Suites verwenden.
7. Input-Validierung implementieren: Validieren Sie rigoros alle 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 zu mindern, was besonders wichtig für Anforderung 6.4 in v4.0 ist.

Ignorieren Sie dies und... (Konsequenzen der Nichteinhaltung)

Das Ignorieren von PCI DSS kann finanziell lähmend und rufschädigend sein:

• Monatliche Bußgelder: Akquirierende Banken verhängen hohe Bußgelder bei Nichteinhaltung der Compliance, die typischerweise zwischen 5.000 und 100.000+ US-Dollar pro Monat liegen und je nach Compliance-Level und Dauer der Nichteinhaltung steigen.
• Erhöhte Transaktionsgebühren: Banken können die Transaktionsgebühren für nicht-Compliance-konforme Händler erhöhen.
• Strafen der Kartenmarken: Kartenmarken können direkt zusätzliche Strafen verhängen.
• Beendigung der Kartenverarbeitung: Banken können die Möglichkeit, Zahlungskarten zu akzeptieren, vollständig entziehen, wodurch Einnahmequellen aus Kartenzahlungen effektiv eingestellt werden.
• Kosten bei Datenlecks: Wenn die Nichteinhaltung zu einem Datenleck führt, schießen die Kosten in die Höhe. Dies umfasst forensische Untersuchungen, Kosten für den Kartenaustausch (3-5 $+ pro Karte), Kreditüberwachung für Opfer, Anwaltskosten, behördliche Bußgelder (z. B. DSGVO, falls zutreffend) und potenzielle Klagen.
• Reputationsschaden: Die öffentliche Offenlegung von Non-Compliance oder einer Kreditkartendatenpanne schädigt das Kundenvertrauen und das Markenimage erheblich.
• Erhöhte Kontrolle: Nach einer Nichteinhaltung der Compliance oder einer Sicherheitsverletzung sehen sich Organisationen einer intensiveren Kontrolle durch Banken und Kartenanbieter gegenüber.

FAQ

Wer muss PCI DSS konform sein?

Jede Organisation, die Daten von Karteninhabern der großen Kreditkartenunternehmen (Visa, Mastercard, American Express, Discover, JCB) akzeptiert, verarbeitet, speichert oder übermittelt. 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 ausläuft, wobei neue v4.0-Anforderungen bis zum 31. März 2025 als Best Practices gelten). Wesentliche Änderungen in v4.0 umfassen aktualisierte Anforderungen an Passwörter/MFA, eine breitere Anwendbarkeit von Sicherheitskontrollen, neue Anforderungen zur Bekämpfung von Phishing- und E-Commerce-Skimming-Angriffen, klarere Leitlinien und die Einführung eines „maßgeschneiderten Ansatzes“ als alternative Methode zur Erfüllung der Anforderungsziele neben dem traditionellen „definierten Ansatz“.

Was sind Händlerstufen / Dienstleisterstufen?

Diese kategorisieren Organisationen basierend auf dem jährlichen Volumen der von ihnen verarbeiteten Kartentransaktionen. Stufe 1 (höchstes Volumen) hat die strengsten Validierungsanforderungen (jährlicher ROC durch QSA, vierteljährliche ASV-Scans). Stufen 2, 3 und 4 haben sukzessive geringere Volumina und validieren typischerweise über jährliche SAQs und vierteljährliche ASV-Scans.

Was sind ein QSA und ein ASV?

Ein QSA (Qualified Security Assessor) ist eine vom PCI SSC zertifizierte Person, die PCI DSS-Assessments vor Ort durchführt und Reports on Compliance (ROCs) für Level-1-Händler/Dienstleister erstellt. Ein ASV (Approved Scanning Vendor) ist eine vom PCI SSC zertifizierte Organisation, die die erforderlichen vierteljährlichen externen Netzwerkschwachstellen-Scans durchführt.

Was ist die 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 PCI DSS Compliance, da die Anforderungen hauptsächlich innerhalb dieser Umgebung gelten. Netzwerksegmentierung kann verwendet werden, um den Umfang des CDE zu reduzieren.

Können wir den CVV2-Code speichern?

Nein. Sensible Authentifizierungsdaten (SAD), zu denen der 3- oder 4-stellige Kartenprüfcode (CVV2, CVC2, CID, CAV2), vollständige Magnetstreifendaten und PINs gehören, dürfen niemals gespeichert werden, nachdem die Transaktionsautorisierung abgeschlossen ist. Das Speichern von SAD ist ein schwerwiegender Compliance-Verstoß.

Ist die PCI DSS-Compliance gesetzlich vorgeschrieben?

Während PCI DSS ein von Kartenmarken geschaffener Industriestandard ist, wird die Compliance typischerweise vertraglich durch Vereinbarungen zwischen Händlern, Acquirer-Banken und den Kartenmarken vorgeschrieben. Die Nichteinhaltung verletzt diese Verträge und führt zu den von den Banken/Marken durchgesetzten Strafen. Sie kann sich auch mit gesetzlichen Anforderungen wie der DSGVO überschneiden, wenn personenbezogene Daten betroffen sind.