Datenschutzerklärung

Verantwortlich für die Datenverarbeitung ist:

nios digital UG (haftungsbeschränkt)
Haderslebener Str. 2
22049 Hamburg, Deutschland
E-Mail: info@nios.digital

Vertretungsberechtigt: Felix Gudowius · Amtsgericht Hamburg, HRB 186579 · USt-IdNr. DE368264501

Wir verarbeiten personenbezogene Daten unserer Nutzerinnen und Nutzer ausschließlich, soweit dies zur Bereitstellung einer funktionsfähigen Website und unserer Inhalte und Leistungen erforderlich ist. Die Verarbeitung erfolgt regelmäßig nur nach Einwilligung der Nutzer (Art. 6 Abs. 1 lit. a DSGVO), zur Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO), aufgrund einer rechtlichen Verpflichtung (Art. 6 Abs. 1 lit. c DSGVO) oder eines berechtigten Interesses (Art. 6 Abs. 1 lit. f DSGVO).

3.1 Bereitstellung des Online-Angebots

Beim Aufruf der Website werden technisch notwendige Verbindungsdaten (IP-Adresse, Browser, Datum/Uhrzeit) verarbeitet. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am stabilen Betrieb).

3.2 Account- und Auth-Cookies

Für Login, Sitzungsverwaltung und CSRF-Schutz setzen wir technisch notwendige Cookies. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) sowie § 25 Abs. 2 Nr. 2 TTDSG (technische Notwendigkeit für den vom Nutzer ausdrücklich gewünschten Telemediendienst).

3.3 Theme- und Sprach-Präferenz (LocalStorage)

Wir speichern deine ausgewählte Optik (Hell/Dunkel) und Spracheinstellung im LocalStorage deines Browsers. Diese Daten verlassen dein Gerät nicht. Rechtsgrundlage ist § 25 Abs. 2 Nr. 2 TTDSG (technische Notwendigkeit) bzw. Art. 6 Abs. 1 lit. f DSGVO (Komfort).

3.4 Statistik / Reichweitenmessung

Aktuell setzen wir keine Reichweitenmess- oder Analytics-Tools ein. Sobald wir z. B. Vercel Analytics oder Sentry aktivieren, erfolgt dies ausschließlich nach deiner Einwilligung im Cookie-Banner (Art. 6 Abs. 1 lit. a DSGVO und § 25 Abs. 1 TTDSG). Technisch werden solche Skripte über die Wrapper-Komponente <ConsentGated category="statistics"> nur dann geladen, wenn die entsprechende Einwilligung vorliegt; bei Widerruf werden sie zur Laufzeit wieder entfernt.

3.5 Marketing-Tracking

Werbe- und Conversion-Tracking ist aktuell nicht aktiv. Vor einer späteren Aktivierung holen wir deine ausdrückliche Einwilligung ein (Art. 6 Abs. 1 lit. a DSGVO und § 25 Abs. 1 TTDSG).

3.6 Zahlungsabwicklung über Stripe

Für kostenpflichtige Tarife nutzen wir den Zahlungsdienstleister Stripe Payments Europe Ltd., 1 Grand Canal Street Lower, Grand Canal Dock, Dublin, Irland. Stripe erhebt für die Vertragsabwicklung erforderliche Daten (Name, E-Mail, Zahlungsdaten). Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO. Stripe ist gemäß PCI-DSS zertifiziert und verarbeitet Kreditkartendaten direkt; wir erhalten keine vollständigen Kartendaten.

Wir schützen personenbezogene und insbesondere sensible Nutzerdaten (z. B. OAuth-Zugriffs- und Refresh-Tokens, Kalenderdaten, Apple App-spezifische Passwörter, Zahlungs- und Account-Informationen) durch ein Set an technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO. Dieses Schutzniveau gilt durchgängig für alle Verarbeitungen — von der Erhebung bis zur Löschung.

4.1 Verschlüsselung in Transit

Sämtliche Verbindungen zwischen deinem Endgerät, unseren Servern und allen eingebundenen Drittanbietern (Google, Apple/iCloud, Stripe, Supabase, Vercel) erfolgen ausschließlich über TLS 1.2 oder höher (HTTPS). Unverschlüsselte HTTP-Verbindungen werden serverseitig per HSTS-Header (Strict-Transport-Security mit includeSubDomains) erzwungen. OAuth-Token-Austausche mit Google laufen ausschließlich über oauth2.googleapis.com server-to-server, niemals über den Client.

