[VORNAME NACHNAME], handelnd unter der Geschäftsbezeichnung Tanavo, [STRASSE HAUSNUMMER], [PLZ ORT], Deutschland.

E-Mail für Datenschutzanfragen: [GESCHÄFTLICHE DATENSCHUTZ-E-MAIL-ADRESSE]. Telefon: [TELEFONNUMMER]. Datenschutzbeauftragte Person: [NUR EINTRAGEN, WENN EINE BENENNUNG ERFORDERLICH IST ODER ERFOLGT].

Die Angaben zur geplanten deutschen Einzelunternehmung und zur Geschäftsregistrierung sind vor Veröffentlichung zu vervollständigen.

Für den Restaurantbetrieb bestimmt der jeweilige Restaurantbetreiber grundsätzlich Zwecke und wesentliche Mittel der Verarbeitung von Reservierungs-, Walk-in-, Wartelisten-, No-show-, Gäste-CRM- und Workforce-Daten. Soweit Tanavo diese Daten ausschließlich zur Bereitstellung der beauftragten Funktionen nach dokumentierter Weisung verarbeitet, ist Tanavo dafür als Auftragsverarbeiter vorgesehen und der Restaurantbetreiber bleibt Verantwortlicher. Die konkrete Rollenverteilung ist je Zweck, Vertrag und aktivierter Funktion zu bestätigen.

Für eigene Zwecke kann Tanavo Verantwortlicher sein, insbesondere für eigene Konten, Authentifizierung, Plattformbetrieb, Sicherheits- und Auditmaßnahmen, Missbrauchsabwehr sowie eigene Vertrags- und Abrechnungsverwaltung, soweit diese Vorgänge tatsächlich stattfinden. Gemeinsame Verantwortlichkeit ist nicht pauschal ausgeschlossen und muss anhand der tatsächlichen Zweck- und Mittelbestimmung geprüft werden.

Beim Aufruf der Website und der öffentlichen Restaurantseiten werden technisch erforderliche Anfrage- und Verbindungsdaten an die eingesetzten Hosting- und Netzwerkdienste übermittelt. Tanavo hostet die aktuelle Anwendung über Cloudflare. Welche konkreten Protokollfelder, IP-Verkürzungen, Sicherheitsprotokolle, Speicherfristen, Supportzugriffe und Unterauftragnehmer im verwendeten Cloudflare-Konto tatsächlich aktiv sind, ist noch zu bestätigen: [CLOUDFLARE-RECHTSTRÄGER, KONTO, DPA, LOGFELDER, REGIONEN UND FRISTEN ERGÄNZEN].

Die Zwecke sind abhängig von der verifizierten Konfiguration insbesondere Auslieferung, Stabilität, Missbrauchs- und Angriffserkennung sowie Fehleranalyse. [Konkrete Rechtsgrundlage und Interessenabwägung je Logzweck festlegen.] Eine allgemeine Aussage über vollständige Cookielosigkeit oder eine bestimmte Log-Aufbewahrung wird mit diesem Entwurf nicht getroffen.

Für Restaurantinhaber, Platform-Admins und Mitarbeitende können Auth-Nutzerkennung, Name, E-Mail-Adresse, Restaurantzuordnung, Rolle, Berechtigungen und Kontostatus verarbeitet werden. Die Anwendung verwendet Supabase für Authentifizierung. Das konkrete Produktionsprojekt ist Supabase Frankfurt; Rechtsträger, DPA, Unterauftragnehmer, Auth-Logs, Session-Speicher, Supportzugriffe und tatsächliche Speicherorte sind vor Veröffentlichung zu verifizieren: [SUPABASE-ANGABEN ERGÄNZEN].

Platform-Admin-Funktionen können tenantbezogene Betriebs-, Sicherheits- und Verwaltungsdaten sehen. Der Zugriff auf Abwesenheiten ist im geprüften Schema für Restaurantinhaber und Platform-Admins vorgesehen; Zweck, Notwendigkeit, Freigabe, Protokollierung und Begrenzung dieses Zugriffs bleiben offene Betriebs- und Rechtsentscheidungen.

