In Europa gibt es Millionen von kleinen und mittleren Unternehmen, die Kartenzahlungen akzeptieren – online, telefonisch oder im Laden. Die meisten von ihnen wissen, dass sie irgendwelche Datensicherheitsstandards einhalten müssen, aber die wenigsten haben sich wirklich damit befasst, was PCI DSS konkret für ihr Unternehmen bedeutet. Die gute Nachricht: Mit den richtigen Architekturentscheidungen ist die Compliance-Belastung für kleine Unternehmen überschaubar. Die schlechte Nachricht: Viele KMU implementieren Zahlungen auf eine Weise, die die Compliance unnötig kompliziert macht.
Das europäische Kontext: DSGVO, PSD2 und PCI DSS
Kleine Unternehmen in Europa operieren in einem Regulierungsrahmen, der mehrere überschneidende Anforderungen umfasst. DSGVO (Datenschutz-Grundverordnung) regelt den Umgang mit personenbezogenen Daten aller europäischen Bürger und gilt für jedes Unternehmen, das europäische Kunden bedient. PSD2 (Zahlungsdiensterichtlinie 2) hat die Anforderungen an die Starke Kundenauthentifizierung (SCA) eingeführt. PCI DSS ist ein privatrechtlicher Standard der Kartennetzwerke, der durch Merchantverträge verpflichtend gemacht wird.
Diese drei Regelwerke überschneiden sich, sind aber nicht identisch. PCI DSS und DSGVO haben unterschiedliche Definitionen von sensiblen Daten: DSGVO schützt personenbezogene Daten (Name, Adresse, E-Mail), PCI DSS schützt Kartendaten (PAN, CVV, PIN). Eine Datenpanne bei Kartendaten kann sowohl PCI DSS-Strafen als auch DSGVO-Bußgelder auslösen. Kleine Unternehmen in Europa müssen beide Anforderungen im Auge behalten.
Typische Fehler kleiner Unternehmen bei der Zahlungsimplementierung
In der Praxis sehen wir häufig folgende Fehler, die PCI DSS für kleine Unternehmen unnötig kompliziert machen:
- Kartendaten per E-Mail oder WhatsApp empfangen: Kunden senden Kartennummern über ungesicherte Kanäle, was direkt gegen PCI DSS verstößt und gleichzeitig das Unternehmen ernsthaften DSGVO-Risiken aussetzt.
- Kartennummern in Excel-Tabellen speichern: Viele kleine Unternehmen, die Abonnements oder wiederkehrende Zahlungen verwalten, speichern Kartennummern in Tabellenkalkulationen. Das ist ein schwerwiegender PCI DSS-Verstoß.
- Kartennummern in CRM oder ERP eingeben: Interne Systeme sind oft nicht für die sichere Verwaltung sensibler Zahlungsdaten ausgelegt und könnten die gesamte Datenbank zum PCI DSS-Scope machen.
- Benutzerdefinierte Zahlungsformulare ohne sichere Implementierung: JavaScript-Zahlungsformulare auf der eigenen Domain, die ohne korrekte Sicherheitsmaßnahmen implementiert werden, sind anfällig für Skimming-Angriffe.
Die richtige Architektur für kleine Unternehmen
Für die meisten kleinen europäischen Unternehmen ist die optimale PCI DSS-Architektur:
- Keine Kartendaten selbst verarbeiten: Delegieren Sie die vollständige Kartendatenverarbeitung an einen PCI DSS Level-1-zertifizierten Anbieter. Verwenden Sie eine Hosted Payment Page oder sichere Token-APIs.
- Nur Tokens intern speichern: Anstelle der Kartennummer speichert das CRM/ERP einen Token. Der Token kann für Rückerstattungen, Abonnement-Verlängerungen und Kundenverwaltung verwendet werden, ohne das PCI DSS-Risiko.
- Telefonische Zahlungen über sichere Links: Statt Kartennummern telefonisch entgegenzunehmen, sendet der Mitarbeiter dem Kunden einen sicheren Zahlungslink. Der Kunde gibt die Karte selbst ein.
Mit dieser Architektur qualifiziert sich das Unternehmen für SAQ A: Die jährliche Compliance-Arbeit reduziert sich auf die Beantwortung von 22 Fragen und die Überprüfung der Zahlungsseite auf Skript-Sicherheit.
Praktische Checkliste für KMU
Überprüfen Sie Ihren aktuellen Compliance-Status mit dieser Checkliste:
- Speichern wir Kartennummern in einem eigenen System (Datenbank, Excel, CRM)? → Sofortiger Handlungsbedarf
- Empfangen wir Kartennummern per E-Mail, Fax oder Telefon und geben sie manuell ein? → Sofortiger Handlungsbedarf
- Haben wir ein eigenes Zahlungsformular auf unserer Website, das Kartendaten empfängt? → Prüfen ob SAQ A-EP statt SAQ A gilt
- Verwenden wir eine vollständig gehostete Zahlungsseite eines zertifizierten Anbieters? → Richtige Architektur, SAQ A möglich
- Haben wir unseren Acquirer über unsere Compliance-Situation informiert und das jährliche SAQ eingereicht? → Pflicht
Häufig gestellte Fragen
Mein Acquirer hat mich noch nie nach PCI DSS gefragt. Muss ich trotzdem compliant sein?
Ja. Das Fehlen einer aktiven Anforderung durch den Acquirer bedeutet nicht, dass keine Pflicht besteht. Die PCI DSS-Anforderung ist im Händlervertrag verankert, den Sie beim Öffnen des Händlerkontos unterzeichnet haben. Acquirer in Europa haben unterschiedliche Häufigkeiten, mit denen sie aktiv Compliance-Nachweise von kleinen Händlern einfordern, aber die vertragliche Verpflichtung besteht unabhängig davon. Bei einer Datenpanne werden fehlende Compliance-Nachweise zu erschwerenden Faktoren bei der Haftungszuweisung.
Ist PCI DSS dasselbe wie DSGVO-Compliance?
Nein. PCI DSS und DSGVO haben unterschiedliche Geltungsbereiche, Anforderungen und Strafrahmen. DSGVO schützt personenbezogene Daten europäischer Bürger und wird von nationalen Datenschutzbehörden durchgesetzt. PCI DSS schützt Zahlungskartendaten und wird durch Kartennetzwerk-Verträge und Acquirer-Beziehungen durchgesetzt. Beide Regelwerke gelten gleichzeitig: Ein Unternehmen kann DSGVO-konform sein, aber PCI DSS-Verstöße begehen, und umgekehrt.
Kleines Unternehmen, große Compliance-Erleichterung: PCI Proxy EU bietet die Tokenisierungslösung, die Ihre PCI DSS-Compliance auf SAQ A reduziert. PCI Proxy EU entdecken.