4.2 Verschlüsselung sensibler Daten at Rest (AES-256-GCM)

Sensible Geheimnisse werden vor dem Schreiben in die Datenbank symmetrisch mit AES-256-GCM verschlüsselt — einem authentifizierten Verschlüsselungsverfahren, das sowohl Vertraulichkeit als auch Integrität sicherstellt. Konkret betroffen:

• Google OAuth Access- und Refresh-Tokens (Calendar-Sync)
• Apple/iCloud App-spezifische Passwörter (CalDAV)
• sonstige Drittanbieter-Credentials, die wir im Auftrag des Nutzers speichern müssen

Pro Verschlüsselung wird ein frischer 96-Bit-Nonce zufällig erzeugt; der GCM-Authentication-Tag verhindert nachträgliche Manipulation. Der 256-Bit-Master-Schlüssel (BOOKING_CRYPTO_KEY) liegt ausschließlich als Umgebungsvariable in unserer Server-Runtime — er ist nicht im Quellcode, nicht im Client-Bundle und nicht in Logs zu finden. Datenbank-Backups bei Supabase sind zusätzlich AES-256 at-rest verschlüsselt (verwaltet durch Supabase / AWS).

4.3 Zugriffskontrolle und Mandantentrennung

• Row Level Security (RLS): Jede Tabelle in unserer Postgres-Datenbank ist standardmäßig durch RLS-Policies geschützt. Auch im Falle einer fehlerhaften Anwendungs-Query kann ein Nutzer ausschließlich seine eigenen Daten lesen oder schreiben — Mandantentrennung ist auf Datenbankebene erzwungen, nicht nur in der App-Logik.
• JWT-basierte Authentifizierung: Jede API-Route prüft das Supabase-Session-Token in einer dedizierten Proxy-Schicht, bevor die Anfrage einen Route-Handler erreicht. Öffentliche Endpunkte (z. B. der Stripe-Webhook) sind explizit allowlisted und nutzen Signatur-Validierung.
• Rollenmodell: Innerhalb einer Organisation gelten sechs differenzierte Rollen (owner, finance_manager, event_manager, operations, advisor_readonly, client_readonly) — wir vergeben Berechtigungen nach dem Prinzip der minimalen Rechte (Least Privilege).
• Administrativer Zugriff: Service-Role-Keys für administrative Datenbankoperationen liegen ausschließlich serverseitig. Auf Produktivsysteme haben nur autorisierte Mitarbeitende per 2-Faktor-Authentifizierung Zugriff.

4.4 Eingabevalidierung und Schutz vor Injection

Sämtliche eingehenden Daten werden serverseitig per Zod-Schema validiert, bevor sie verarbeitet oder gespeichert werden. Wir nutzen ausschließlich parametrisierte Queries (Supabase-Client), sodass klassische SQL-Injection-Vektoren konstruktionsbedingt ausgeschlossen sind. Authentifizierungs-Endpunkte sind rate-limited.

4.5 Sicherheitsheader und Browser-Schutz

Unsere Web-App liefert folgende HTTP-Header an alle Clients aus:

• Strict-Transport-Security (HSTS) — erzwingt HTTPS inkl. Sub-Domains
• X-Frame-Options: DENY — Schutz vor Clickjacking
• X-Content-Type-Options: nosniff — verhindert MIME-Sniffing
• Referrer-Policy: origin-when-cross-origin — minimaler Referrer-Leak
• Permissions-Policy — schränkt potenziell sensible Browser-APIs (Kamera, Mikrofon, Geolocation, Payment) ein

4.6 Logging, Monitoring und Auditierbarkeit

Wir betreiben strukturiertes Logging mit dem Ziel, sicherheits- und datenschutzrelevante Ereignisse nachvollziehbar zu machen, ohne sensible Inhalte mitzuschreiben. Tokens, Passwörter, Kalender-Termin-Titel/-Beschreibungen, Zahlungsdaten und Klartext-Geheimnisse erscheinen nicht in Logs. Anomalien (gehäufte fehlerhafte Logins, ungewöhnliche API-Muster) werden überwacht. Status-Verläufe in unseren Anwendungstabellen (Booking-Historie, Audit-Logs) ermöglichen die Rekonstruktion relevanter Vorgänge.

4.7 Sichere Softwareentwicklung