Je nach beauftragter und aktivierter Funktion können Restaurantbetreiber und berechtigte Teammitglieder folgende Daten verarbeiten: Gastname, Telefonnummer, optionale E-Mail-Adresse, Reservierungs- oder Besuchsdatum und -zeit, Gruppengröße, Status, Quelle, Referenz, Notizen und Zugriffswerte.

Walk-in-Besuche werden im implementierten Modell als Reservierungen mit der Quelle walk_in geführt und können mit Gastprofilen, Besuchsende, Tischsitzungen und nicht-identifizierenden Statistikwerten verbunden sein. Wartelisteneinträge können Kontaktangaben, gewünschte Zeit, Gruppengröße, Notizen, Status und Zeitstempel enthalten. No-show-Daten und CRM können Besuchs-, Stornierungs- und No-show-Kennzahlen, normalisierte Kontaktwerte, Tags und interne Notizen enthalten.

Der jeweilige Restaurantbetreiber entscheidet über Zweck, Eingabe und Nutzung dieser Gästedaten. Tanavo verarbeitet sie als Auftragsverarbeiter, soweit dies nur zur Bereitstellung der beauftragten Funktionen erfolgt. Restaurantbetreiber müssen Daten minimieren und dürfen keine Diagnosen oder sonstigen nicht erforderlichen sensiblen Angaben in Freitexten speichern.

Workforce-Funktionen können Schichten mit Datum, Zeiten, Pausen, Bereich und Notiz, Arbeitszeiteinträge mit Beginn, Ende, Quelle und Authentifizierungsmethode sowie Korrekturen mit alten und neuen Werten, Begründung und handelnder Person verarbeiten.

Abwesenheiten können Teammitglied, erfassende Person, Zeitraum und einen Typ wie Urlaub, krank oder sonstiger Grund enthalten. Ein Krankheitsmerkmal kann Gesundheitsdaten offenbaren und damit eine besondere Kategorie nach Art. 9 DSGVO berühren. Das Schema sieht kein Diagnosefeld vor; Diagnosen und medizinische Dokumente gehören nicht in Freitextnotizen. Der Restaurantbetreiber muss Zweck, Erforderlichkeit, Art.-6-Rechtsgrundlage, Art.-9-Ausnahme, Beschäftigtendatenschutz, Zugriff und Frist vor der Nutzung prüfen. Tanavo behauptet mit diesem Entwurf keine entsprechende Rechtsgrundlage.

Bei Reservierungsereignissen kann eine transaktionale Nachricht Name, Empfängeradresse, Besuchsdaten, Gruppengröße, Referenz sowie Restaurantname und Kontaktdaten enthalten. In Tanavo werden für Reservierungs-E-Mail-Ereignisse Status-, Versand-, Fehler-, Provider- und Zeitmetadaten sowie technische Token-/Lease-Felder verarbeitet. Payloads und Providerkennungen können bei einer vorgesehenen Erasure-/Retention-Aktion geleert werden; bereits zugestellte E-Mails, Mailboxkopien, Providerprotokolle und Suppressionsdaten werden dadurch nicht automatisch gelöscht.

Der Quellcode sieht den Versand über eine Supabase Edge Function und Resend vor. Ob Resend in jeder Umgebung tatsächlich aktiviert ist, welche Nachrichten versandt werden, welcher Rechtsträger und welche Speicher-/Löschfristen gelten, ist offen: [RESEND-RECHTSTRÄGER, DPA, DATENORTE, TRANSFERS, LOG-/EVENT-FRISTEN UND SENDERKONFIGURATION ERGÄNZEN]. Marketingversand ist nach dem geprüften Stand nicht als aktiv belegt.

