PCI-DSS-Compliance für Cloud-native Banking 2026

Was ist PCI DSS und wer muss compliant sein?

PCI DSS - der Payment Card Industry Data Security Standard - ist ein globales Regelwerk für technische und organisatorische Sicherheitsmaßnahmen. Es gilt für jedes Unternehmen, das Kartendaten speichert, verarbeitet oder überträgt. Herausgeber ist der PCI Security Standards Council, gegründet von Visa, Mastercard, American Express, Discover und JCB.

Wer eine Primärkontennummer (PAN) in irgendeiner Form berührt, fällt unter PCI DSS. Das umfasst Kartenausgeber, Zahlungsabwickler, Acquiring-Banken, Fintech-Plattformen mit Kartentransaktionen sowie SaaS-Dienste, die im Datenpfad zwischen Karteninhaber und Kartennetzwerk liegen.

Seit dem 31. März 2025 ist PCI DSS v4.0.1 die einzig gültige Version. Alle 64 neuen oder aktualisierten Anforderungen aus v4.0 sind jetzt verbindlich - die Übergangsfrist ist abgelaufen. In Deutschland betreffen diese Anforderungen Banken und Zahlungsdienstleister, die ohnehin den BaFin-Vorgaben aus BAIT und MaRisk unterliegen. Viele PCI-Kontrollen überschneiden sich mit diesen Anforderungen, was eine integrierte Compliance-Strategie wirtschaftlich sinnvoll macht.

Bei Nicht-Compliance drohen monatliche Strafen der Acquirer-Banken von 5.000 bis 100.000 EUR je nach Verstoßdauer, forensische Untersuchungen im Schadenfall sowie der Entzug der Kartenakzeptanz. Datenschutzverletzungen bei Kartendaten lösen in Deutschland zusätzlich DSGVO-Meldepflichten gegenüber der Datenschutzbehörde und dem BSI aus.

Die 12 Anforderungen kompakt für Banking erklärt

PCI DSS v4.0.1 gliedert seine Kontrollen in 12 Anforderungsfamilien, geordnet nach sechs Zielen. Die folgende Tabelle ordnet jede Anforderung den für Fintechs und Cloud-native Banken relevantesten Maßnahmen zu.

Im deutschen Regulierungskontext ergänzen sich PCI DSS und die BaFin-BAIT (Bankaufsichtliche Anforderungen an die IT) in vielen Punkten: Anforderungen an Berechtigungsmanagement, Protokollierung und Incident-Management decken sich weitgehend. Wer BAIT-konform ist, hat die Hälfte der PCI-Arbeit bereits erledigt - und umgekehrt.

PCI DSS in Cloud-nativen und Container-Umgebungen

Die klassischen PCI-DSS-Leitlinien wurden für Serverräume mit festen IP-Bereichen geschrieben. Cloud-native Umgebungen - Kubernetes-Cluster, serverlose Funktionen, ephemere Container, Multi-Account-Cloud-Setups - erfordern einen anderen Ansatz für die meisten der 12 Anforderungen. Der Standard trägt dem durch den "Customized Approach" Rechnung, der es erlaubt, Sicherheitsziele durch zur eigenen Architektur passende Kontrollen zu erfüllen.

Das Shared-Responsibility-Modell. Beim Betrieb auf einer Public Cloud übernimmt der Cloud-Anbieter die physische und Hypervisor-Schicht. Alles darüber liegt in der eigenen Verantwortung. Diese Grenze klar zu kartieren ist der erste Schritt bei der Cloud-PCI-Scope-Bestimmung.

Zero-Trust und Service Mesh. In einer Microservices-Architektur existiert der klassische Perimeter nicht mehr. Jeder Pod und jeder Service benötigt eine eigene Identität. Ein Service Mesh wie Istio oder Linkerd erzwingt Mutual TLS zwischen allen Services, liefert Request-genaue Observability und begrenzt den Blast-Radius: Wird ein Container kompromittiert, verhindert mTLS die Seitwärtsbewegung zu benachbarten Services. Das entspricht direkt Anforderung 4 (Verschlüsselung im Transit) und unterstützt die kontinuierliche Überwachungspflicht aus Anforderung 10.

Policy as Code. Tools wie Open Policy Agent (OPA) oder Kyverno ermöglichen es, PCI-Kontrollen als Code zu definieren und zum Admission-Zeitpunkt durchzusetzen: keine Root-privilegierten Container, keine öffentlich erreichbaren Load Balancer für interne Services, Herkunftsnachweis für Container-Images, Erkennung von Konfigurationsdrift. In Verbindung mit einem CSPM-Tool liefert das den kontinuierlichen Compliance-Nachweis, den v4.0 verlangt. Für die DSGVO-konforme Datenhaltung in Deutschland empfiehlt sich zusätzlich eine explizite Datenresidenz-Konfiguration, die sicherstellt, dass Kartendaten EU-Rechenzentren nicht verlassen.

Scope-Reduktion durch Tokenisierung und Netzwerksegmentierung

Der effektivste Weg, PCI-Compliance-Kosten und -Komplexität zu senken, besteht darin, die Größe der Karteninhaberdaten-Umgebung zu minimieren. Weniger Systeme im Scope bedeutet ein kleineres Audit, weniger Belege und eine kleinere Angriffsfläche. Zwei Techniken treiben die Scope-Reduktion: Tokenisierung und Netzwerksegmentierung.