• Codeänderungen durchlaufen Pull-Request-Reviews und automatisierte Tests (Vitest, ESLint, TypeScript-Strict-Mode) bevor sie deployt werden.
• Abhängigkeiten werden automatisiert auf bekannte Sicherheitslücken geprüft; sicherheitsrelevante Updates werden zeitnah eingespielt.
• Secrets werden niemals ins Repository committet, sondern als Umgebungsvariablen in Vercel verwaltet.
• Datenbank-Migrationen sind versioniert; alle Schema-Änderungen sind reproduzierbar nachvollziehbar.

4.8 Backups und Wiederherstellung

Unsere Postgres-Datenbank wird durch Supabase automatisiert gesichert (Point-in-Time-Recovery für die letzten 7 Tage, tägliche Snapshots). Backups sind verschlüsselt und liegen in der gleichen EU-Region wie die Primärdatenbank.

4.9 Daten-Pannen (Breach Notification, Art. 33/34 DSGVO)

Im Falle einer Verletzung des Schutzes personenbezogener Daten, die voraussichtlich zu einem Risiko für die Rechte und Freiheiten betroffener Personen führt, melden wir den Vorfall der zuständigen Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden. Bei hohem Risiko informieren wir auch die betroffenen Nutzer unverzüglich per E-Mail an die im Account hinterlegte Adresse. Verdachtsfälle kannst du jederzeit unter info@nios.digital melden.

4.10 Löschung und Datenminimierung

Bei Trennung einer Kalenderverbindung (Google/Apple) werden die verschlüsselten Tokens bzw. Passwörter aus der Datenbank entfernt (auf NULL gesetzt), bei Google zusätzlich serverseitig revoked (Google OAuth Revocation-Endpoint), aktive Push-Notification- Channels werden geschlossen und sämtliche zwischengespeicherten externen Kalender-Events aus der Verfügbarkeitsdatenbank gelöscht. Beim Löschen deines Accounts werden alle nicht durch gesetzliche Aufbewahrungspflichten gebundenen personenbezogenen Daten innerhalb von 30 Tagen entfernt (siehe Abschnitt 6).

Wir setzen sorgfältig ausgewählte Auftragsverarbeiter ein, mit denen jeweils ein Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO abgeschlossen wurde. Alle eingesetzten Dienstleister verfügen über dokumentierte Informationssicherheits-Programme (u. a. SOC 2 Type II, ISO 27001 bzw. PCI-DSS) und verschlüsseln Daten sowohl bei der Übertragung als auch im Ruhezustand:

• Supabase Inc., 970 Toa Payoh North #07-04, Singapur — Hosting der Datenbank und Auth in der EU-Region (Frankfurt). SOC 2 Type II + HIPAA-konform. Daten werden AES-256 at-rest verschlüsselt; Verbindungen ausschließlich über TLS. Datenübermittlung in die USA durch Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO abgesichert.
• Vercel Inc., 440 N Barranca Ave #4133, Covina, CA 91723, USA — Hosting der Web-App (Edge-Funktionen, statische Auslieferung). SOC 2 Type II zertifiziert. Datenübermittlung in die USA durch Standardvertragsklauseln und das EU-US Data Privacy Framework abgesichert.
• Stripe Payments Europe Ltd., Dublin, Irland — Zahlungsabwicklung. PCI-DSS Level 1 zertifiziert. Wir erhalten keine vollständigen Kreditkartendaten — diese werden direkt von Stripe entgegengenommen und tokenisiert. Datenverarbeitung erfolgt innerhalb der EU, ergänzt um SCC-gestützte Übermittlung an die US-Konzernmutter.
• Google LLC / Google Ireland Ltd. — ausschließlich als API-Anbieter (Google Calendar, OAuth), wenn ein Nutzer aktiv eine Kalenderverbindung herstellt. Es findet kein Tracking, keine Analyse-Integration und keine Übermittlung zu Werbezwecken statt. Details siehe Abschnitt 10.
• Resend — transaktionaler E-Mail-Versand (Booking-Bestätigungen, Einladungen, System-Mails). Verbindungen ausschließlich über TLS; SPF/DKIM/DMARC für Versanddomain konfiguriert.

Wir speichern personenbezogene Daten nur so lange, wie es für die jeweiligen Zwecke erforderlich ist oder wir gesetzlich dazu verpflichtet sind:

• Account-Daten: für die Dauer der Vertragsbeziehung
• Buchungs- und Rechnungsdaten: 10 Jahre (handels- und steuerrechtliche Aufbewahrungspflichten)
• Server-Logs: max. 30 Tage (technische Notwendigkeit / Sicherheit)
• Cookie-Einwilligung: 12 Monate; danach erneute Abfrage
• Google-OAuth-Tokens und externer Kalender-Snapshot: bis zum Disconnect durch den Nutzer; bei Disconnect sofortige Revocation und Löschung
• Daten gelöschter Accounts (sofern nicht aufbewahrungspflichtig): innerhalb von 30 Tagen vollständig entfernt