Die Anwendung enthält Strukturen für Plattformrechnungen mit Rechnungsnummer, Status, Datum, Zeitraum, Betrag, Tarif sowie Restaurant- und Absenderdaten. Soweit solche Rechnungen tatsächlich erstellt oder verwaltet werden, können sie für eigene Vertrags- und Abrechnungszwecke von Tanavo verarbeitet werden; verantwortliche Stelle, Rechtsgrundlage, konkrete Dokumentkategorie und gesetzliche Aufbewahrung sind festzulegen.

Stripe, Wallet und Loyalty sind nach dem vorliegenden Betriebsstand deaktiviert. Es wird daher nicht behauptet, dass Tanavo derzeit Stripe-Zahlungsdaten, Wallet-Daten oder Loyalty-Daten verarbeitet. Falls diese Funktionen später aktiviert werden, ist diese Datenschutzerklärung vorab um Anbieter, Zwecke, Datenkategorien, Transfers, Rechtsgrundlagen und Fristen zu ergänzen.

Mögliche Empfänger sind der jeweilige Restaurantbetreiber, von ihm berechtigte Teammitglieder und – für technische Bereitstellung – Cloudflare, Supabase und gegebenenfalls Resend. Der Code allein beweist weder, welche Konten aktuell eingesetzt werden, noch Vertragsrollen, Supportzugriffe, Unterauftragnehmer, Datenorte oder Löschfristen.

Für Cloudflare, Supabase und Resend sind Rechtsträger, konkrete Leistung, Datenkategorien, DPA-Version, Unterauftragsverarbeiter, Verarbeitungsorte und internationale Zugriffe zu dokumentieren: [AKTUELLE PROVIDER- UND VERTRAGSANGABEN ERGÄNZEN]. Für jede Übermittlung in ein Drittland oder jeden Zugriff aus einem Drittland sind Angemessenheitsbeschluss oder geeignete Garantien und gegebenenfalls ergänzende Maßnahmen anzugeben. Es wird kein Drittlandtransfer als rechtlich abgesichert behauptet, bevor diese Nachweise vorliegen.

Der Supabase-Client richtet eine persistente Authentifizierungssitzung über den vorhandenen Speicheradapter ein. Kiosk-Funktionen verwenden im Web localStorage für Gerätekennung sowie Kiosk-/Restaurant-Zugriffswerte. Einzelne Owner-Oberflächen können lokale Ansichts- oder Navigationspräferenzen speichern. Die konkrete ausgelieferte Webkonfiguration, Cookie-Flags, Speicherfristen, eingebettete Inhalte und weitere externe Requests müssen noch durch einen Laufzeittest bestätigt werden.

Im geprüften Abhängigkeitsstand wurde kein SDK für Vercel Analytics oder Speed Insights gefunden. Das ist kein Nachweis, dass Hosting-, Browser- oder Drittanbieterprotokolle ohne Messung auskommen. [Alle Cookies, localStorage-/sessionStorage-Schlüssel, Einbettungen, Telemetrie und erforderlichen Einwilligungen inventarisieren.] Für das Speichern oder Auslesen von Informationen auf Endgeräten ist § 25 TDDDG je Vorgang zu prüfen. Eine Einwilligung oder die Ausnahme für technisch unbedingt Erforderliches darf nicht pauschal angenommen werden.

Tanavo verfügt über eine Retention-Architektur mit konfigurierbaren Kategorien, Vorschau, Legal Holds, tenantbezogenen Prüfungen und einem globalen Schalter. GDPR_RETENTION_ENABLED ist derzeit false; automatische Retention und automatische Löschung sind daher nicht aktiv und wurden mit diesem Entwurf nicht aktiviert. Die konkrete Ausführung hängt zusätzlich von der jeweils geprüften Produktionskonfiguration und einer gültigen Freigabe ab.

Retention- und Löschentscheidungen dürfen nur nach dokumentiertem Zweck, Fristbeginn, Rechtsgrundlage und gesetzlicher Ausnahme erfolgen. Legal Holds können eine Löschung für den konkreten Umfang und Zeitraum sperren. Eine einzelne Löschung in der Datenbank entfernt nicht automatisch Providerprotokolle, bereits zugestellte E-Mails, Exporte, lokale Caches, Storageobjekte oder Backups. Für jede Kategorie sind Frist oder objektive Kriterien, gesetzliche Aufbewahrung, Hold-Verfahren, Providerkopien, Logs, Backups und Fristablauf festzulegen: [AKTUELLE KATEGORIEN, FRISTBEGINNE, FRISTEN UND AUSNAHMEN ERGÄNZEN].

