DSGVO für SaaS: die Punkte, die vor dem ersten Enterprise-Kunden stehen müssen
Für: SaaS-Anbieter im DACH-Raum
Aktualisiert: 2026-09
Für ein SaaS-Produkt sind sechs Bereiche unverzichtbar: Rechtsgrundlagen je Verarbeitung, ein gepflegtes Verarbeitungsverzeichnis, technisch umgesetzte Betroffenenrechte, ein funktionierendes Löschkonzept, saubere Subunternehmerketten und eine belegbare Aussage zur Datenresidenz.
Datenschutz wird in SaaS-Produkten meist zu spät ernst genommen — typischerweise dann, wenn der erste grössere Kunde einen Fragebogen schickt. Zu diesem Zeitpunkt sind die teuren Entscheidungen längst gefallen: Datenmodell, Hosting-Region, Subunternehmer.
Diese Checkliste beschreibt die Punkte, die vor diesem Moment stehen sollten. Sie ist auf Produkte im DACH-Raum zugeschnitten und berücksichtigt, dass Schweizer Anbieter regelmässig sowohl das revidierte Datenschutzgesetz als auch die DSGVO bedienen müssen.
Die Checkliste
- 01
Verarbeitungen und Rechtsgrundlagen zuordnen
Jede Verarbeitung im Produkt einzeln benennen und ihr eine Rechtsgrundlage zuordnen. Besonders relevant für Analytik, Produkt-Telemetrie und alles, was über die reine Vertragserfüllung hinausgeht.
Erledigt, wenn: Keine Verarbeitung im Produkt ist ohne benannte Rechtsgrundlage, und Einwilligungen sind technisch widerrufbar umgesetzt.
- 02
Verarbeitungsverzeichnis an die Entwicklung koppeln
Das Verzeichnis so führen, dass neue Datenfelder und neue Drittdienste dort ankommen. Ein Verzeichnis, das von der Entwicklung entkoppelt ist, bildet nach zwei Releases nicht mehr das Produkt ab.
Erledigt, wenn: Das Verzeichnis wurde beim letzten Release aktualisiert, und der Auslöser dafür ist Teil des Entwicklungsprozesses.
- 03
Betroffenenrechte technisch umsetzen
Auskunft, Berichtigung, Löschung und Datenübertragbarkeit brauchen einen Weg im System. Solange das Handarbeit in der Datenbank bedeutet, ist die Frist bei mehreren gleichzeitigen Anfragen nicht haltbar.
Erledigt, wenn: Für jedes Recht existiert ein definierter Ablauf, und ein Auskunftsersuchen wurde einmal vollständig durchgespielt.
- 04
Löschkonzept über alle Speicherorte prüfen
Löschung muss auch Backups, Logdateien, Suchindizes und Analysewerkzeuge erfassen. Der Datensatz in der Hauptdatenbank ist meist der einzige, an den gedacht wird.
Erledigt, wenn: Es liegt eine Liste aller Orte vor, an denen personenbezogene Daten liegen, samt Löschfrist je Ort.
- 05
Subunternehmer vollständig erfassen
Jeder Dienst, der Kundendaten verarbeitet, ist ein Unterauftragsverarbeiter — auch Monitoring, Fehler-Tracking, E-Mail-Versand und KI-Schnittstellen. Diese Liste gehört öffentlich einsehbar.
Erledigt, wenn: Die Liste ist vollständig, jeder Eintrag hat einen Vertrag, und Kunden können sie ohne Anfrage abrufen.
- 06
Datenresidenz belegbar machen
Nicht nur wissen, wo die Hauptdatenbank liegt, sondern auch, wo Backups, Logs und Support-Werkzeuge liegen. Bei Anfragen aus regulierten Branchen wird genau danach gefragt.
Erledigt, wenn: Zu jedem Speicherort lässt sich die Region ohne Rückfrage beim Anbieter benennen.
- 07
Mandantentrennung prüfen
Bei mandantenfähigen Systemen ist die Trennung der Kundendaten der kritischste Punkt überhaupt. Ein Fehler hier ist gleichzeitig eine Datenschutzverletzung und ein Vertrauensverlust, von dem sich ein Produkt selten erholt.
Erledigt, wenn: Die Trennung ist auf Datenbankebene erzwungen und durch einen Test abgedeckt, der bei jedem Release läuft.
Häufige Fehler
- —Die Datenschutzerklärung beschreibt ein Produkt, das es so nicht mehr gibt. Sie wird beim Start geschrieben und danach nie an Produktänderungen angepasst.
- —Die Löschung erfasst die Hauptdatenbank, aber nicht Backups, Logs und Analysewerkzeuge. Damit ist sie unvollständig.
- —Neue Drittdienste werden im Entwicklungsalltag eingebunden, ohne dass jemand die Subunternehmerliste ergänzt.
- —Die Mandantentrennung beruht auf Anwendungslogik statt auf einer Durchsetzung in der Datenbank. Ein einzelner vergessener Filter genügt dann für einen Vorfall.
Was diese Checkliste nicht abdeckt
- —Diese Checkliste ersetzt keine datenschutzrechtliche Prüfung Ihres konkreten Produkts, besonders nicht bei besonderen Kategorien personenbezogener Daten.
- —Datenschutz-Folgenabschätzungen sind ein eigenständiges Verfahren und werden hier nicht abgedeckt.
- —Internationale Datentransfers sind nur so weit berührt, wie sie die Frage der Datenresidenz betreffen. Die vertragliche Absicherung von Drittlandtransfers ist ein eigenes Thema.
- —Sektorspezifisches Recht — Gesundheitswesen, Finanzsektor, öffentliche Beschaffung — kommt zusätzlich hinzu.
Übergeordnete Leistung: SaaS-Produktentwicklung
Passende Angebote
DSGVO- & revDSG-Audit für SaaS
Ein Datenschutz-Audit für SaaS prüft, ob Datenflüsse, Auftragsverarbeitung, Löschkonzept und technische Massnahmen DSGVO- und revDSG-konform sind. Ergebnis ist ein konkreter Befund mit priorisierten Korrekturen — aus Sicht von Leuten, die selbst SaaS betreiben.
SaaS Security & RLS Audit
Ein SaaS-Security-Audit prüft gezielt die Mandantentrennung: Ist Row-Level-Security wasserdicht, greift die Zugriffskontrolle, sind typische Supabase-Fallen (Service-Role im Client, fehlende RLS) vermieden? Ergebnis ist ein Befund mit konkreten Fixes.
Häufige Fragen
Reicht Hosting in der EU für DSGVO-Konformität?
Nein. Der Serverstandort ist ein Baustein, aber Rechtsgrundlagen, Betroffenenrechte, Löschkonzept und Subunternehmerketten sind davon unabhängig zu erfüllen.
Was gilt zusätzlich für Schweizer Anbieter?
Das revidierte Datenschutzgesetz gilt parallel. Die Anforderungen überschneiden sich weitgehend, weichen aber in Details ab — etwa bei der Meldung von Verletzungen und beim Verzeichnis.
Wann sollte man damit anfangen?
Vor der Festlegung von Datenmodell und Hosting-Region. Diese beiden Entscheidungen sind später am teuersten zu korrigieren.
Brauchen wir einen Datenschutzbeauftragten?
Das hängt von Art und Umfang der Verarbeitung ab, nicht allein von der Unternehmensgrösse. Bei umfangreicher systematischer Überwachung oder besonderen Datenkategorien ist die Frage ernsthaft zu prüfen.
Weitere Checklisten
Auftragsverarbeitungsvertrag prüfen: worauf es beim Gegenlesen ankommt
Beim Gegenlesen eines Auftragsverarbeitungsvertrags entscheiden sechs Punkte: Gegenstand und Weisungsbindung, die Subunternehmerkette samt Widerspruchsrecht, Ort der Verarbeitung, Mitwirkung bei Betroffenenrechten, Meldewege bei Verletzungen und der Umgang mit Daten nach Vertragsende.
Technische Due Diligence: was in wenigen Tagen prüfbar ist
Eine technische Due Diligence in knapper Zeit konzentriert sich auf sechs Fragen: Trägt die Architektur den geplanten Wachstumspfad, wie gross ist die technische Schuld, hängt das System an einzelnen Personen, wie steht es um Sicherheit und Lizenzen, und lässt sich der Betrieb übergeben.
Technical-SEO-Prüfung: die Punkte, die Indexierung tatsächlich verhindern
Die meisten technischen SEO-Probleme lassen sich auf wenige Ursachen zurückführen: Seiten sind nicht indexierbar, Canonicals zeigen falsch, die Sitemap enthält Seiten, die nicht indexiert werden sollen, hreflang ist nicht reziprok, oder Seiten sind intern kaum verlinkt.