PCI-DSS-Nachweiswege: SAQ, ROC und Compliance-Level

Problem in der Praxis

Viele Organisationen behandeln den PCI-DSS-Nachweis als einmal jährlich auszufüllendes Formular. Es wird ein Self-Assessment Questionnaire ausgewählt, der nicht zur tatsächlichen Zahlungsumgebung passt, der Geltungsbereich wird zu eng gefasst, und erst spät fällt auf, dass das Transaktionsvolumen einen umfangreicheren Prüfbericht durch einen externen Assessor verlangt.

Typisch ist auch die Annahme, eine ISO-27001-Zertifizierung oder ein bestehendes ISMS decke die PCI-Anforderungen automatisch ab. Das ist nicht der Fall: Die beiden Welten überschneiden sich inhaltlich, ersetzen einander aber nicht.

Hinzu kommt, dass die konkreten Schwellenwerte und Validierungspflichten je Kartenmarke unterschiedlich sind. Wer von einem einheitlichen Grenzwert ausgeht, kann sein eigenes Level falsch einschätzen. Der Nachweisweg wird so reaktiv gewählt, oft erst auf Nachfrage des Acquirers, statt ihn als planbaren Bestandteil der Sicherheitssteuerung zu führen.

CISO-Einordnung

Es lohnt sich, die zentralen Bausteine konzeptionell sauber auseinanderzuhalten:

• Compliance-Level (1 bis 4): Die Einstufung richtet sich nach dem jährlichen Kartentransaktionsvolumen. Level 1 steht für das höchste Volumen, die Level 2 bis 4 staffeln absteigend. Wichtig ist: Die genauen Schwellenwerte und die daran geknüpften Validierungspflichten werden von den einzelnen Card Schemes (unter anderem Visa, Mastercard, American Express, Discover, JCB) festgelegt und weichen je Marke leicht voneinander ab. Ein verbreiteter Orientierungswert für Level 1 liegt im Bereich mehrerer Millionen Transaktionen pro Jahr; die verbindliche Einstufung ist jedoch beim Acquirer beziehungsweise beim jeweiligen Scheme zu erfragen und nicht als markenübergreifend einheitlich anzunehmen.
• SAQ (Self-Assessment Questionnaire): Das Instrument der Selbstbewertung für dafür berechtigte Händler und Dienstleister. Es existieren mehrere Typen, die jeweils auf eine bestimmte Zahlungsumgebung zugeschnitten sind, etwa rein ausgelagerte E-Commerce-Szenarien, Kartenterminals ohne elektronische Speicherung oder Umgebungen mit Point-to-Point-Verschlüsselung. Welcher Typ einschlägig ist, hängt davon ab, wie Karteninhaberdaten erfasst, verarbeitet und übertragen werden. Die genaue Anzahl und Abgrenzung der SAQ-Typen wird je nach Zählweise unterschiedlich dargestellt und sollte für den Einzelfall an der Originalquelle bestätigt werden.
• ROC (Report on Compliance): Der umfassende, formale Prüfbericht, der typischerweise für Level-1-Händler und größere Service Provider verlangt wird. Er wird in der Regel durch einen externen, qualifizierten Assessor erstellt.
• AOC (Attestation of Compliance): Die formale Konformitätsbestätigung, die eine Selbstbewertung oder einen Prüfbericht begleitet und das Dokument ist, das gegenüber Acquirer oder Scheme den Nachweis transportiert.

Bei den Rollen sind drei Begriffe zentral. Der QSA (Qualified Security Assessor) ist ein vom PCI SSC qualifizierter externer Prüfer, der einen ROC erstellen darf. Der ISA (Internal Security Assessor) ist eine intern qualifizierte Person, die als internes Äquivalent bestimmte Bewertungen vornehmen kann. Der ASV (Approved Scanning Vendor) führt die externen Schwachstellen-Scans durch, die je nach Umgebung Teil des Nachweises sind. Relevant ist außerdem, dass PCI DSS in der aktuellen Version zwei Umsetzungswege kennt: einen vorgegebenen Ansatz und einen risikobasiert angepassten Ansatz. Der angepasste Ansatz lässt sich nur durch einen QSA bewerten, nicht im Wege einer reinen Selbstbewertung.

Umsetzungsperspektive

Aus CISO-Sicht folgt der Nachweisweg einer klaren Reihenfolge:

• Level bestimmen: Das einschlägige Compliance-Level beim Acquirer verbindlich erfragen, statt es aus allgemeinen Richtwerten abzuleiten.
• Scope definieren: Die Cardholder Data Environment (CDE) sauber abgrenzen, also alle Systeme, Prozesse und Personen, die Karteninhaberdaten verarbeiten oder die Sicherheit dieser Daten beeinflussen. Der Geltungsbereich ist der eigentliche Hebel.
• Scope reduzieren: Durch Netzsegmentierung, Auslagerung an konforme Dienstleister oder Verschlüsselungsverfahren lässt sich die CDE und damit der Prüfaufwand deutlich verkleinern. Ein kleinerer Scope kann auch einen einfacheren SAQ-Typ ermöglichen.
• Instrument wählen: Den zur Zahlungsumgebung passenden SAQ-Typ bestimmen oder den ROC-Pfad mit QSA einplanen, abhängig von Level und Vertragslage.
• Begleitnachweise planen: ASV-Scans und Penetrationstests in der erforderlichen Taktung einplanen. Die Validierung erfolgt typischerweise jährlich, Scans je nach Anforderung häufiger; die genaue Frequenz ist scheme- und levelabhängig.

Diese Kette sollte nicht jährlich neu improvisiert, sondern als wiederkehrender Prozess mit klaren Verantwortlichkeiten betrieben werden.

Typische Fehler

1. Ein SAQ-Typ wird gewählt, der nicht zur realen Zahlungsumgebung passt, etwa weil ein vermeintlich ausgelagerter Kanal doch Karteninhaberdaten berührt.
2. Der Scope wird zu eng gefasst, sodass verbundene oder sicherheitsbeeinflussende Systeme übersehen werden.
3. Die Level-Schwellen werden als markenübergreifend einheitlich angenommen, statt sie je Scheme zu prüfen.
4. Die AOC wird als nachrangiges Beiwerk behandelt, obwohl sie das gegenüber dem Acquirer wirksame Nachweisdokument ist.
5. Ein angepasster Umsetzungsansatz wird gewählt, ohne den dafür notwendigen QSA und die erforderliche Wirksamkeitsanalyse einzuplanen.

Risiken und Trade-offs

Eine Selbstbewertung ist günstiger und schneller, verlagert aber die Verantwortung für die Richtigkeit vollständig auf die Organisation. Eine falsch ausgefüllte Selbstbewertung ist im Schadensfall schwer zu verteidigen. Ein ROC durch einen QSA ist aufwendiger und teurer, liefert aber eine unabhängig belastbare Aussage.

Bei der Scope-Reduktion stehen Architektur- und Betriebskosten dem Prüfaufwand gegenüber: Investitionen in Segmentierung oder Auslagerung senken den jährlichen Nachweisaufwand, verursachen aber zunächst eigene Kosten und Komplexität.

Der angepasste Umsetzungsansatz bietet Flexibilität für Organisationen mit reifen Kontrollen, bindet jedoch zwingend einen QSA und erfordert eine eigene, dokumentierte Wirksamkeitsanalyse. Für weniger reife Umgebungen ist der vorgegebene Ansatz meist der pragmatischere Weg.

Entscheidungspunkte

• Welches Compliance-Level gilt je Kartenmarke tatsächlich, und ist es beim Acquirer bestätigt?
• Wie ist die CDE abgegrenzt, und welche Maßnahmen könnten den Scope sinnvoll verkleinern?
• Welcher SAQ-Typ passt zur konkreten Zahlungsumgebung, oder ist ein ROC-Pfad erforderlich?
• Wird ein vorgegebener oder ein angepasster Umsetzungsansatz verfolgt, und ist die dafür nötige Prüfrolle eingeplant?
• Wer verantwortet AOC, ASV-Scans und Penetrationstests in der jährlichen Taktung?

Praktische Empfehlungen

1. Klären Sie Level und einschlägigen Nachweisweg aktiv mit dem Acquirer, bevor Sie Aufwände planen.
2. Behandeln Sie die CDE-Abgrenzung als zentrale Steuerungsentscheidung und reduzieren Sie den Scope gezielt.
3. Wählen Sie den SAQ-Typ anhand der realen Datenflüsse, nicht anhand des bequemsten Fragebogens.
4. Planen Sie QSA, ISA und ASV als Rollen mit klaren Verantwortlichkeiten und Vorlaufzeiten ein.
5. Verifizieren Sie verbindliche Level-Schwellen und Validierungsvorgaben beim jeweiligen Card Scheme bzw. Ihrem Acquirer (diese legen die Schwellen fest) und die Standard-/Vorlagendetails beim PCI SSC.

Relevante Normreferenzen

• PCI DSS v4.0.1 (PCI Security Standards Council): Referenz für Nachweisinstrumente, Level-Logik und Rollen; Standarddetails und Vorlagen aus der offiziellen PCI-SSC-Dokumentation. Verbindliche Level-Schwellen und Validierungspflichten legen jedoch die Card Schemes bzw. der Acquirer fest und sind dort zu verifizieren.
• ISO/IEC 27001: Referenz für ein zertifizierbares ISMS mit breiterem Geltungsbereich; inhaltliche Überschneidung mit PCI DSS, aber keine gegenseitige Ersetzung.
• NIST Cybersecurity Framework: Referenz als übergeordnete Mapping-Ebene für Sicherheitsfunktionen; kein offizielles Eins-zu-eins-Mapping zu PCI DSS.