Warum die meisten No-Code-Apps DSGVO-Probleme haben

Die häufigsten DSGVO-Probleme bei No-Code-Apps:

1. **Datenspeicherung außerhalb der EU**: Bubble und viele andere Tools speichern standardmäßig in US-Rechenzentren. Post-Schrems-II erfordert das komplexe Verträge.

2. **Fehlende Datenzugriffskontrolle**: Ohne Row-Level-Security kann jeder authentifizierte Nutzer alle Daten aller anderen Nutzer sehen — ein kritischer Datenschutzverstoß.

3. **Kein Verarbeitungsverzeichnis**: Viele Startups wissen nicht, welche personenbezogenen Daten sie verarbeiten und bei welchen Subunternehmern diese landen.

4. **Fehlende AVVs**: Wenn du Subunternehmer nutzt (Supabase, OpenAI, Stripe, Analytics), brauchst du mit jedem einen Auftragsverarbeitungsvertrag.

Die gute Nachricht: mit der richtigen Architektur — WeWeb + Supabase EU-Region — lassen sich die meisten dieser Probleme von Anfang an verhindern, ohne komplexe nachträgliche Maßnahmen.

Row-Level-Security: Das Fundament der Datenisolation

Row-Level-Security (RLS) ist der wichtigste technische Sicherheitsmechanismus in Supabase. Es sind SQL-Policies, die bei jeder Datenbankabfrage ausgeführt werden und sicherstellen, dass jeder Nutzer nur die Zeilen sehen und bearbeiten kann, für die er berechtigt ist.

RLS auf einer Tabelle aktivieren: ```sql ALTER TABLE projects ENABLE ROW LEVEL SECURITY; ```

Einfache Policy — jeder Nutzer sieht nur seine eigenen Projekte: ```sql CREATE POLICY "user_own_projects" ON projects FOR ALL USING (user_id = auth.uid()); ```

Multi-Tenant-Policy — Organisationsmitglieder sehen Organisationsprojekte: ```sql CREATE POLICY "org_member_projects" ON projects FOR SELECT USING ( org_id IN ( SELECT org_id FROM memberships WHERE user_id = auth.uid() ) ); ```

Goldene Regel: Aktiviere RLS auf ALLEN Tabellen von Anfang an. Das ist nicht verhandelbar für DSGVO-Konformität.

DSGVO-Pflicht-Checkliste für No-Code-Apps

**Technische Anforderungen**: - [ ] Supabase EU-Region ausgewählt (Frankfurt oder Irland) - [ ] RLS auf allen nutzerorientierten Tabellen aktiviert - [ ] Kein personenbezogener Datenzugriff ohne Authentifizierung - [ ] API-Keys in Umgebungsvariablen, nicht im Frontend-Code - [ ] HTTPS für alle Verbindungen (Supabase und WeWeb erzwingen das automatisch)

**Rechtliche Anforderungen**: - [ ] Datenschutzrichtlinie auf Deutsch (was, warum, wie lange, wer) - [ ] Verarbeitungsverzeichnis dokumentiert (intern) - [ ] AVV mit Supabase abgeschlossen - [ ] AVV mit OpenAI abgeschlossen (wenn KI genutzt) - [ ] AVV mit Analytics-Tool (PostHog, Mixpanel, etc.) - [ ] AVV mit E-Mail-Provider (SendGrid, Brevo, etc.)

**Nutzer-Rechte implementiert**: - [ ] Auskunftsrecht: Nutzer kann alle ihre Daten exportieren - [ ] Löschungsrecht: Nutzer kann ihr Konto und alle Daten löschen - [ ] Berichtigungsrecht: Nutzer kann ihre Daten bearbeiten - [ ] Widerspruchsrecht: Opt-Out für nicht-essentielle Datenverarbeitung

Audit-Logs implementieren

Für B2B-SaaS, das sensible Daten verarbeitet (Finanz, HR, Legal), sind Audit-Logs oft vertraglich oder regulatorisch vorgeschrieben. Sie dokumentieren: wer hat wann welche Daten eingesehen oder geändert.

Einfache Audit-Log-Tabelle in Supabase: ```sql CREATE TABLE audit_logs ( id bigserial PRIMARY KEY, user_id uuid REFERENCES auth.users, action text NOT NULL, -- 'read', 'create', 'update', 'delete' resource_type text NOT NULL, -- z.B. 'customer', 'invoice' resource_id text, details jsonb, created_at timestamptz DEFAULT now() ); ```

Fülle den Audit-Log über Supabase Database Triggers (automatisch bei INSERT/UPDATE/DELETE) oder in deinen Xano/Edge Function-Endpunkten (manuell, mehr Kontrolle).

Für DSGVO-Artikel 5 (Rechenschaftspflicht): der Audit-Log belegt, dass nur autorisierte Zugriffe stattgefunden haben. Das ist ein zentrales Dokument bei Datenschutzaudits durch deutsche DSBs oder bei Behördenanfragen nach einem Datenschutzvorfall.

Verschlüsselung und Datenschutz im Detail

Supabase verschlüsselt Daten in der Übertragung (TLS) und im Ruhezustand (AES-256) automatisch. Für die meisten No-Code-Apps ist das ausreichend.

Für besonders schützenswerte Daten (DSGVO-Artikel-9-Daten: Gesundheit, biometrische Daten, religiöse Überzeugungen, politische Meinungen):

**Anwendungsebenen-Verschlüsselung**: Verschlüssele sensible Felder vor der Speicherung in Supabase mit einer Anwendungsschlüssel (gespeichert als Supabase-Geheimnis). Das bedeutet, dass selbst Supabase-Mitarbeiter diese Felder nicht im Klartext sehen können.

**Pseudonymisierung**: Ersetze direkte Identifikatoren (Name, E-Mail) durch indirekte Identifikatoren (UUID) in den Datentabellen. Speichere die Zuordnungstabelle getrennt mit strengeren Zugriffskontrollen.

Für den deutschen Mittelstand, der mit Behörden oder im Gesundheitssektor arbeitet: erwäge zertifizierte Cloud-Lösungen nach BSI C5 oder ISO 27001. Supabase selbst hat SOC2 Type II Zertifizierung — überprüfe, ob das für deine Compliance-Anforderungen ausreicht.

Datenpannen und Meldepflichten

Die DSGVO verlangt, dass Datenpannen der zuständigen Aufsichtsbehörde innerhalb von 72 Stunden gemeldet werden. Für deutsche Unternehmen: die Landesdatenschutzbehörde des jeweiligen Bundeslandes (z.B. Berliner Beauftragte für Datenschutz für Berliner Unternehmen).

Vorbeugung in deiner No-Code-Architektur:

**Überwachung**: Nutze Supabase Logs und Alerts, um ungewöhnliche Datenzugriffspatterns zu erkennen (z.B. ein Nutzer, der 10.000 Zeilen in 5 Minuten abfragt). Richte Alerting-Webhooks ein.

**Incident-Response-Plan**: Dokumentiere vor dem ersten Nutzer, wie du bei einer potenziellen Datenpanne vorgehen würdest: wer wird benachrichtigt, wie wird der Zugriff gesperrt, was wird der Aufsichtsbehörde gemeldet.

**Regelmäßige Backups**: Supabase Pro beinhaltet tägliche automatische Backups. Aktiviere das — ein Backup ist sowohl für Recovery als auch für DSGVO-Compliance relevant (du kannst nachweisen, wann welche Daten vorhanden waren).