PCI DSS v4.x: Neuerungen und der Customized Approach

Problem in der Praxis

Viele Organisationen behandeln PCI DSS als jährliches Audit-Ereignis. Kurz vor dem Stichtag werden Nachweise zusammengetragen, ein Self-Assessment Questionnaire oder ein Report on Compliance erstellt und die Attestation of Compliance unterzeichnet. Diese Logik gerät unter v4.x an ihre Grenzen.

Der Customized Approach wird oft als bequemer Ausweg missverstanden. Tatsächlich ist er anspruchsvoller als der Defined Approach: Er verlangt eine eigene Zielanalyse, eine dokumentierte Wirksamkeitsbegründung und eine Bewertung durch einen qualifizierten Assessor. Wer kein gelebtes Risikomanagement hat, erzeugt damit mehr Aufwand und mehr Prüfrisiko, nicht weniger.

Gleichzeitig werden die zukunftsdatierten Anforderungen unterschätzt. Solange sie als Best Practice galten, wurden sie verschoben; seit dem 31.03.2025 sind sie regulärer Prüfgegenstand. Besonders die Ausweitung starker Mehrfaktor-Authentifizierung auf Zugriffe in die Karteninhaberdaten-Umgebung trifft Architekturen, die historisch nur Administrations- und Fernzugriffe abgesichert haben.

CISO-Einordnung

Der Kern von v4.x ist eine Wahl zwischen zwei Wegen zum selben Ziel. Der Defined Approach folgt den vorgegebenen Anforderungen und den zugehörigen Testverfahren. Er ist planbar, gut verstanden und für Selbstbewertungen geeignet. Der Customized Approach erlaubt eine alternative Umsetzung, die das jeweilige Sicherheitsziel auf anderem Weg erreicht. Er ist nicht selbst-bewertbar im klassischen Sinn, sondern setzt eine Bewertung durch einen Qualified Security Assessor voraus und verlangt vom Unternehmen eine eigene, nachvollziehbare Analyse der erreichten Wirkung.

Beide Ansätze können innerhalb eines Assessments kombiniert werden. Eine Organisation kann den Großteil im Defined Approach abdecken und nur für einzelne, gut begründete Fälle den Customized Approach wählen, etwa wenn eine moderne Architektur ein Schutzziel besser erreicht als die vorgegebene Standardmaßnahme. Ergänzend kennt v4.x die zielgerichtete Risikoanalyse für bestimmte frequenz- und häufigkeitsbezogene Anforderungen, mit der eine Organisation Prüfintervalle risikobasiert begründen kann.

Für den CISO ist die eigentliche Frage damit nicht technischer, sondern steuerungsorientierter Natur: Verfügt die Organisation über genug Risiko- und Nachweisreife, um eine eigene Wirksamkeitsargumentation gegenüber einem Assessor zu vertreten? Wenn ja, eröffnet der Customized Approach Spielraum für Innovation. Wenn nein, ist der Defined Approach der robustere Weg.

Umsetzungsperspektive

Sinnvoll ist eine bewusste Standortbestimmung vor der nächsten Validierung. Dazu gehören der korrekte Scope, also die saubere Abgrenzung der Cardholder Data Environment einschließlich angebundener und sicherheitsbeeinflussender Systeme, sowie die Prüfung, wo Segmentierung den Scope verkleinert. Je kleiner und klarer der Scope, desto beherrschbarer ist jeder weitere Schritt.

Auf dieser Basis sollte je Themenbereich entschieden werden, welcher Ansatz gewählt wird. Der Customized Approach ist dort attraktiv, wo etablierte Kontrollen ein Ziel nachweislich besser erreichen als die Standardvorgabe und wo bereits Telemetrie, Tests und Kennzahlen existieren, die diese Wirkung belegen. Wo solche Nachweise fehlen, ist der Defined Approach der schnellere Weg zur Konformität.

Die zukunftsdatierten Anforderungen sollten als Dauerzustand behandelt werden, nicht als einmaliges Projekt. Das betrifft vor allem die stärkere Authentifizierung, die Verschärfung von Authentifizierungsparametern, den erweiterten Schutz im E-Commerce-Umfeld und die klarere Zuordnung von Rollen und Verantwortlichkeiten. v4.x verschiebt den Schwerpunkt insgesamt von der punktuellen Prüfung zum kontinuierlichen Sicherheitsbetrieb. Diese Aussagen sind bewusst konzeptionell gehalten; verbindliche Einzelheiten ergeben sich ausschließlich aus dem offiziellen Standardtext des PCI SSC.

