PCI DSS: Wer muss den Standard einhalten und welcher SAQ gilt

Die Frage, wer PCI DSS einhalten muss, hat eine täuschend einfache Antwort: jeder, der Karteninhaberdaten speichert, verarbeitet oder überträgt, plus die Dienstleister, die die Sicherheit dieser Daten beeinflussen können. In der Praxis ist der Anwendungsbereich die Stelle, an der die meisten Teams hängen bleiben, denn schon ein einzelner gehosteter Checkout kann Sie in einen anderen Validierungspfad ziehen als ein vollständig selbst betriebenes Zahlungssystem. Dieser Leitfaden richtet sich an Compliance-Manager, CISOs und Gründer, die wissen müssen, ob PCI DSS auf sie anwendbar ist, was der Standard tatsächlich verlangt und welcher Self-Assessment Questionnaire (SAQ) zu ihrem Setup passt. Er bezieht sich auf PCI DSS v4.0.1, die derzeit geltende Version.

Was PCI DSS ist

Der Payment Card Industry Data Security Standard (PCI DSS) ist ein Sicherheitsstandard für Organisationen, die mit Zahlungskarten der großen Kartenmarken umgehen. Gepflegt wird er vom PCI Security Standards Council (PCI SSC), einem von den großen Kartenmarken gegründeten Gremium. Die aktuelle Fassung ist PCI DSS v4.0.1. Entscheidend: PCI DSS ist eine vertragliche Verpflichtung. Die Kartenmarken und Ihre Acquiring-Bank verlangen ihn, und er fließt über Ihren Händlervertrag oder Ihre Dienstleisterverträge an Sie weiter. Durchsetzung, Bußgelder und Validierungsfristen kommen von Acquirern und Kartenmarken. Darüber lohnt es sich nachzudenken, denn es verändert, mit wem Sie diskutieren. Es gibt keine Aufsichtsbehörde, an die Sie sich wenden könnten, und keinen Verhältnismäßigkeitsgrundsatz, auf den Sie sich stützen könnten; Ihr Gegenüber ist eine Bank, die Ihre Gebühren erhöhen oder Ihre Transaktionen ablehnen kann. In der Praxis macht das PCI DSS weniger verhandelbar als die meisten gesetzlichen Regelwerke, obwohl er nur ein Vertrag ist. Der Standard ist in 12 Kernanforderungen gegliedert, gruppiert unter 6 Zielen, und deckt alles ab, von Netzwerksicherheit und Verschlüsselung über Zugriffskontrolle und Überwachung bis hin zu einer schriftlichen Informationssicherheitsrichtlinie.

Wer den Standard einhalten muss und wer im Anwendungsbereich liegt

Wenn Ihre Organisation an irgendeiner Stelle mit Karteninhaberdaten in Berührung kommt, sind Sie im Anwendungsbereich. Das umfasst Händler, die Karten für Waren oder Dienstleistungen akzeptieren, und Dienstleister, deren Systeme die Sicherheit dieser Daten beeinflussen können. Der Umfang Ihrer Verpflichtung, und wie Sie sie nachweisen, hängt von Ihrer Rolle und Ihrem jährlichen Kartentransaktionsvolumen ab.

Händler und die vier Stufen

Händler werden nach jährlichem Transaktionsvolumen in vier Stufen eingeteilt, und die Stufe bestimmt, wie die Compliance validiert wird:

• Level 1 ist die Stufe mit dem höchsten Volumen und erfordert in der Regel ein jährliches Vor-Ort-Assessment, das einen von einem Qualified Security Assessor (QSA) abgezeichneten Report on Compliance (ROC) hervorbringt, plus vierteljährliche Netzwerkscans.
• Level 2, 3 und 4 decken zunehmend niedrigere Volumina ab und können sich oft über einen jährlichen Self-Assessment Questionnaire und eine Attestation of Compliance validieren, wiederum mit Scans, wo Kartendaten das Internet durchqueren.

Die genauen Volumenschwellen und die Behandlung jeder Stufe legen die einzelnen Kartenmarken fest; bestätigen Sie Ihre Stufe daher bei Ihrem Acquirer. Das ist eine einzige E-Mail, und die meisten Teams verschicken sie nie. Wer seine Stufe aus einem Blogbeitrag errät, bereitet am Ende das falsche Validierungspaket vor, Wochen vor einer Frist, die er ebenfalls nur geraten hat.

Dienstleister

