3.1 Identität und Authentifizierung (Clerk)

Provider: Clerk Inc. (USA), Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO
Daten: E-Mail, Name (optional), Profilbild (optional), technische Login- und Sitzungsdaten sowie gegebenenfalls OAuth-Provider
Zweck: Login, Passwort-Reset, Session-Management
Clerk ist der Identitätsanbieter. Die Anwendung synchronisiert daraus nur die für den Anwendungsbetrieb erforderliche lokale Benutzerprojektion, insbesondere die Clerk-ID, Profilstammdaten und die anwendungsinterne Rolle. Finanz- und Immobiliendaten werden nicht durch diesen Rollenabgleich an Clerk übertragen.
Drittlandtransfer: EU-Standardvertragsklauseln + EU-US DPF
Clerk Datenschutz

3.2 Finanzdaten

Immobiliendaten: Kaufpreis, Adresse, Wohnfläche, Baujahr
Finanzdaten: Eigenkapital, Einkommen, Mieteinnahmen
Berechnungen: Cashflow, Rendite, AfA, Amortisation
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung)

3.3 Rollen-System (RBAC)

Anwendungsrollen: BASE (technischer Minimalzugriff), USER, FRIEND, SALE, LEAD, BARON, HEAD und ADMIN
Gespeichert in: Anwendungsdatenbank (Single Source of Truth für Rollen)
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Systemsicherheit)

3.4 Technische Daten

IP-Adresse (temporär, max. 60s für Security-Store-basiertes Rate Limiting)
Webhook-Event-IDs (z. B. Svix-ID, temporär für Replay-Schutz)
Browser-Typ, OS, Zugriffszeitpunkte, Referrer-URL

3.5 Szenario- und Share-Daten

Gespeicherte Szenarien können Immobilien-, Finanz- und gegebenenfalls Steuerdaten enthalten. Wenn du einen Share-Link erzeugst, wird ein zeitlich begrenzter technischer Bearer-Link erstellt. Der JWT enthält nur technische Claims wie Szenario-ID, Ausstellungs-/Ablaufzeit, Issuer, Audience und eine eindeutige Token-ID sowie gegebenenfalls ein technisches Rollenmerkmal; die Finanzwerte stehen nicht im Token.
Beim Öffnen des Links wird das zugehörige Szenario aktuell aus der Anwendungsdatenbank geladen und die Darstellung serverseitig neu berechnet. Der Share ist daher derzeit kein unveränderlicher Daten-Snapshot. Wer den Link besitzt, kann die dabei freigegebenen Werte bis zum Ablauf des Links einsehen. Teile Share-Links nur mit den vorgesehenen Empfängern.

4.1 Hosting (Vercel)

Auslieferung über ein weltweites CDN. Laut aktueller Vercel-Projektkonfiguration (Stand: 19. Juli 2026) ist die Region für serverseitige Funktionen Frankfurt, Deutschland (fra1).
DPA/AVV: Die veröffentlichte Vercel-DPA und ihre Anwendbarkeit auf den gewählten Plan werden im internen Nachweisregister geprüft.
Vercel Privacy

4.2 PostgreSQL-Datenbank

Die Anwendung verwendet eine PostgreSQL-Datenbank. Anbieter, Region und Auftragsverarbeitungsvertrag richten sich nach der aktuell eingesetzten Produktionskonfiguration und müssen mit dem jeweiligen Datenbankanbieter abgeglichen werden.

4.3 Storage (Cloudflare R2)

Zweck: Immobilien- und Website-Medien
R2-Bucket-Jurisdiktion: Europäische Union (EU) laut aktueller Betreiberkonfiguration
DPA/AVV: Cloudflare veröffentlicht eine DPA; Vertragsstatus und Annahme werden im internen Nachweisregister dokumentiert.
Cloudflare Privacy

4.4 Security Store (Upstash Redis)

Deployment: AWS eu-central-1 (Frankfurt, Deutschland) laut aktueller Betreiberkonfiguration; der Dienst ist global erreichbar
Daten: IP-Adressen (temporär, max. 60s Sliding Window) + Webhook-Event-IDs
Zweck: DDoS-Schutz, Brute-Force-Prävention, Replay-Schutz für Webhooks
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (IT-Sicherheit)
Upstash DPA

4.5 Google Places API

Zweck: Abruf und Darstellung des Google-Unternehmensprofils, der Gesamtbewertung, Bewertungsanzahl, zugehöriger Links und ausgewählter Rezensionen
Daten: technische Place-ID sowie von Google bereitgestellte Bewertungsdaten, insbesondere Rezensionstext, Bewertung, Veröffentlichungszeit, Autorenname und Autorenbild. Der Abruf erfolgt serverseitig; Adresseingaben der Plattformnutzer werden hierfür nicht an Google übertragen.
Google Privacy

4.6 E-Mail-Versand (Resend)

Für Kontaktformular und transaktionale E-Mail-Zustellung
Daten: Name, E-Mail, Telefon, Nachricht
Der Passwort-Reset und die Identitätsfunktionen erfolgen über Clerk (siehe 3.1).

4.7 TanStack Query (Client-Side Cache)

Speicherort: Lokaler Browser (kein Upload)
Dauer: Standardmäßig fünf Minuten bis zur Veraltung und zehn Minuten bis zur Entfernung ungenutzter Cache-Einträge; einzelne Abfragen können abweichend konfiguriert sein
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (Performance)

4.8 Fehler- und Performance-Telemetrie (Sentry)

Zweck: technische Fehleranalyse, Stabilität und Performance der Anwendung
Übermittelt werden können technische Request- und Laufzeitinformationen sowie von der Anwendung gemeldete Fehlerdaten. Die automatische Übermittlung von Nutzer-PII ist deaktiviert; zusätzliche Filter reduzieren ausgewählte sensible Request-Felder. Je nach Fehlerkontext können dennoch technische Metadaten wie Route, Browser-, Netzwerk- oder Konsoleninformationen enthalten sein. Session Replay ist derzeit vollständig deaktiviert.
Rechtsgrundlage und Aufbewahrungsdauer richten sich nach der konkreten Sentry- Konfiguration, der Interessenabwägung und den vertraglichen Vereinbarungen.

4.9 Web Analytics und Speed Insights (Vercel)

Aktiv nur nach deiner Auswahl der Kategorie „Analyse und Performance“ und nur auf öffentlichen Marketingseiten.
Zweck: aggregierte Besucher-/Referrer-Auswertung sowie Messung realer technischer Performance und Core Web Vitals nach Route, Gerät und Region.
Daten: Zeitstempel, aufgerufener Pfad, Referrer, ungefähre Region, Gerät, Betriebssystem, Browser und Performance-Messwerte. Es werden keine Admin-, Finanz-, Rechts- oder tokenisierten Share-Seiten erfasst.
Vercel beschreibt Web Analytics als anonymisierte, aggregierte Messung ohne Drittanbieter-Cookies und ohne anwendungsübergreifende Nutzeridentifikatoren. Die konkrete Verarbeitung, Rechtsgrundlage und Aufbewahrung werden anhand der aktiven Vercel-Konfiguration und der Interessen-/Einwilligungsprüfung festgelegt.
Vercel Web Analytics: Privacy und Compliance · Vercel Speed Insights