Tokenisierung. Ein Tokenisierungssystem ersetzt die rohe PAN durch einen Ersatzwert (Token) ohne kryptografische Verbindung zum Original. Systeme, die nur den Token sehen - CRM, Kundenportal, Analyse-Pipeline - sind außerhalb des Scope. Im Scope verbleiben nur der Tokenisierungs-Vault, das Schlüsselmanagementsystem und Anwendungen, die die De-Tokenisierungs-API aufrufen.

Damit ein Token ein System aus dem Scope nimmt, müssen zwei Bedingungen erfüllt sein: Das token-only System darf keinen Zugriff auf Vault, Schlüssel oder De-Tokenisierungsendpunkt haben; und der Token muss für das empfangende System ohne API-Aufruf an den Vault irreversibel sein. Sind beide Bedingungen erfüllt, bestätigen die Tokenisierungsrichtlinien des PCI Security Standards Council, dass diese Systeme außerhalb der CDE fallen.

Netzwerksegmentierung. Segmentierung trennt Systeme, die PANs halten oder berühren, von solchen, die das nicht tun. In einer Kubernetes-Umgebung bedeutet das: dedizierte Namespaces oder Node-Pools für CDE-Workloads, Netzwerkrichtlinien, die allen Traffic von Nicht-CDE-Namespaces zu CDE-Namespaces (außer explizit erlaubten Pfaden) blockieren, sowie separate VPCs oder Accounts für die Kartendaten-Verarbeitung.

Scoping-Fehler sind das häufigste und teuerste Versagen bei PCI-Prüfungen. Ein verbreiteter Irrtum: Verschlüsselung allein entfernt ein System aus dem Scope. Verschlüsselung schützt Daten innerhalb der CDE, zieht aber keine CDE-Grenzen. Nur Tokenisierung (korrekt implementiert) und nachgewiesene Segmentierung entfernen Systeme aus dem Scope. Für DSGVO-regulierte Umgebungen in Deutschland gilt zusätzlich: Kartendaten sind häufig personenbezogene Daten im Sinne der DSGVO - eine Datenpanne löst also sowohl PCI-DSS-Meldepflichten als auch DSGVO-Meldepflichten aus.

SAQ vs. ROC, Händlerlevel und der Prüfprozess

Die PCI-DSS-Validierungsanforderungen hängen von Ihrem Händler- oder Dienstleister-Level ab, der von den Kartenschemata (Visa, Mastercard usw.) nach dem jährlichen Transaktionsvolumen und Risikoprofil festgelegt wird.

SAQ (Self-Assessment Questionnaire). Der SAQ ist eine Selbstdeklaration. Es gibt verschiedene SAQ-Typen (A, A-EP, B, B-IP, C, C-VT, D, P2PE-HW), je nachdem, wie Kartendaten verarbeitet werden. SAQ-A gilt für Händler, die die Kartendatenverarbeitung vollständig ausgelagert haben. SAQ-D - der umfangreichste - gilt, wenn PANs selbst gespeichert, verarbeitet oder übertragen werden, und spiegelt nahezu alle PCI-DSS-Kontrollen wider. Die Fertigstellung eines SAQ-D dauert für ein Fintech typischerweise sechs bis zwölf Monate.

ROC (Report on Compliance). Der ROC ist ein unabhängiges Audit durch einen QSA oder zertifizierten Internal Security Assessor (ISA). Er ist für Level-1-Unternehmen verpflichtend und bei Dienstleistern und Fintechs mit hohem Volumen üblich. Das Ergebnis ist ein detaillierter technischer Bericht plus Attestation of Compliance (AoC). Viele Fintechs streben freiwillig eine ROC-Prüfung an, weil Enterprise-Banken und Kartenschemata sie als Voraussetzung für Partnerschaften fordern.

In Deutschland bieten spezialisierte PCI-QSA-Anbieter auch integrierte BAIT/MaRisk-PCI-Audits an, die Doppelarbeit bei der Beweiserhebung reduzieren. Da BaFin und PCI-DSS-Anforderungen an IT-Sicherheit, Zugriffskontrolle und Incident-Management weitgehend deckungsgleich sind, lässt sich mit einer integrierten Compliance-Strategie der Gesamtaufwand erheblich senken.

Wie Crassulas Plattform die PCI-Scope-Reduktion unterstützt

Crassulas White-Label-Banking-Plattform wurde so konzipiert, dass sie die kritischsten Teile der Karteninhaberdaten-Umgebung übernimmt - und Kunden ermöglicht, Karten- und Zahlungsprodukte aufzubauen, ohne selbst die vollständige Last der CDE-Eigentümerschaft zu tragen.

Wer ein Karten- oder Zahlungsprodukt auf Crassula aufbaut, erbt die bereits in der Plattform eingebauten Sicherheitskontrollen. Das reduziert den Scope der eigenen PCI-Prüfung auf die Integrationspunkte zwischen der eigenen Anwendung und den Crassula-APIs. Für Teams, die ein erstes Kartenprogramm in Deutschland aufsetzen, verkürzt dieser Ansatz den Weg zur ersten PCI-Prüfung von 12-18 Monaten (eigener CDE-Aufbau) auf 3-6 Monate. Kontaktieren Sie das Crassula-Team für eine technische Übersicht der Shared-Responsibility-Grenzen und die Dokumentation, die Ihr QSA benötigt.

FAQ