Der PCI DSS SAQ A (Self-Assessment Questionnaire A) ist die einfachste Form der PCI DSS-Selbstbewertung: Er enthält nur 22 Fragen und ist für Händler gedacht, die ihre Zahlungsseite vollständig an einen zertifizierten Drittanbieter ausgelagert haben. Sich für SAQ A zu qualifizieren bedeutet nicht nur weniger Papierkram – es bedeutet, dass das gesamte interne System des Händlers aus der CDE herausfällt. Viele Händler, die sich für SAQ D qualifizieren und hunderte Kontrollen verwalten, könnten sich stattdessen mit einer einfachen Architekturänderung für SAQ A qualifizieren.
Was SAQ A ist und was es erfordert
PCI SSC (PCI Security Standards Council) hat mehrere SAQ-Typen definiert, die auf verschiedene Händler-Akzeptanzszenarien zugeschnitten sind. SAQ A gilt für Händler, die Kartendaten vollständig an einen PCI DSS-zertifizierten Drittanbieter ausgelagert haben und selbst keine Kartendaten in irgendeiner Form speichern, verarbeiten oder übertragen. In diesem Szenario hat der Händler keine CDE-Systeme: Alle Kartendaten werden vom Drittanbieter verarbeitet.
Die Anforderungen von SAQ A sind absichtlich begrenzt und konzentrieren sich hauptsächlich auf:
- die Sicherheit der Website, auf der das Zahlungsformular des Drittanbieters angezeigt wird
- Überprüfung, ob die Seite nur HTTPS verwendet und kein Skimming durch Script-Injektion anfällig ist
- Nachweis, dass der Drittanbieter PCI DSS-zertifiziert ist
- physische Sicherheit der Umgebungen, die die Website hosten
SAQ A in PCI DSS v4 hat im Vergleich zu v3.2.1 neue Anforderungen für die Sicherheit von Skripts auf der Zahlungsseite erhalten (Anforderung 6.4.3), um Script-Injection-Angriffe wie Magecart zu verhindern. Der Händler muss alle auf der Zahlungsseite geladenen JavaScript-Skripts autorisieren und inventarisieren.
SAQ A-Zulassungsvoraussetzungen
Um sich für SAQ A zu qualifizieren, muss ein Händler alle folgenden Bedingungen erfüllen:
- Alle Kartendatenempfang ist ausschließlich an PCI DSS-zertifizierte Drittanbieter ausgelagert
- Der Händler speichert, verarbeitet oder überträgt keine Kartendaten auf eigenen Systemen oder Räumlichkeiten
- Alle Kartenakzeptanz-Kanäle sind vollständig ausgelagert (kein telefonischer Empfang von Kartendaten, kein Eingeben von Karten in interne Systeme)
- Die Händler-Website darf nicht selbst Kartendaten empfangen (das Zahlungsformular lädt in einem Frame oder auf einer Seite des Drittanbieters)
- Der Händler ist kein direkter Vertragspartner für das Kartenakzeptanzsystem (er ist nicht über ein eigenes PCI DSS-zertifiziertes Rechenzentrum verbunden)
Eine wichtige Klarstellung: Nicht alle iFrame-basierten Lösungen erfüllen die SAQ-A-Anforderungen. Die Zahlungsseite muss vollständig auf der Domain des Drittanbieters gerendert werden (Hosted Payment Page), oder der Frame muss so implementiert sein, dass der Händler niemals PAN-Daten aus dem Frame abfangen kann. Wenn die Website JavaScript enthält, das Daten aus dem Frame extrahieren könnte, verliert der Händler die SAQ-A-Qualifikation.
Tokenisierung als Weg zu SAQ A
Für Händler, die aktuell SAQ C, SAQ D oder SAQ C-VT ausfüllen, ist Tokenisierung der direkte Weg zu SAQ A. Wenn alle Zahlungsflüsse über einen zertifizierten Drittanbieter (wie PCI Proxy EU) geroutet werden, der die Kartendaten tokenisiert bevor sie interne Systeme erreichen, verlässt der Händler die CDE. Die internen Systeme sehen nur Tokens, keine PANs.
Konkret bedeutet das:
- Online-Checkout: Hosted Payment Page oder sicheres iFrame, das PANs direkt in den Vault sendet
- Telefonkanal: MOTO-Tokenisierungslink, der an den Kunden gesendet wird, statt verbale Karteneingabe
- Backend: CRM, ERP und Buchhaltung arbeiten ausschließlich mit Tokens
Nach dieser Transformation speichert, verarbeitet und überträgt der Händler keine Kartendaten mehr: Er qualifiziert sich für SAQ A. Statt Hunderte von PCI DSS-Kontrollen zu verwalten, beantwortet er 22 Fragen und nutzt die PCI DSS-Zertifizierung von PCI Proxy EU für alles andere.
SAQ A vs. SAQ A-EP: Den Unterschied kennen
PCI DSS hat auch SAQ A-EP (A-Extended Perimeter) für Händler, die Zahlungsseiten über iFrame oder JavaScript-Redirect implementiert haben, aber direkten Einfluss auf die Rendition der Seite haben. SAQ A-EP enthält etwa 140 Fragen und ist deutlich aufwändiger als SAQ A. Die Unterscheidung ist technisch:
- SAQ A: Die Zahlungsseite lädt vollständig auf der Domain des Drittanbieters (Hosted Payment Page), der Händler kontrolliert nicht, wie das Formular gerendert wird
- SAQ A-EP: Der Händler kontrolliert Teile der Zahlungsseitenrendition (eigenes JavaScript lädt vor dem Zahlungsformular), auch wenn Kartendaten direkt an den Drittanbieter gehen
Ziel ist SAQ A, nicht SAQ A-EP. Dazu muss die Zahlungsseiten-Integration vollständig dem Drittanbieter überlassen werden, ohne eigenes JavaScript auf der Zahlungsseite.
Häufig gestellte Fragen
Muss ich als SAQ-A-Händler noch einen Schwachstellenscan durchführen?
SAQ A verlangt keinen vierteljährlichen ASV-Schwachstellenscan (dieser ist SAQ C und SAQ D vorbehalten). SAQ A v4 verlangt jedoch die Sicherheitsprüfung der Zahlungsseiten-Skripts und regelmäßige Überprüfung der Website auf Anzeichen von Script-Injection-Angriffen. Die Prüfung kann intern oder durch einen externen Dienstleister durchgeführt werden, muss aber dokumentiert werden.
Wenn ich nur Stripe oder PayPal verwende, qualifiziere ich mich für SAQ A?
Wenn Sie ausschließlich die Hosted Payment Pages von Stripe oder PayPal verwenden (Weiterleitung auf stripe.com oder paypal.com für den Checkout), qualifizieren Sie sich in der Regel für SAQ A. Wenn Sie Stripe Elements oder PayPal JS SDK in Ihrer eigenen Seite verwenden (d.h. das Zahlungsformular auf Ihrer Domain rendert), müssen Sie möglicherweise SAQ A-EP ausfüllen. Konsultieren Sie Ihren Acquirer zur Bestätigung.
Was bedeuten die neuen v4-Anforderungen für SAQ A?
PCI DSS v4 fügte SAQ A die Anforderungen 6.4.3 und 11.6.1 hinzu: Der Händler muss alle Skripts auf der Zahlungsseite (auch von Drittanbietern) inventarisieren und autorisieren und einen Mechanismus implementieren, um Änderungen an Zahlungsseiten-Skripts zu erkennen. Diese Anforderungen wurden eingeführt, um Magecart-Angriffe zu bekämpfen, die Händler-Zahlungsseiten kompromittieren, ohne die Systeme des Zahlungsanbieters zu berühren.
SAQ A ist das Ziel: Mit PCI Proxy EU Tokenisierung qualifizieren Sie sich und reduzieren Ihre jährliche PCI DSS-Compliance-Last von Hunderten auf 22 Fragen. PCI Proxy EU entdecken.