Jedes Unternehmen, das Karteninhaberdaten im Auftrag anderer speichert, verarbeitet oder überträgt oder das die Sicherheit der Kartendaten eines Kunden beeinflussen könnte, ist nach PCI DSS ein Dienstleister (Service Provider). Hosting-Anbieter, Payment-Gateways, Managed-Security-Firmen und ähnliche Unternehmen validieren typischerweise gegen den vollständigsten Anforderungskatalog, und größere Dienstleister müssen in der Regel unabhängig von einer händlerartigen Stufe ein Vor-Ort-Assessment durchlaufen.

Was PCI DSS verlangt

Die Substanz des Standards steckt in seinen 12 Anforderungen, gruppiert unter 6 Zielen. Kurz gefasst verlangt PCI DSS, dass Sie ein sicheres Netzwerk aufbauen und betreiben (Firewalls und Netzwerkkontrollen installieren und verwalten sowie Hersteller-Standardpasswörter entfernen), gespeicherte Karteninhaberdaten schützen (durch Verschlüsselung und starke Kryptografie bei der Übertragung) und ein Schwachstellenmanagement-Programm pflegen (Anti-Malware-Kontrollen und sichere Softwareentwicklung). Weiter verlangt er starke Zugriffskontrolle (Zugriff nach dem Need-to-know-Prinzip beschränken, eindeutige Kennungen verwenden und physischen Zugang sichern), regelmäßige Überwachung und Tests der Netzwerke (Zugriffe protokollieren und nachverfolgen sowie Schwachstellenscans und Penetrationstests durchführen) und eine Informationssicherheitsrichtlinie, die den Umgang der Mitarbeiter mit Kartendaten regelt.

Version 4.0.1 behält diese Struktur bei, legt aber mehr Gewicht auf kontinuierliche, risikobasierte Sicherheit über das gesamte Jahr hinweg. Mehrere neuere Erwartungen, etwa strengere Skript-Kontrollen für Zahlungsseiten, sind für E-Commerce-Händler relevant und bestimmen mit, welcher SAQ auf sie zutrifft. Diese Skript-Kontrollen sind der wirklich schwierige Teil der aktuellen Version. Jedes Skript auf einer Checkout-Seite zu inventarisieren und freizugeben klingt trivial, bis man einem Marketingteam mit einem Tag-Manager und der Gewohnheit begegnet, freitags Pixel hinzuzufügen. Der Großteil des restlichen Standards ist Sicherheitshygiene, die Sie ohnehin haben sollten. Dieser Teil erzwingt ein Governance-Gespräch darüber, wer Code auf Ihre Zahlungsseite bringen darf, und dieses Gespräch ist selten angenehm.

Die Self-Assessment Questionnaires und welcher gilt

Berechtigte Händler validieren, indem sie den SAQ ausfüllen, der dazu passt, wie sie Kartendaten annehmen und verarbeiten. Den falschen zu wählen ist ein häufiger und teurer Fehler, denn jeder SAQ trägt eine andere Teilmenge der 12 Anforderungen. Die wichtigsten Typen sind:

• SAQ A - für Händler, deren Kartenfunktionen vollständig an validierte Dritte ausgelagert sind, etwa E-Commerce-Sites, die den Kunden komplett auf eine gehostete Zahlungsseite weiterleiten oder ein vollständig ausgelagertes Iframe verwenden. Sie berühren oder speichern Kartendaten auf Ihren eigenen Systemen zu keinem Zeitpunkt. Dies ist der kürzeste SAQ.
• SAQ A-EP - für E-Commerce-Händler, die teilweise auslagern. Der klassische Fall ist eine Zahlungsseite, an deren Auslieferung Ihre Site beteiligt ist, zum Beispiel wenn Ihr Webserver Skripte neben einem Zahlungsformular eines Drittanbieters ausliefert. Hier greifen die Kontrollen für Zahlungsseiten-Skripte und Änderungserkennung (Anforderungen 6.4.3 und 11.6.1), und der Fragebogen ist erheblich länger als SAQ A.
• SAQ B - für Händler mit Imprint-Geräten oder eigenständigen Dial-out-Terminals, ohne elektronische Speicherung von Karteninhaberdaten.
• SAQ C - für Händler mit einer mit dem Internet verbundenen Zahlungsanwendung, bei der Kartendaten nicht elektronisch gespeichert werden.
• SAQ D - der umfangreichste Fragebogen, für alle anderen Händler, die in keinen engeren SAQ passen, und für Dienstleister, die zur Selbstbewertung berechtigt sind. Er deckt den breitesten Anforderungskatalog ab.