Betroffene können je nach Verarbeitung Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit und Widerspruch verlangen sowie eine erteilte Einwilligung mit Wirkung für die Zukunft widerrufen. Bei Restaurantdaten ist grundsätzlich der Restaurantbetreiber als Verantwortlicher zuständig; Tanavo unterstützt ihn, soweit Tanavo als Auftragsverarbeiter tätig ist. Für Tanavos eigene Verarbeitung ist Tanavo zuständig. Anfragen sind an [DATENSCHUTZ-KONTAKT] zu richten; eine sichere Identitätsprüfung ist erforderlich.

Der Owner-Bereich enthält einen Workflow für Datenschutzanfragen zu einem CRM-Gast. Nach dokumentierter Verifizierung kann ein begrenzter Export für dasselbe Restaurant mit ausgewählten CRM-, Reservierungs-, Wartelisten-, No-show- und Benachrichtigungsdaten angefordert werden. Dieser Workflow ist kein vollständiger Export aller Systeme oder ein vollständiger Anbieterwechsel-Export. Das Erfassen oder Abschließen eines Vorgangs löscht Daten nicht automatisch. Antwortprozess, Fristen, sichere Zustellung, Berichtigung, Einschränkung, Widerspruch und Zuständigkeit je Vorgang müssen organisatorisch verbindlich festgelegt werden.

Die Anwendung verwendet tenantbezogene Zugriffskontrollen, RLS und serverseitige Funktionen. Das sind keine Zusage vollständiger Sicherheit und ersetzen keine aktuelle Prüfung der Live-Konfiguration. Konkrete TOM, Verschlüsselung, Berechtigungsprüfung, Schlüsselverwaltung, Protokollzugriff, Backup-/Wiederherstellungsschutz, Tests und Supportzugriffe sind in einer separaten TOM-Anlage und im Betrieb nachzuweisen.

Datenschutzverletzungen werden nach dem festgelegten internen Verfahren bewertet. [Vertraulichen Vorfallkontakt, Verantwortliche, Eskalation, Dokumentation und gegebenenfalls Meldeprozess an die zuständige Aufsichtsbehörde ergänzen.]

Betroffene haben das Recht, sich bei einer Datenschutzaufsichtsbehörde zu beschweren, insbesondere bei der für ihren gewöhnlichen Aufenthaltsort, Arbeitsplatz oder den Ort des mutmaßlichen Verstoßes zuständigen Behörde. Die für Tanavo maßgebliche Behörde ist vor Veröffentlichung anhand des tatsächlichen Sitzes festzulegen: [NAME, ANSCHRIFT, WEBSITE UND KONTAKT DER ZUSTÄNDIGEN AUFSICHTSBEHÖRDE ERGÄNZEN].

DS-DE-DRAFT-0.3 · Arbeitsentwurf, nicht freigegeben und kein Wirksamkeitsdatum. Vor Veröffentlichung offen: vollständige Anbieterangaben, Datenschutzkontakt und Aufsichtsbehörde; konkrete Zwecke und Rechtsgrundlagen je Verarbeitung; Controller-/Processor-Abgrenzung je Restaurantvertrag; Cloudflare-, Supabase- und Resend-Verträge, Rechtskörper, Datenorte, Subprozessoren und Transfers; Laufzeitprotokolle, Cookies und Endgerätespeicher; Retention-/Hold-Fristen; TOM; Betroffenenrechteprozess sowie Vorfallkontakt.

Dieser Entwurf behauptet keine Aktivierung automatischer Löschung, keine abgeschlossene Drittlandbewertung, keine bestätigte DPA-Einbeziehung und keine rechtliche Freigabe.