Dir stehen nach DSGVO folgende Rechte zu:

• Auskunft über deine gespeicherten Daten (Art. 15)
• Berichtigung unrichtiger Daten (Art. 16)
• Löschung deiner Daten (Art. 17)
• Einschränkung der Verarbeitung (Art. 18)
• Datenübertragbarkeit (Art. 20)
• Widerspruch gegen die Verarbeitung auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO (Art. 21)
• Widerruf erteilter Einwilligungen mit Wirkung für die Zukunft (Art. 7 Abs. 3)

Zur Ausübung dieser Rechte genügt eine formlose E-Mail an info@nios.digital.

Du hast das Recht, dich bei einer Datenschutz-Aufsichtsbehörde zu beschweren. Für uns zuständig ist:

Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit
Ludwig-Erhard-Str. 22, 7. OG
20459 Hamburg, Deutschland
Telefon: +49 40 428 54-4040
E-Mail: mailbox@datenschutz.hamburg.de
Web: https://datenschutz-hamburg.de

Wir kategorisieren Cookies und vergleichbare Speichertechnologien wie folgt:

• Notwendig: Auth-Sitzung, CSRF-Schutz, Theme-Präferenz, Spracheinstellung, Consent-Cookie selbst. Diese werden ohne Einwilligung gesetzt (§ 25 Abs. 2 Nr. 2 TTDSG).
• Statistik: Anonymisierte Reichweitenmessung. Wird ausschließlich nach Einwilligung geladen.
• Marketing: Werbe- und Conversion-Tracking. Ausschließlich nach Einwilligung.
• Externe Inhalte: Eingebettete Inhalte Dritter (z. B. YouTube, Karten). 2-Klick-Lösung — Inhalte werden erst nach deiner Zustimmung vom Drittanbieter geladen.

Du kannst deine Einwilligung jederzeit mit Wirkung für die Zukunft ändern oder widerrufen: Cookie-Einstellungen öffnen.

Für Nutzer der Booking-App (booking.vamiro.io) verarbeiten wir zusätzliche Daten zur Bereitstellung der Booking-Funktionen:

• DJ-Profil & Promotion: Künstlername, Bio, Genres, Promo-Materialien, Profilbild — sichtbar für verbundene Promoter. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.
• Google Calendar-Sync — Datenschutz und Sicherheit: Wenn du als DJ deinen Google Calendar verbindest, fragt Vamiro Booking über OAuth 2.0 die folgenden Scopes ab. Sämtliche technische Schutzmaßnahmen aus Abschnitt 4 (TLS 1.2+ in Transit, AES-256-GCM at Rest, RLS, kein Logging von Token-Inhalten oder Termin-Inhalten) gelten für diese Verbindung unverändert.
  • userinfo.email — einmaliger Abruf deiner Google-E-Mail-Adresse, ausschließlich um die verbundene Identität in den Vamiro-Einstellungen anzuzeigen und Doppelverbindungen desselben Accounts zu verhindern.
  • calendar.readonly — Lesezugriff auf deine Kalender-Liste (zur Auswahl der für die Verfügbarkeit berücksichtigten Kalender) sowie Datum/Uhrzeit/busy-free-Status deiner Termine. Wir lesen keine Termin-Titel, Beschreibungen oder Teilnehmer — nur die zeitliche Belegung, um Doppelbuchungen zu verhindern.
  • calendar.events — Schreibzugriff für genau einen Zweck: Vamiro erstellt, aktualisiert oder löscht ausschließlich diejenigen Kalender-Einträge, die durch bestätigte Vamiro-Bookings entstanden sind. Andere Termine werden weder gelesen, verändert noch gelöscht.

  Speicherung und Schlüsselmanagement: OAuth-Access- und -Refresh-Tokens werden vor der Persistierung mit AES-256-GCM verschlüsselt — jede Verschlüsselung mit einem frischen, zufälligen 96-Bit-Nonce und einem GCM-Authentication-Tag zum Integritätsschutz. Der 256-Bit-Master-Key liegt ausschließlich als Umgebungsvariable in unserer Server-Runtime (nicht im Client-Bundle, nicht im Quellcode, nicht in Backups als Klartext). Tokens werden zur Laufzeit nur innerhalb der jeweiligen Server-Route entschlüsselt; sie erscheinen weder in Application- noch in HTTP-Access-Logs.

  Datenminimierung: Wir speichern dauerhaft ausschließlich verschlüsselte Tokens, deine ausgewählten Kalender-IDs und einen minimalen Cache der verfügbaren Kalender-Liste. Kalender-Termine selbst (start/end + busy/free, keine Titel, Beschreibungen oder Teilnehmer) werden ausschließlich zur Verfügbarkeitsprüfung in einer Snapshot- Tabelle vorgehalten und beim Disconnect vollständig gelöscht.

  Google API Services — Limited Use Disclosure

  Vamiros Verwendung und Übertragung von Informationen, die über Google APIs an die Anwendung übermittelt werden, hält sich an die Google API Services User Data Policy, einschließlich der Limited-Use-Anforderungen.

  Konkret bedeutet das:

  • Google-Nutzerdaten werden ausschließlich zur Bereitstellung und Verbesserung der user-facing Booking- und Verfügbarkeitsfunktion verwendet.
  • Daten werden nicht für Werbung verwendet oder an Werbenetzwerke übertragen.
  • Daten werden nicht zum Training von generalisierten KI-/ML-Modellen verwendet.
  • Daten werden nicht an Dritte verkauft.
  • Daten werden Menschen nicht zur Einsichtnahme zugänglich gemacht, mit Ausnahme von: (a) ausdrücklicher Einwilligung des Nutzers, (b) Erfordernis zur Wahrung der Sicherheit (z. B. Missbrauchsuntersuchung), (c) gesetzlichen Verpflichtungen oder (d) anonymisierter Aggregat-Auswertung im Rahmen der Plattform.

  Widerruf jederzeit möglich:

  • In Vamiro: Einstellungen → Calendar Sync → „Verbindung trennen“. Vamiro ruft daraufhin den Google-Revoke-Endpoint auf, alle Tokens werden ungültig und Webhook-Channels gestoppt.
  • Bei Google direkt: myaccount.google.com/permissions → „Vamiro Booking“ → Zugriff entfernen.

  Bereits in deinen Kalender geschriebene Vamiro-Booking-Events bleiben dir erhalten — wir löschen sie beim Disconnect nicht automatisch. Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO (Einwilligung im OAuth-Consent) und Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung der Booking-Plattform).

• Apple/iCloud Calendar-Sync: Apple bietet keine OAuth-Schnittstelle, daher verbinden DJs ihren iCloud-Kalender mit einem App-spezifischen Passwort über CalDAV. Dieses Passwort wird vor dem Schreiben in die Datenbank ebenfalls mit AES-256-GCM verschlüsselt — identische Schlüssel- und Token-Hygiene wie bei Google (Abschnitt 4.2). Lese-/Schreibverhalten, Datenminimierung und Widerrufs-Möglichkeiten entsprechen dem Google-Sync (siehe oben). Trennung in den Vamiro-Einstellungen löscht das gespeicherte Passwort serverseitig; zusätzlich kannst du das App-Passwort jederzeit unter appleid.apple.com widerrufen.
• Datenlöschung auf Anfrage: Du kannst jederzeit die vollständige Löschung deiner Google-User-Daten und deines gesamten Vamiro-Accounts verlangen. Wege:
  • Selbst-Disconnect: in Vamiro unter Einstellungen → Calendar Sync → Verbindung trennen — löst automatisch Google-Token-Revocation, Channel-Stop und Snapshot-Löschung aus.
  • Account-Löschung per E-Mail: formlose Anfrage an info@nios.digital. Wir bestätigen den Eingang innerhalb von 72 Stunden und schließen die Löschung der nicht-aufbewahrungspflichtigen Daten innerhalb von 30 Tagen ab.
• Booking-Historie & Audit-Log: Status-Verläufe (Anfrage → Bestätigung → Stornierung) speichern wir zur Vertragsdokumentation und Streitbeilegung.
• Pool-Einladungen per E-Mail: E-Mail-Adressen eingeladener DJs werden ausschließlich zum Versand der Einladung verarbeitet und nach deren Annahme/Ablehnung gemäß Speicherdauer verarbeitet.

Wir passen diese Erklärung an, wenn sich Funktionen oder Auftragsverarbeiter ändern. Die jeweils aktuelle Version findest du stets auf dieser Seite; das Datum der letzten Aktualisierung steht oben.