Typische Fehler

1. Der Customized Approach wird als Abkürzung gewählt, obwohl die Risiko- und Nachweisreife dafür fehlt.
2. Die zukunftsdatierten Anforderungen werden weiter als Best Practice behandelt, obwohl sie seit dem 31.03.2025 voll verpflichtend sind.
3. Die Ausweitung der Mehrfaktor-Authentifizierung wird auf Administrations- und Fernzugriffe verengt statt auf alle relevanten Zugriffe in die Karteninhaberdaten-Umgebung bezogen.
4. Der Scope wird zu weit gefasst, weil Segmentierung nicht genutzt oder nicht belegt wird.
5. PCI DSS wird als jährliches Audit-Projekt betrieben statt als kontinuierlicher Sicherheitsbetrieb.

Risiken und Trade-offs

Der Customized Approach bietet Flexibilität, erzeugt aber höhere Begründungs- und Dokumentationslast und ist von der Verfügbarkeit eines qualifizierten Assessors abhängig. Eine schwache Wirksamkeitsargumentation kann zu Feststellungen führen, die im Defined Approach nicht entstanden wären.

Der Defined Approach ist planbar und gut auditierbar, kann aber moderne Architekturen schlechter abbilden und in Einzelfällen zu Maßnahmen zwingen, die das Schutzziel nicht optimal treffen. Ein zu weiter Scope erhöht Aufwand und Angriffsfläche, eine zu aggressive Segmentierung ohne saubere Belege kann im Assessment scheitern.

Strategisch ist zu beachten, dass PCI DSS scope-eng und präskriptiv ist, während ein ISMS nach ISO/IEC 27001 breiter und risikobasiert steuert. Eine ISO-Zertifizierung ersetzt PCI DSS nicht und umgekehrt; beide können jedoch sinnvoll ineinandergreifen, wenn PCI DSS als detaillierte technische Kontrollschicht in das ISMS eingebettet wird.

Entscheidungspunkte

• Für welche Themen ist der Customized Approach fachlich gerechtfertigt, und besitzt die Organisation die Nachweisreife dafür?
• Wo verkleinert Segmentierung den Scope, und ist diese Reduktion belastbar belegt?
• Welches Validierungsinstrument passt zur Umgebung und zum jeweiligen Compliance-Level, und wo ist eine Bewertung durch einen QSA erforderlich?
• Sind die seit dem 31.03.2025 verpflichtenden Anforderungen, insbesondere die erweiterte Authentifizierung, dauerhaft im Betrieb verankert?
• Welche Prüfintervalle lassen sich über eine zielgerichtete Risikoanalyse risikobasiert begründen?

Praktische Empfehlungen

1. Bestimmen Sie zuerst Scope und Segmentierung sauber, bevor Sie über Ansätze entscheiden.
2. Wählen Sie den Customized Approach selektiv und nur dort, wo Sie Wirksamkeit mit Daten belegen können.
3. Behandeln Sie die zukunftsdatierten Anforderungen als Dauerbetrieb, nicht als Projekt mit Enddatum.
4. Verankern Sie die stärkere Authentifizierung architektonisch, nicht nur als Einzelmaßnahme an der Peripherie.
5. Klären Sie verbindliche Schwellenwerte, Validierungspflichten und Fristen mit Acquirer und Card Scheme sowie gegen den offiziellen PCI-SSC-Text, da diese je Marke variieren können.

Relevante Normreferenzen

• PCI DSS v4.0.1 (PCI Security Standards Council): aktuelle, seit dem 01.01.2025 alleinig unterstützte Version; Punktrelease zu v4.0 ohne neue oder gestrichene Anforderungen, nur Klarstellungen. Referenz, kein Wortlaut.
• ISO/IEC 27001: Referenz für ein risikobasiertes ISMS mit breiterem Scope; ergänzt, ersetzt PCI DSS aber nicht.
• NIST Cyber Security Framework sowie NIST SP 800-53 / 800-63: Referenz für Mapping auf Sicherheitsfunktionen und Authentifizierung; kein offizielles 1:1-Mapping durch den PCI SSC.