Datenschutz bei Verkaufs- und Buchungsfunktionen auf Websites ist kein Thema für den Projektstart allein. Die meisten Pflichten entstehen erst im laufenden Betrieb, wenn Kundendaten fließen, Zahlungsdienstleister eingebunden werden und Schnittstellen Daten weitergeben. Wer hier nicht systematisch prüft, übernimmt Risiken, die sich später kaum noch beheben lassen.
Datenfluss im Überblick: Was bei Buchung und Kauf alles anfällt
Personenbezogene Daten in Buchungs- und Shopsystemen beschränken sich nicht auf Name und E-Mail-Adresse. Bereits beim ersten Seitenbesuch entstehen Datenspuren: IP-Adresse, Browserkennung, Spracheinstellung, Referrer-Information. Sobald ein Nutzer einen Termin bucht oder einen Artikel in den Warenkorb legt, kommen Kontaktdaten, ggf. Rechnungs- und Lieferadressen, Telefonnummern, Kommentare oder Freitextfelder hinzu.
Bei Buchungssystemen fallen zusätzlich Kalenderdaten, gewählte Zeitfenster, Teilnehmeranzahlen und oft Gesundheits- oder Präferenzangaben an. Bei Shops entstehen Transaktionshistorien, Retourendaten und Kommunikationsprotokolle. Zahlungsdaten – ob Kreditkartennummer, IBAN oder Transaktions-ID beim Zahlungsdienstleister – bilden eine eigene Kategorie mit verschärften Anforderungen.
Typischer Fehler: Betreiber dokumentieren nur die offensichtlichen Eingabefelder, nicht aber die automatisch erfassten Metadaten und Logdateien. Server-Logs speichern IP-Adressen mit Zeitstempel, manche Systeme protokollieren sogar fehlgeschlagene Zahlungsversuche oder abgebrochene Käufe. Auch diese Daten unterliegen der Dokumentationspflicht.
Eigenverantwortung und Auftragsverarbeitung: Wer haftet für was
Die zentrale Unterscheidung betrifft die Rollenzuordnung nach Datenschutzrecht. Der Website-Betreiber ist grundsätzlich Verantwortlicher für alle Datenverarbeitung. Sobald ein Dienstleister im Auftrag des Betreibers tätig wird, liegt Auftragsverarbeitung vor – etwa bei einem extern gehosteten Shopsystem, einem Buchungskalender-Anbieter oder einem E-Mail-Versanddienst für Bestellbestätigungen.
Auftragsverarbeitung liegt nicht vor, wenn der Dienstleister eigenständig über Zweck und Mittel der Verarbeitung entscheidet. Das ist bei Zahlungsdienstleistern regelmäßig der Fall: Sie verarbeiten Daten für eigene Zwecke (Zahlungsabwicklung, Betrugsprävention) und sind selbst Verantwortliche. Gleiches gilt für Analyse-Dienste, die über eigene Zwecke hinaus Profile erstellen.
Ein Auftragsverarbeitungsvertrag muss schriftlich oder elektronisch in Textform vorliegen, bevor die Verarbeitung beginnt. Wesentliche Inhalte: Gegenstand und Dauer der Verarbeitung, Art und Zweck der Daten, Verpflichtungen zur Einhaltung von Weisungen, zum Datenlöschungsrecht, zur Vertraulichkeit und zur Gewährleistung der Datensicherheit. Generische Vorlagen aus dem Internet greifen oft zu kurz, weil sie die konkreten Verarbeitungstätigkeiten des eingesetzten Systems nicht abbilden.
Zahlungsdienstleister als eigene Risikostelle
Zahlungsdaten bergen ein erhöhtes Schadenspotenzial bei Missbrauch. Die datenschutzrechtliche Verantwortung teilt sich hier: Der Betreiber muss die korrekte Einbindung gewährleisten, der Zahlungsdienstleister trägt die Verantwortung für die eigentliche Zahlungsabwicklung. Praktisch bedeutet das: Der Betreiber darf keine vollständigen Kreditkartennummern oder CVV-Codes auf seinem Server speichern, wenn er nicht explizit dazu berechtigt ist und die dafür erforderlichen Sicherheitsstandards implementiert hat.
Bei der Einbindung von Zahlungsfenstern ist zu prüfen, ob diese als iFrame, Weiterleitung oder API-Schnittstelle realisiert sind. Jede Variante hat unterschiedliche Implikationen für die Datenverarbeitung und die erforderlichen Informationen in der Datenschutzerklärung. Der Ratgeber zu Online-Zahlung und Dienstleistern behandelt diese technischen Unterschiede und ihre datenschutzrechtliche Bewertung ausführlicher.
Typischer Fehler: Betreiber geben Zahlungsdaten an Dritte weiter, ohne die Schnittstellenkonfiguration zu dokumentieren oder zu prüfen, ob tatsächlich nur die notwendigen Daten fließen. Manche Schnittstellen übermitteln automatisch Warenkorbinhalte oder Kundenhistorien, die für die Zahlungsabwicklung nicht erforderlich sind.
SaaS gegenüber Selbsthosting: Unterschiede in der Kontrolle
Software-as-a-Service-Lösungen für Buchung und Verkauf erleichtern den Betrieb, schränken aber die Kontrolle über die Datenverarbeitung ein. Der Anbieter bestimmt Serverstandort, Update-Zyklen und oft auch die verfügbaren Konfigurationsoptionen. Der Betreiber muss sicherstellen, dass der SaaS-Anbieter Verarbeitungsstandorte in der EU oder im EWR nennt oder – bei Drittstaaten – geeignete Garantien für das Datenschutzniveau vorweist.
Selbstgehostete Systeme erlauben weitreichendere Kontrolle, setzen aber entsprechendes technisches Wissen voraus. Der Betreiber trägt selbst für Serverhärtung, Verschlüsselung, Backups und Zugriffskontrollen Verantwortung. Die Dokumentationspflicht ist hier umfangreicher, weil keine Auftragsverarbeitung beim Hosting-Anbieter vorliegt, sofern dieser nur reinen Speicherplatz zur Verfügung stellt.
Entscheidend ist in beiden Fällen die tatsächliche Konfiguration, nicht die theoretische Möglichkeit. Ein selbstgehostetes System mit unzureichenden Zugriffsrechten ist datenschutzrechtlich problematischer als ein gut konfiguriertes SaaS-Produkt.
Cookie-Einwilligungen und Tracking in Verkaufsprozessen
Buchungs- und Shopsysteme setzen Cookies für Funktionen, die über die reine Speicherung von Warenkorbinhalten hinausgehen. Dazu gehören Session-Management, Sicherheitsfunktionen (CSRF-Schutz), Spracheinstellungen und – bei eingebundenen Drittsystemen – Analyse- oder Marketing-Cookies.
Technisch notwendige Cookies bedürfen keiner Einwilligung, müssen aber transparent beschrieben werden. Sobald Tracking, Remarketing oder Analysewerkzeuge eingebunden werden, ist eine vorherige, freiwillige und dokumentierte Einwilligung erforderlich. Die Einwilligung muss für jeden Zweck gesondert erfolgen, Voreinstellungen müssen deaktiviert sein.
Typischer Fehler: Betreiber verwechseln funktionale Cookies mit notwendigen Cookies. Ein Cookie, das das Nutzerverhalten über mehrere Seitenaufrufe hinweg für Analysezwecke speichert, ist nicht technisch notwendig im Sinne des Datenschutzes. Auch die Speicherung von Warenkorbdaten über die aktuelle Session hinaus erfordert eine Prüfung, ob sie tatsächlich unbedingt erforderlich ist.
Pflichten in der Datenschutzerklärung bei Transaktionssystemen
Die Datenschutzerklärung muss bei Buchungs- und Shopsystemen spezifischer sein als bei reinen Informationsangeboten. Neben den allgemeinen Angaben zum Verantwortlichen und den Betroffenenrechten gehört dazu:
- Die vollständige Aufzählung der verarbeiteten Kategorien personenbezogener Daten, einschließlich automatisch erfasster Daten
- Die Zwecke der Verarbeitung für jeden Verarbeitungsschritt (Buchung, Zahlung, Versand, Kommunikation)
- Die Rechtsgrundlagen, differenziert nach Vertragserfüllung, rechtlicher Verpflichtung oder Einwilligung
- Die Empfänger oder Kategorien von Empfängern, insbesondere Zahlungsdienstleister, Versanddienstleister, Buchhaltungssoftware
- Die Speicherdauer oder die Kriterien zu ihrer Festlegung
- Hinweise auf Datenübermittlungen in Drittstaaten, sofern relevant
Besonders bei der Speicherdauer zeigt sich oft Unsicherheit. Rechnungsdaten müssen aus steuerrechtlichen Gründen in der Regel zehn Jahre aufbewahrt werden. Kontaktdaten für Marketingzwecke dürfen nur so lange gespeichert werden, wie die Einwilligung besteht. Die Datenschutzerklärung sollte diese Differenzierung abbilden und nicht pauschale Angaben machen.
Typische Konfigurationsfehler und ihre Folgen
Die meisten datenschutzrechtlichen Probleme bei Buchungs- und Shopsystemen entstehen nicht durch das System selbst, sondern durch seine Einrichtung:
Unzureichende Zugriffsrechte: Mitarbeitende sehen alle Kundendaten, obwohl ihre Rolle dies nicht erfordert. Das widerspricht dem Grundsatz der Datensparsamkeit.
Fehlende Testmodi: Schnittstellen zu Zahlungsdienstleistern oder E-Mail-Systemen werden im Live-Betrieb getestet, statt mit Testdaten und Sandbox-Umgebungen zu arbeiten.
Nicht dokumentierte Änderungen: Updates des Systems oder neue Plugins ändern die Datenverarbeitung, ohne dass das Verarbeitungsverzeichnis angepasst wird.
Voreingestellte Marketing-Optionen: Checkboxen für Newsletter oder Datenaustausch mit Partnern sind vorausgewählt. Das ist bei Einwilligungserfordernissen rechtswidrig.
Fehlende Löschroutinen: Testbuchungen, abgebrochene Käufe und veraltete Kundenkonten verbleiben unbegrenzt in der Datenbank.
Unklare Verantwortlichkeiten bei Schnittstellen: Mehrere Systeme tauschen Daten aus, ohne dass dokumentiert ist, welches System welche Daten wann verarbeitet.
Diese Fehler führen nicht automatisch zu Bußgeldern, sie erhöhen aber das Risiko bei Prüfungen und erschweren die Nachweisführung gegenüber Betroffenen.
Praktische Prüfpunkte für Bestandswebsites
Betreiber, die ihre bestehenden Buchungs- oder Shopsysteme überprüfen möchten, können an folgenden Punkten ansetzen:
1. Verarbeitungsverzeichnis aktualisieren: Tatsächliche Datenflüsse mit den dokumentierten abgleichen. Fehlen automatisch erfasste Daten oder Schnittstellen?
2. Auftragsverarbeitungsverträge prüfen: Liegen für alle Dienstleister, die im Auftrag tätig sind, aktuelle Verträge vor? Decken sie die konkret genutzten Funktionen ab?
3. Datenschutzerklärung auf Vollständigkeit prüfen: Sind alle eingesetzten Dienste benannt? Sind die Speicherdauern differenziert dargestellt?
4. Cookie-Einwilligung testen: Werden nicht notwendige Cookies erst nach Einwilligung gesetzt? Ist die Einwilligungslösung dokumentierbar?
5. Zahlungsabwicklung überprüfen: Wo werden Zahlungsdaten erfasst, wo verarbeitet, wo gespeichert? Gibt es Daten, die unerwartet auf eigenen Servern landen?
6. Zugriffsrechte überprüfen: Entsprechen die Benutzerrollen den tatsächlichen Aufgaben? Gibt es Inaktive mit Zugriff?
7. Löschkonzepte umsetzen: Gibt definierte Fristen für verschiedene Datenkategorien? Werden diese automatisiert oder mannhaft umgesetzt?
8. Schnittstellen dokumentieren: Welche Systeme tauschen wie Daten aus? Wer ist für welchen Verarbeitungsschritt verantwortlich?
Datenschutz bei Buchungs- und Shopsystemen ist eine dauerhafte Begleitaufgabe, keine einmalige Zertifizierung. Wer die tatsächlichen Datenflüsse versteht und dokumentiert, kann Risiken einschätzen und gezielt minimieren. Die Suche nach dem angeblich "DSGVO-konformen" System lenkt davon ab, dass die Konfiguration und der laufende Betrieb weitaus entscheidender sind als die Produktauswahl.
Bei der Überprüfung bestehender Systeme oder der Planung neuer Buchungs- und Shopfunktionen unterstützt die INREMA Unternehmensberatung mit einer neutralen Analyse der datenschutzrechtlichen Anforderungen und deren Umsetzung im konkreten Einzelfall.