Die Richtung ist klar: Je mehr Ihre eigenen Systeme mit Kartendaten in Berührung kommen, desto länger und anspruchsvoller wird Ihr SAQ. Den Anwendungsbereich zu reduzieren, etwa durch den Wechsel von einem selbst gehosteten Formular zu einem vollständig weitergeleiteten Checkout, kann Sie von SAQ A-EP in Richtung SAQ A bewegen und Ihre Pflichten erheblich verringern. Wenn Sie eine einzige Entscheidung aus diesem Leitfaden mitnehmen, dann diese. Ein Engineering-Sprint, der die Karteneingabe von Ihren eigenen Seiten wegverlagert, spart mehr Compliance-Aufwand als jede Menge Kontrolldokumentation, und die Ersparnis wiederholt sich jedes Jahr. Führen Sie dieses Gespräch mit dem Engineering, bevor Sie einen Fragebogen öffnen, denn danach dokumentieren Sie nur noch eine bereits getroffene Entscheidung.

Wie Sie die Anforderungen tatsächlich erfüllen

1. Bestätigen Sie Rolle und Stufe bei Ihrer Acquiring-Bank. Fragen Sie, ob Sie als Händler oder Dienstleister behandelt werden und welche Validierungsstufe für Ihr Volumen gilt.
2. Kartieren Sie Ihre Karteninhaberdaten. Dokumentieren Sie jeden Ort, an dem Kartendaten erfasst, übertragen, verarbeitet oder gespeichert werden, einschließlich Zahlungsseiten von Drittanbietern und aller Skripte, die Ihre Site ausliefert. Das definiert Ihren Anwendungsbereich.
3. Minimieren Sie den Anwendungsbereich. Lagern Sie aus, was Sie können, an validierte Anbieter, tokenisieren oder vermeiden Sie die Speicherung von Kartendaten, und segmentieren Sie die Systeme, die im Anwendungsbereich verbleiben. Weniger Scope bedeutet einen kürzeren SAQ und geringeres Risiko.
4. Identifizieren Sie den richtigen SAQ (oder bestätigen Sie, dass Sie einen QSA-geführten Report on Compliance brauchen), basierend darauf, wie Sie Zahlungen tatsächlich annehmen.
5. Schließen Sie die Kontrolllücken. Arbeiten Sie die einschlägigen Anforderungen ab: Firewalls und Netzwerkkontrollen, Verschlüsselung, Zugriffskontrolle, Logging, Schwachstellenmanagement und Ihre schriftliche Sicherheitsrichtlinie.
6. Organisieren Sie die externen Bausteine. Beauftragen Sie, wo erforderlich, einen Approved Scanning Vendor (ASV) für vierteljährliche externe Scans und einen QSA, falls Ihre Stufe ein Vor-Ort-Assessment verlangt. Dies sind eigenständige Mandate, getrennt von jedem Governance-Tooling. Buchen Sie sie früher, als es nötig erscheint. Scan-Fenster und Assessor-Kalender sind die beiden Dinge in diesem Prozess, die sich nicht komprimieren lassen, und ein fehlgeschlagener Scan, der Nachbesserung und einen erneuten Scan braucht, kann allein einen Monat verschlingen.
7. Füllen Sie den SAQ und die Attestation of Compliance aus, sammeln Sie die Nachweise hinter jeder Antwort und reichen Sie alles bei Ihrem Acquirer ein.
8. Halten Sie das Niveau ganzjährig. Scannen, testen, Logs prüfen und jährlich neu validieren. PCI DSS v4.0.1 erwartet kontinuierliche Sicherheitshygiene über das gesamte Jahr.

Für eine Kontrolle-für-Kontrolle-Sicht auf den Standard und darauf, wie er sich auf bereits gesammelte Nachweise abbilden lässt, lesen Sie, wie Venvera PCI DSS handhabt. Wenn Sie unsicher sind, wo Sie stehen, gibt Ihnen der kostenlose Compliance-Check eine schnelle Einschätzung Ihres wahrscheinlichen Anwendungsbereichs und Ihrer Lücken.

Häufig gestellte Fragen

Ist PCI DSS eine gesetzliche Pflicht?

