1. Parteien, Rollen und Abgrenzung
[Restaurantbetreiber mit vollständiger Firma/Name, Anschrift und Kontakt als Verantwortlichen einsetzen. Tanavo-Anbieter mit vollständigen Anbieterangaben als Auftragsverarbeiter einsetzen.]
Diese Anlage soll nur die Verarbeitung von Gast-, Reservierungs-, CRM-, Wartelisten- und Workforce-Daten des Restaurants durch Tanavo auf dokumentierte Weisung erfassen. Für eigene Zwecke von Tanavo – etwa eigene Konten, Authentifizierung, Plattformbetrieb, Sicherheits-/Auditprotokolle sowie eigene Vertrags- oder Abrechnungsverwaltung, soweit tatsächlich betrieben – ist Tanavo gesondert als möglicher eigener Verantwortlicher zu beschreiben. Gemeinsame Verantwortlichkeit ist anhand der tatsächlichen Zweck- und Mittelbestimmung zu prüfen.
Die Codebasis sieht für die Abwesenheitsfunktion einen Zugriffspfad für Restaurantinhaber und Platform-Admins vor. Platform-Admin-Zugriff kann daher potenziell Abwesenheitsangaben einschließlich des Typs „krank“ umfassen. Die Laufzeitberechtigung wurde nicht mit einer gespeicherten normalen Client-Rollenmatrix bestätigt. Zweck, Notwendigkeit, Freigabe, Vertraulichkeit und Protokollierung dieses Supportzugriffs sind als Vertrags- und TOM-Entscheidung offen.
2. Gegenstand, Dauer, Art und Zweck
Gegenstand ist die Bereitstellung der konkret beauftragten Tanavo-Funktionen während der Vertragslaufzeit. [Beginn, Ende, Übergangsfrist und Lösch-/Rückgabezeit nach Vertragsende eintragen.]
Codegestützte Verarbeitungsvorgänge können Erheben/Übermitteln durch Restaurantnutzer oder Gast, Erfassen, Ordnen, Speichern, Abrufen, Anzeigen, Aktualisieren, Auswerten, eingeschränktes Exportieren und Löschen umfassen. Zwecke sind – nur soweit das Restaurant die Funktion beauftragt und freigibt – Reservierungs- und Wartelistenbetrieb, Gästebeziehungsverwaltung, Dienstplanung, Arbeitszeiterfassung, Kiosk-Betrieb und Abwesenheitsverwaltung. Transaktions-E-Mails können über die integrierte Resend-API versendet werden; ob und für welche Umgebung diese tatsächlich aktiviert ist, ist zu bestätigen.
3. Betroffene Personen und Datenarten
• Gäste und Reservierende: Name, Telefon, optionale E-Mail, Reservierungs-/Besuchsdatum und -zeit, Gruppengröße, Status, Referenz, Quelle und Notizen; CRM-Kontaktwerte, Besuchs-/Stornierungs-/No-show-Kennzahlen, Tags und interne Notizen; Wartelisteneinträge und begrenzte E-Mail-Zustellmetadaten.
• Restaurantkontoinhaber, Nutzer und Beschäftigte: Auth-Nutzerkennung, Name, E-Mail, Restaurantzuordnung, Rolle, Berechtigungen und Status; Schichten, Arbeitszeiten, Pausen, Einsatzbereich, Zeiterfassungsquelle, Korrekturen/Begründungen sowie Kiosk-Geräte- und Zugriffsdaten.
• Abwesenheiten: Teammitglied, Abwesenheitstyp (Urlaub/krank/sonstiger Grund), Zeitraum und erfassende Person. Das Krankheitsmerkmal kann Gesundheitsdaten offenbaren und besondere Kategorien berühren. Keine Diagnose-/Belegfelder sind im geprüften Schema ausgewiesen; Freitext darf dafür nicht zweckentfremdet werden. Aufnahme und Verarbeitung solcher Angaben setzen die vom Verantwortlichen festgelegte Rechtsgrundlage und Art.-9-Ausnahme sowie passende Garantien voraus.
• Die konkrete Funktion-/Datenliste ist je Kundenauftrag und aktivierten Modulen zu bestätigen; Auth-Geheimnisse und interne Versandpayloads sind nicht als allgemeine Kundendatenexporte vorgesehen.
4. Weisungen, Vertraulichkeit und Rechte
[Weisungsberechtigte Personen, dokumentierter Weisungskanal, Vertraulichkeitsverpflichtung, Prüfung rechtswidriger Weisungen und Nachweisführung festlegen.]
Der Code enthält einen restaurantbezogenen Workflow, um Datenschutzanfragen zu einem CRM-Gast aufzunehmen, eine Identitätsprüfung zu vermerken und nach Verifizierung einen begrenzten Gästeexport anzufordern. Er stellt weder einen vollständigen Betroffenenrechte-Service noch einen vollständigen Restaurant-/Anbieterwechsel-Export bereit; eine allgemeine automatische Löschung ist nicht belegt. Umfang und rechtmäßige Erledigung entscheidet der Verantwortliche. [Unterstützungsprozess und Antwortfristen vertraglich festlegen.]
5. Sicherheit und besondere Zugriffspfade
Im Repository sind RLS, Rollenprüfungen und serverseitige Funktionen implementiert. Die Abwesenheitsmigration beschränkt die vorgesehene Berechtigung auf Inhaber und Platform-Admins; Metadaten-/Migrationsnachweise ersetzen keine Client-Rollenprüfung. Gespeicherte Runtime-Autorisierungstests für die Rollenmatrix liegen nicht als bestanden vor.
[Konkrete aktuelle TOM-Anlage erstellen und verifizieren: Zugriff/Minimalrechte, Authentifizierung, Vertraulichkeit, Verschlüsselung, Protokollierung und Kontrolle, Verfügbarkeit/Wiederherstellung, Tests, sichere Entwicklung, Personal und Schlüsselverwaltung. Keine im Betrieb nicht belegte Maßnahme zusagen.]
6. Unterauftragsverarbeiter und Übermittlungen
Der aktuelle Anwendungshost ist Cloudflare; Supabase wird für Authentifizierung, Datenbank und Storage eingesetzt; Resend ist als möglicher E-Mail-Versand vorgesehen. Diese technischen Angaben belegen nicht, welche Konten/Verträge aktiv sind oder wer welche Daten tatsächlich verarbeitet.
[Für jeden tatsächlich eingesetzten Anbieter Rechtsträger, konkrete Leistung, Datenkategorien, Verarbeitungsorte, Vertrags-/DPA-Version und Nachweis der Einbeziehung, Unterauftragnehmer, Genehmigung/Änderungsmitteilung, internationale Zugriffe und Transfermechanismus erfassen. Regionen und Vertragsannahmen sind derzeit nicht bestätigt.]
7. Betroffenenanfragen, Sicherheit und Vorfälle
[Verfahren und angemessene Unterstützung bei Rechten, Datenschutz-Folgenabschätzung, vorheriger Konsultation, Nachweisen und Behördenanfragen festlegen.]
[Unverzüglichen internen Meldeweg, Ansprechpartner, Mindestinformationen, Mitwirkungsfristen, Beweissicherung und Eskalation für Datenschutzverletzungen vereinbaren. Der Code definiert allein keine vertragliche Benachrichtigungsfrist.]
8. Laufzeitende: Rückgabe und Löschung
Bei Ende der beauftragten Verarbeitung sind – nach Wahl des Verantwortlichen – Rückgabe oder Löschung sowie Löschung vorhandener Kopien vorzusehen, soweit keine gesetzliche Pflicht zur Aufbewahrung entgegensteht. [Wahlverfahren, Format/Umfang des Restaurant-Gesamtexports, Fristen, Abhängigkeiten, Löschbestätigung und gesetzliche Ausnahmen vereinbaren.]
Der vorhandene CRM-Betroffenenexport ist kein vollständiger Tenant-/Kundenexport für einen Wechsel zu einem anderen SaaS-Anbieter. Eine allgemeine automatische Löschung, Backup-Löschfrist oder vollständige Providerkopien-Löschung ist im geprüften Stand nicht belegt. Diese Punkte benötigen eine konkrete Betriebs- und Vertragslösung, bevor eine Zusage aufgenommen werden kann.
9. Nachweise und Kontrollen
[Benötigte Informationen/Nachweise, Auditverfahren, Vorankündigung, Umfang, Vertraulichkeit, Kosten, Anbieterunterlagen und Umgang mit Feststellungen rechtlich und praktisch vereinbaren.]
Version und Anlagen
AVV-DE-DRAFT-0.3 · Entwurf · kein Vertragsschluss und keine Annahme ausgelöst. Vor Verwendung offen: vollständige Parteien, Verarbeitungsspezifikation, dokumentierte Weisungen, geprüfte TOM, bestätigte Subprozessoren/Transfers, Incident-Kontakte, konkrete Fristen, Export-/Löschverfahren und unterschrifts-/annahmefähige Version.