LoyaFlow Datenverarbeitungsvereinbarung (DPA)
Höflichkeitsübersetzung. Die verbindliche Fassung dieses Dokuments ist die englische: English version. Bei Abweichungen hat die englische Fassung Vorrang.
Diese Datenverarbeitungsvereinbarung ("DPA") ist Bestandteil der Vereinbarung zwischen Abdelfattah el Alouani (Wülflingerstrasse 165, 8408 Winterthur, Schweiz — "LoyaFlow", der "Auftragsverarbeiter") und dem Händler (der "Verantwortliche") für die Nutzung der LoyaFlow-Plattform (der "Dienst").
1. Rollen und Umfang
1.1 Für Endkundendaten — personenbezogene Daten der Kunden des Händlers, die im Dienst verarbeitet werden — ist der Händler der Verantwortliche und LoyaFlow der Auftragsverarbeiter. LoyaFlow verarbeitet Endkundendaten nur nach den dokumentierten Anweisungen des Händlers, wobei dieses DPA und die Nutzung der Funktionen des Dienstes diese Anweisungen darstellen, sofern nicht ein Gesetz, dem LoyaFlow unterliegt, etwas anderes vorschreibt (in diesem Fall informiert LoyaFlow den Händler vor der Verarbeitung, sofern das Gesetz dies nicht untersagt).
1.2 Dieses DPA gilt nicht für Daten, für die LoyaFlow selbst Verantwortlicher ist (Händlerkonto-, Abrechnungs- und Supportdaten) — diese Verarbeitung ist im Plattform-Datenschutzhinweis beschrieben.
1.3 Verarbeitet LoyaFlow Endkundendaten ausserhalb der Anweisungen des Händlers, gilt LoyaFlow für diese Verarbeitung als Verantwortlicher und haftet als solcher.
2. Einzelheiten der Verarbeitung (Art. 28 Abs. 3 DSGVO)
| Gegenstand | Betrieb des digitalen Treueprogramms des Händlers (Einbindung, Wallet-Pässe, Treueaktivität, Programmkommunikation). |
| Dauer | Laufzeit der Händlervereinbarung + die 30-tägige Abwicklungsfrist (Abschnitt 9). |
| Art und Zweck | Hosting und Speicherung; Ausstellung, Signierung, Verteilung, Aktualisierung und Widerruf von Wallet-Pässen; Erfassung von Treueereignissen; Versand technischer Push-Benachrichtigungen; Anmeldeseiten; Kundenverwaltung, Export- und Löschwerkzeuge; Support. |
| Kategorien betroffener Personen | Die Kunden des Händlers (Mitglieder des Treueprogramms). |
| Kategorien personenbezogener Daten | Identität: vollständiger Name. Kontakt: E-Mail-Adresse, Telefonnummer (soweit vom Händler erhoben). Programmdaten: Kartenkennung, Punkte-/Stempelsaldo, Stufe, Aktivitätsverlauf (Gutschrifts-/Einlösungs-/Anpassungsereignisse mit Zeitstempeln). Einbindungs-Metadaten: bevorzugte Locale, akzeptierte Version der Händler-Datenschutzerklärung, Zeitstempel der Marketing-Einwilligung. Geräte-/Pass-Daten: Pass-Seriennummer, Gerätebibliothek-Kennungen, Push-Tokens. Technische Daten: Anfrageprotokolle (IP-Adresse, User-Agent), kurzfristig aus Sicherheitsgründen aufbewahrt. Modul-Daten (sofern der Händler das entsprechende Zusatzmodul aktiviert): Buchungen und Termine — Kontaktname, E-Mail, normalisierte Telefonnummer, Personenzahl, gewünschtes Datum/Uhrzeit, gewählte Dienstleistung/Mitarbeiter, Buchungsstatus einschliesslich No-Show-Verlauf, interne Notizen des Händlers, Zeitstempel gesendeter Erinnerungen; Missbrauchs-Sperrliste — gesperrte E-Mail-Adressen und normalisierte Telefonnummern mit optionaler Notiz des Händlers (Rechtsgrundlage: berechtigtes Interesse des Händlers, Art. 6 Abs. 1 lit. f DSGVO); Erinnerungs-E-Mails — Empfängeradresse und Nachrichteninhalt zum Zeitpunkt des Versands. Die Digitale Speisekarte enthält ausschliesslich Inhalte des Händlers (keine personenbezogenen Endkundendaten). |
| Besondere Kategorien | Keine. Der Dienst ist nicht dafür ausgelegt, und der Händler darf ihn nicht dafür verwenden, besondere Kategorien personenbezogener Daten oder Daten von Kindern im Sinne des anwendbaren Rechts zu verarbeiten. |
3. Pflichten des Auftragsverarbeiters
LoyaFlow wird:
- (a) Anweisungen. Endkundendaten nur wie in Abschnitt 1.1 beschrieben verarbeiten und den Händler informieren, falls eine Anweisung nach Auffassung von LoyaFlow gegen Datenschutzrecht verstösst.
- (b) Vertraulichkeit. Sicherstellen, dass zur Verarbeitung der Daten befugte Personen zur Vertraulichkeit verpflichtet sind (vertraglich oder gesetzlich).
- (c) Sicherheit. Die technischen und organisatorischen Massnahmen in Anhang II umsetzen und aufrechterhalten, sie mit fortschreitender Technologie überprüfen und aktualisieren — einschliesslich Verschlüsselung während der Übertragung und im Ruhezustand, strikter Mandantentrennung, laufender Aktualisierung des Dienstes und kontinuierlicher Überwachung.
- (d) Unterauftragsverarbeiter. Unterauftragsverarbeiter nur gemäss Abschnitt 4 hinzuziehen.
- (e) Rechte betroffener Personen. Den Händler, soweit möglich und unter Berücksichtigung der Art der Verarbeitung, bei der Beantwortung von Anfragen betroffener Personen unterstützen. Der Dienst stellt Self-Service-Werkzeuge bereit: Kundenexport und -löschung im Dashboard sowie einen öffentlichen Anfragekanal auf der Pass-Seite (Abmeldung wird sofort ausgeführt; Export- und Löschanfragen werden zur Erfüllung an den Händler weitergeleitet).
- (f) Meldung von Verletzungen. Den Händler unverzüglich, spätestens jedoch innerhalb von 48 Stunden, nachdem eine Verletzung des Schutzes von Endkundendaten bekannt wurde, benachrichtigen, mit den Informationen, die für die eigenen Meldepflichten des Händlers vernünftigerweise erforderlich sind, und bei der Untersuchung und Schadensbegrenzung mitwirken.
- (g) Unterstützung. Unter Berücksichtigung der Art der Verarbeitung und der verfügbaren Informationen den Händler bei dessen Pflichten nach Art. 32–36 DSGVO unterstützen (Sicherheit, Meldung von Verletzungen, Datenschutz-Folgenabschätzungen, vorherige Konsultation).
- (h) Löschung und Rückgabe. Nach Abschnitt 9 am Ende der Leistungen verfahren.
- (i) Prüfungen. Die zum Nachweis der Einhaltung von Art. 28 vernünftigerweise erforderlichen Informationen zur Verfügung stellen und Prüfungen gemäss Abschnitt 8 ermöglichen.
4. Unterauftragsverarbeiter
4.1 Der Händler erteilt eine allgemeine schriftliche Genehmigung für die in Anhang I aufgeführten Unterauftragsverarbeiter.
4.2 LoyaFlow wird mindestens 30 Tage im Voraus (im Dashboard und/oder per E-Mail) ankündigen, bevor ein Unterauftragsverarbeiter hinzugefügt oder ersetzt wird. Der Händler kann aus angemessenen datenschutzrechtlichen Gründen widersprechen; wird keine Lösung gefunden, kann der Händler das betroffene Abonnement mit Wirkung zum Zeitpunkt der Änderung kündigen, mit anteiliger Rückerstattung vorausbezahlter Gebühren für den verbleibenden Zeitraum.
4.3 LoyaFlow legt jedem Unterauftragsverarbeiter vertraglich Datenschutzpflichten auf, die ein gleichwertiges Schutzniveau wie dieses DPA bieten, und bleibt gegenüber dem Händler in vollem Umfang für die Leistung seiner Unterauftragsverarbeiter verantwortlich.
5. Internationale Datenübermittlungen
5.1 Primäre Speicherung und Verarbeitung finden in Rechenzentrumsregionen der Schweiz/des EWR statt. Übermittlungen zwischen der Schweiz, dem EWR und dem Vereinigten Königreich stützen sich auf deren gegenseitige Angemessenheitsbeschlüsse und erfordern keine zusätzlichen Garantien.
5.2 Unterauftragsverarbeiter in den Vereinigten Staaten (Anhang I) erhalten begrenzte Datensätze im Rahmen des EU-U.S. Data Privacy Framework und seiner Schweizer und UK-Erweiterungen und/oder der Standardvertragsklauseln, wie in Anhang I angegeben.
6. Datenschutz-Folgenabschätzungen
Der Händler ist für seine eigenen Datenschutz-Folgenabschätzungen verantwortlich. LoyaFlow stellt die Beschreibungen in diesem DPA (einschliesslich der Anhänge) als Tatsachengrundlage sowie auf Anfrage angemessene zusätzliche Informationen bereit.
7. Haftung
Die Haftung nach diesem DPA unterliegt der Haftungsklausel der Nutzungsbedingungen, ausser soweit das Datenschutzrecht anderes vorschreibt (die Aufteilung nach Art. 82 DSGVO zwischen Verantwortlichem und Auftragsverarbeiter bleibt unberührt).
8. Prüfungen
Nach 30-tägiger schriftlicher Ankündigung, höchstens einmal pro Jahr (ausser nach einer wesentlichen Verletzung oder wenn von einer Aufsichtsbehörde verlangt), kann der Händler die Einhaltung dieses DPA durch LoyaFlow prüfen — zunächst anhand von Dokumentation, Zertifizierungen und Prüfberichten von LoyaFlow und seinen Infrastrukturanbietern; eine Vor-Ort-Prüfung, sofern zwingend erforderlich, erfolgt auf Kosten des Händlers, während der Geschäftszeiten, ohne Zugriff auf Daten anderer Händler.
9. Ende der Verarbeitung (Abwicklung)
9.1 Bei Beendigung oder Ablauf der Händlervereinbarung: Pässe werden sofort ungültig gemacht; Endkundendaten werden 30 Tage aufbewahrt (Sicherheit, Betrugsprävention, Reaktivierung), während derer der Händler sie exportieren kann; nach 30 Tagen werden sie gelöscht, ausser soweit die Aufbewahrung gesetzlich vorgeschrieben ist (in diesem Fall werden die Daten isoliert und geschützt, bis der Rechtsgrund entfällt). Die eigenen Konto- und Konfigurationsdaten des Händlers (Branding, Kartenvorlagen, Einstellungen — keine Endkundendaten) werden bis zu 90 Tage nach Schliessung aufbewahrt, um eine Reaktivierung zu ermöglichen, und dann gelöscht. Backups werden im Rahmen ihres eigenen Rotationszyklus innerhalb einer begrenzten Frist bereinigt.
9.2 Die Löschung erfasst alle Unterauftragsverarbeiter (verbreitet über die Abwicklungs-Jobs: Widerruf von Wallet-Pässen bei Apple/Google, Bereinigung von Datenbank und Speicher).
Anhang I — Genehmigte Unterauftragsverarbeiter (v1.1)
| Unterauftragsverarbeiter | Dienstleistung | Betroffene Daten | Standort/Region | Übermittlungsgarantie |
|---|---|---|---|---|
| Supabase, Inc. | Datenbank, Authentifizierung, Dateispeicherung | Alle Kategorien von Endkundendaten (Abschnitt 2) | AWS eu-central-1 (Frankfurt, Deutschland) | EWR-Hosting; DPF/Standardvertragsklauseln für etwaigen US-Support-Zugriff |
| Google Cloud (Google Ireland Ltd / Google LLC) | Anwendungs-Hosting (Cloud Run, europe-west1), Secret-Management, Logging, Bildspeicherung | Pass-Inhalt zum Erstellungszeitpunkt (Name, Saldo, Branding), Anfrageprotokolle, gespeicherte Bilder | EU (Belgien) | EWR-Hosting; DPF für US-Muttergesellschaft |
| Apple Inc. | Apple Push Notification Service (Pass-Aktualisierung) | Nur Geräte-Push-Token — Benachrichtigungen enthalten eine leere Nutzlast (kein personenbezogener Inhalt) | USA | EU-U.S. DPF + Schweizer/UK-Erweiterungen |
| Google LLC | Google Wallet API (Android-Pässe) | Pass-Inhalt: Name, Saldo/Stempel, Karten-ID, Branding des Händlers | USA | EU-U.S. DPF + Schweizer/UK-Erweiterungen |
| Cloudflare, Inc. | DNS, CDN, Edge-Sicherheit vor öffentlichen Seiten | Transitverkehr (IP, Anfrage-Metadaten) | Globales Edge (EU-Einstiegspunkte) | DPF + Standardvertragsklauseln |
| Amazon Web Services EMEA SARL (Amazon SES) | Zustellung von Transaktions-E-Mails — Programmbenachrichtigungen und, mit den Buchungs-/Terminmodulen, Buchungsbestätigungen und Erinnerungen an Endkunden | Empfänger-E-Mail-Adresse, Nachrichteninhalt | AWS eu-central-1 (Frankfurt, Deutschland) | EWR-Region; Standardvertragsklauseln/DPF für etwaigen US-Support-Zugriff |
| Resend, Inc. | Zustellung von Transaktions-E-Mails (Legacy-/Fallback-Übertragungsweg, wird schrittweise abgelöst) | Empfänger-E-Mail-Adresse, Nachrichteninhalt | USA | DPF / Standardvertragsklauseln |
Hinweis: Paddle (Zahlungen/Merchant of Record) verarbeitet die Abrechnungsdaten des Händlers, nicht Endkundendaten, und erscheint daher im Plattform-Datenschutzhinweis, nicht in diesem Anhang.
Anhang II — Technische und organisatorische Massnahmen (TOM, v1.0)
Architektur & Mandantentrennung
- Strikte Mandantentrennung, durchgesetzt in der Datenbank mittels Row-Level-Security auf jeder Mandanten-Tabelle, verknüpft mit der serverseitigen Sitzungsidentität des Händlers — Clients übermitteln niemals ihre Mandanten-ID.
- Schreibzugriffe auf Programmdaten erfolgen ausschliesslich über eine kontrollierte serverseitige API-Oberfläche (Stored Procedures); keine direkten Tabellen-Schreibzugriffe von Clients.
- Die anonyme (nicht angemeldete) Oberfläche ist auf fünf capability-beschränkte Funktionen begrenzt (Anmelde- und Pass-Seiten), jeweils durch eine nicht erratbare Kennung beschränkt; kein anonymer Tabellenzugriff.
Verschlüsselung & Geheimnisse
- TLS für alle Daten während der Übertragung; vom Anbieter verwaltete Verschlüsselung im Ruhezustand für Datenbank, Speicher und Backups.
- Private Schlüssel zur Pass-Signierung werden verschlüsselt gespeichert (AES-256, passphrasengeschützt) und zur Laufzeit ausschliesslich über einen verwalteten Geheimnisspeicher (GCP Secret Manager) bereitgestellt; niemals im Code oder in Images.
- API-Schlüssel werden als gesalzene Hashes gespeichert (einmalig angezeigt); pro-Pass- Authentifizierungstoken; öffentliche Pass-Links sind Capability-URLs (nicht erratbare UUIDs).
Betrieb
- Service-Konten nach dem Prinzip der geringsten Rechte pro Workload; Validierung von Zertifikaten beim Start (Ablauf und Kette) mit Fail-Fast bei Fehlkonfiguration.
- Der Dienst wird aktuell gehalten und überwacht: Abhängigkeits-Updates, strukturierte Protokolle, Fehlerüberwachung mit Wiederholungsversuchen und Dead-Letter-Rettung für asynchrone Jobs sowie Missbrauchsbegrenzungen (Ratenobergrenzen, Instanzobergrenzen, Nutzlastobergrenzen) auf öffentlichen Endpunkten.
- Dokumentiertes, versioniertes Datenbankschema (Append-only-Migrationen); Produktionsänderungen werden vor der Bereitstellung geprüft und gegen eine Staging-Validierungsschleife verifiziert.
Datenlebenszyklus
- Logische Löschung, gefolgt von einem 30-tägigen Aufbewahrungsfenster, dann Bereinigung (PII-Phase); Wallet-Pässe werden bei Löschung sofort ungültig gemacht.
- Kurze Aufbewahrung für technische Protokolle/Anfrageprotokolle; Geräteprotokoll-Endpunkt begrenzt und nicht über den betrieblichen Bedarf hinaus aufbewahrt.
- Point-in-Time-Recovery und Backups in der Produktion, Bereinigung nach Rotation.
Personen & Prozesse
- Zugriff auf die Produktion beschränkt auf befugtes, zur Vertraulichkeit verpflichtetes Personal; persönliche Konten, MFA auf Anbieter-Konsolen.
- Vorfall-Playbook: Erkennen → Eindämmen → Bewerten → Verantwortlichen innerhalb von 48 h benachrichtigen → Dokumentieren.
Version 1.1 · Gültig ab: 29. August 2026 · Verbindliche Sprache: Englisch.