Nein. PCI DSS ist ein vertraglicher Standard, der von den Kartenmarken und Ihrer Acquiring-Bank durchgesetzt wird. Allerdings kann seine Missachtung Ihren Händlervertrag verletzen und Bußgelder, höhere Gebühren oder den Verlust der Möglichkeit, Karten zu akzeptieren, nach sich ziehen; in der Praxis funktioniert er daher für jeden, der Kartenzahlungen annimmt, wie eine harte Anforderung.

Gilt PCI DSS für kleine Unternehmen?

Ja. Eine Ausnahme für geringe Unternehmensgröße existiert nicht. Ein Unternehmen, das eine Handvoll Transaktionen pro Jahr verarbeitet, ist im Anwendungsbereich, sobald es mit Karteninhaberdaten in Berührung kommt. Kleinere Händler fallen in der Regel in die niedrigeren Validierungsstufen und können sich mit einem SAQ selbst bewerten, sie müssen die einschlägigen Anforderungen aber dennoch erfüllen.

Woher weiß ich, welchen SAQ ich verwenden muss?

Beginnen Sie damit, wie Kartendaten zu Ihnen gelangen. Vollständig ausgelagerter E-Commerce deutet auf SAQ A; eine E-Commerce-Seite, die Sie teilweise hosten oder für die Sie Skripte ausliefern, deutet auf SAQ A-EP; eigenständige Terminals deuten auf SAQ B; eine internetverbundene Zahlungsanwendung ohne gespeicherte Daten deutet auf SAQ C; und alles andere, einschließlich der meisten Dienstleister, deutet auf SAQ D. Wenn zwei plausibel erscheinen, klären Sie es mit Ihrem Acquirer, denn ein zu leichter SAQ lässt Anforderungen unerfüllt.

Brauche ich PCI DSS trotzdem, wenn ich Stripe oder einen anderen Zahlungsdienstleister nutze?

In der Regel ja, aber Ihre Pflichten sind leichter. Ein validierter Zahlungsdienstleister und ein gehosteter oder weitergeleiteter Checkout können Sie zu SAQ A bringen, dem kürzesten Fragebogen, weil Sie den direkten Umgang mit Kartendaten vermeiden. Sie bleiben verantwortlich dafür, den SAQ auszufüllen, die Integrität Ihrer Website zu schützen und zu bestätigen, dass Ihre Anbieter PCI DSS-konform sind.

Kann eine GRC-Plattform mich allein PCI DSS-konform machen?

Nein. Keine Governance-Plattform kann Ihre Compliance im Alleingang validieren, und keine GRC-Plattform ist ein Approved Scanning Vendor. ASV-Scans und QSA-Assessments sind separate Verträge, die Sie eigenständig abschließen. Venvera hilft Ihnen, Ihre PCI DSS-Kontrollen zu organisieren, zu verfolgen und mit Nachweisen zu belegen; Venvera ist weder ein ASV noch ein QSA und ersetzt keinen von beiden.

Was ist der Unterschied zwischen einem SAQ und einem Report on Compliance?

Ein SAQ ist eine Selbstbewertung, die berechtigte Händler selbst ausfüllen, gepaart mit einer Attestation of Compliance. Ein Report on Compliance (ROC) wird von einem Qualified Security Assessor im Rahmen eines Vor-Ort-Assessments erstellt und ist in der Regel für die volumenstärksten Level-1-Händler und große Dienstleister erforderlich.

Primärquellen

• PCI Security Standards Council (PCI SSC) - das Gremium, das PCI DSS pflegt und die Standards, SAQs und begleitenden Leitfäden veröffentlicht. pcisecuritystandards.org.
• PCI DSS v4.0.1 Standard - die aktuelle Version des Standards mit den 12 Anforderungen und ihren Prüfverfahren, verfügbar in der PCI SSC Document Library. PCI SSC Document Library.
• PCI SSC Self-Assessment Questionnaires - die SAQ-Dokumente und die Berechtigungskriterien, die bestimmen, welcher Fragebogen gilt. SAQ-Anleitungen und Formulare.

Hinweis zum Geltungsbereich. Dieser Leitfaden fasst PCI DSS auf hoher Ebene zusammen und ersetzt den Standard selbst nicht. Validierungsstufen, Schwellenwerte und SAQ-Berechtigung legen die Kartenmarken und Ihr Acquirer fest; prüfen Sie die Einzelheiten daher anhand der offiziellen PCI SSC-Dokumente und Ihrer eigenen Verträge, bevor Sie handeln.

Von Alexander Sverdlov, CEO und Gründer, Venvera. Veröffentlicht am 20. Juli 2026 - Zuletzt geprüft am 20. Juli 2026.