SaaS datenschutzkonform betreiben: DSG und DSGVO für kleine Produkte
Datenschutz wirkt bei einem kleinen SaaS schnell wie ein Berg aus Paragraphen, dabei kochen DSG und DSGVO am Ende auf eine Handvoll praktischer Entscheidungen herunter. Welche Daten du erhebst, wo sie liegen, wer sie in deinem Auftrag verarbeitet, und wie schnell du eine Auskunft oder Löschung umsetzen kannst. Dieser Artikel führt dich durch diese Punkte, vom Datenverzeichnis bis zum Löschkonzept, mit Beispielen aus dem Betrieb eigener Produkte. Kein Rechtsrat, sondern eine Landkarte, damit du weisst, welche Fragen dein Anwalt am Ende noch beantworten muss.
SaaS datenschutzkonform betreiben heisst: wissen, welche Daten du hast
Der erste Schritt ist langweilig und genau deshalb wird er gern übersprungen. Du musst wissen, welche Personendaten dein Produkt überhaupt anfasst. Nicht ungefähr, sondern konkret. Bei einem kleinen SaaS sind das meist drei Gruppen: die Kontaktdaten der Nutzer (Name, E-Mail, vielleicht Telefonnummer), die Inhalte, die sie selbst eingeben, und die technischen Spuren, die im Betrieb anfallen (IP-Adressen in Logs, Session-Tokens, Fehlermeldungen).
Das revidierte Schweizer Datenschutzgesetz, kurz revDSG, gilt seit September 2023 und verlangt von Unternehmen ein Verzeichnis der Bearbeitungstätigkeiten. Die europäische DSGVO kennt dasselbe unter Artikel 30. Für ein winziges Produkt klingt das nach Bürokratie, in der Praxis ist es eine Tabelle: Welche Daten, zu welchem Zweck, wie lange aufbewahrt, an wen weitergegeben. Wer das einmal sauber aufschreibt, hat die Hälfte aller späteren Datenschutzfragen schon im Griff, weil fast jede Anfrage auf dieses Verzeichnis zurückführt.
Ein Beispiel aus dem Alltag. Du baust ein Tool, mit dem Handwerksbetriebe ihre Offerten verwalten. Auf den ersten Blick verarbeitest du nur Geschäftsdaten. Schaust du genauer hin, stehen in den Offerten Namen und Adressen von Privatkunden, und damit bist du mitten im Personendatenschutz, ohne es geplant zu haben. Genau solche Stellen findest du nur, wenn du dein eigenes Produkt einmal von der Datenseite her durchgehst.
DSG oder DSGVO: welches Gesetz für dein Produkt gilt
Viele Gründer fragen zuerst, ob für sie das Schweizer oder das europäische Recht zählt. Die unbequeme Antwort: oft beide. Das revDSG greift, wenn deine Bearbeitung sich in der Schweiz auswirkt. Die DSGVO greift zusätzlich, sobald du Personen in der EU Waren oder Dienste anbietest oder ihr Verhalten beobachtest. Sitzt ein einziger zahlender Kunde in Deutschland, fällst du in der Regel unter beide Regelwerke.
Das ist weniger schlimm, als es klingt. Die beiden Gesetze sind bewusst aneinander angeglichen, weil die Schweiz den freien Datenfluss mit der EU erhalten will. Wenn du sauber nach DSGVO arbeitest, erfüllst du das revDSG fast vollständig mit. Die Unterschiede sind im Detail (das revDSG kennt zum Beispiel keine generelle Pflicht zur Folgenabschätzung in gleicher Breite, und die Bussgelder treffen in der Schweiz natürliche Personen statt das Unternehmen), aber für den Aufbau deines Produkts ist die Faustregel klar: Bau für den strengeren der beiden Standards, dann musst du nicht zweimal nachdenken.
Wer ausschliesslich Schweizer Firmenkunden bedient und technisch verhindern kann, dass EU-Bürger das Produkt nutzen, kommt mit dem revDSG allein aus. Diese saubere Trennung gelingt in der Praxis aber selten, sobald ein Produkt wächst. Plane lieber von Anfang an für beide.
Auftragsbearbeitung: jeder Dienst, der für dich Daten anfasst
Kein kleines SaaS läuft allein. Du nutzt einen Hoster, einen E-Mail-Versanddienst, vielleicht ein Fehler-Monitoring, einen Zahlungsanbieter. Jeder dieser Dienste, der in deinem Auftrag Personendaten verarbeitet, ist ein Auftragsbearbeiter. Und für jeden brauchst du einen Auftragsbearbeitungsvertrag, im DSGVO-Jargon AVV oder DPA genannt.
Das ist kein Papier, das du selbst aufsetzt. Die seriösen Anbieter stellen ihren AVV bereit, meist als PDF oder als Klausel in den AGB, die du mit der Anmeldung akzeptierst. Deine Aufgabe ist, sie einzusammeln und zu wissen, von wem du welchen hast. Praktisch heisst das: eine zweite Liste neben deinem Datenverzeichnis, in der jeder Subdienstleister mit seinem AVV-Status steht.
Wir betreiben mit Wortfreunde und Reazon selbst Produkte und kennen die Übung von innen. Beim Hochziehen eines Produkts sammeln sich solche Dienste schneller an, als man denkt. Ein neues Analytics-Tool hier, ein Transaktions-E-Mail-Service dort. Wer das nicht laufend pflegt, sitzt nach einem Jahr auf einem Dutzend Dienstleister, von denen er die Hälfte vergessen hat. Genau dieser Unterschied zwischen bauen und dauerhaft betreiben prägt, wie ein Produktstudio an Compliance herangeht: nicht als einmaliges Audit, sondern als Teil des laufenden Produkt-Betriebs.
Ein Punkt, den viele unterschätzen: Auch Subdienstleister haben Subdienstleister. Dein E-Mail-Versender nutzt vielleicht selbst eine Cloud in den USA. Du musst diese Kette nicht im Detail kontrollieren, aber du solltest wissen, dass es sie gibt, denn sie führt direkt zur nächsten Frage.
Datenstandort: wo deine Server stehen und warum es zählt
Wo physisch deine Daten liegen, ist eine der wenigen Datenschutzfragen mit handfesten technischen Konsequenzen. Innerhalb der Schweiz oder des EWR ist die Sache einfach: Der Datentransfer braucht keine zusätzliche Rechtfertigung. Sobald Daten in ein Drittland fliessen, etwa in die USA, brauchst du eine Grundlage für diesen Transfer.
Für die USA gibt es seit 2023 das EU-US Data Privacy Framework, und die Schweiz hat ein eigenes Pendant. Ist dein US-Anbieter dort zertifiziert, ist der Transfer abgedeckt. Ist er es nicht, brauchst du Standardvertragsklauseln, die sogenannten SCC, plus oft eine zusätzliche Risikoeinschätzung. Das wird schnell aufwendig.
Der pragmatische Weg für ein kleines Produkt: Wähle Anbieter mit Rechenzentren in der Schweiz oder der EU, dann erübrigt sich die ganze Drittland-Diskussion. Viele grosse Cloud-Anbieter lassen dich die Region wählen. Frankfurt, Zürich, Amsterdam. Das kostet selten mehr und spart dir eine Menge Papierkrieg. Wo du auf einen US-Dienst angewiesen bist, etwa weil es kein gleichwertiges europäisches Pendant gibt, prüfst du gezielt die Zertifizierung.
Die Kostenfrage dahinter wird oft falsch gestellt. Datenschutzkonformer Betrieb ist kein eigener Posten, der separat aufschlägt, sondern eine Auswahlentscheidung bei den Diensten, die du ohnehin brauchst. Die Treiber sind die Anzahl der Subdienstleister und wie exotisch deine Anforderungen sind. Wer einen Standard-Stack mit EU-Hosting fährt, zahlt für Compliance praktisch nichts extra. Wer eine bunte Sammlung von US-Spezialtools verkabelt, zahlt in Beratungsstunden. Was der Betrieb sonst monatlich kostet, haben wir im Artikel zu SaaS-Betriebskosten aufgeschlüsselt.
Auskunft und Löschung: die Rechte, die jeder Nutzer hat
Jede Person, deren Daten du verarbeitest, hat zwei Rechte, die du technisch bedienen können musst. Das Auskunftsrecht: Auf Anfrage musst du mitteilen, welche Daten du über sie gespeichert hast. Und das Recht auf Löschung: Unter bestimmten Bedingungen musst du diese Daten entfernen.
In der Theorie klingt das simpel. In der Praxis scheitert es oft an der Architektur. Wenn die Daten einer Person über fünf Tabellen, drei Logfiles und zwei externe Dienste verstreut sind, wird eine Löschanfrage zur Detektivarbeit. Deshalb lohnt es sich, von Anfang an zu wissen, wo eine Nutzer-Identität überall auftaucht. Ein durchdachtes Datenmodell, bei dem alles an einer Nutzer-ID hängt, macht aus einer Löschung einen Knopfdruck statt einer halbtägigen Suche.
Ein Detail, das viele übersehen: Löschen heisst nicht nur die Hauptdatenbank. Es heisst auch Backups, Logs und die Kopien bei deinen Auftragsbearbeitern. Backups löscht man in der Regel nicht einzeln, hier reicht es, wenn sie nach der üblichen Rotationsfrist von selbst verschwinden und du das dokumentierst. Aber du musst es bedacht haben, sonst stehst du bei der ersten Anfrage ohne Antwort da.
Für ein kleines Produkt mit überschaubaren Nutzerzahlen darf die Bearbeitung anfangs manuell sein. Eine Anfrage pro Quartal lässt sich von Hand erledigen. Erst wenn das Volumen steigt oder das Produkt skaliert, lohnt sich ein automatisierter Export- und Lösch-Mechanismus. Diesen Zeitpunkt nicht zu früh anzusetzen, ist eine bewusste Entscheidung, kein Versäumnis.
Wann sich der Aufwand nicht lohnt und ein anderer Weg besser ist
Nicht jedes Datenschutzthema verdient denselben Aufwand, und es gibt Situationen, in denen du gar nicht erst selbst bauen solltest. Wenn dein Produkt besonders heikle Daten verarbeitet, also Gesundheitsdaten, biometrische Daten, Daten über religiöse oder politische Ansichten, steigt die Anforderung sprunghaft. Das revDSG nennt das besonders schützenswerte Personendaten, und hier reicht das Bordmittel-Wissen aus diesem Artikel nicht. Dann brauchst du juristische Begleitung, bevor du eine Zeile Code schreibst.
Es gibt auch den umgekehrten Fall. Wenn du nur eine simple Funktion brauchst, die du als geprüftes Standardprodukt kaufen kannst, ist der datenschutzkonforme Eigenbau selten den Aufwand wert. Ein fertiges Tool, das nachweislich konform betrieben wird, nimmt dir die ganze Auftragsbearbeitungs- und Datenstandort-Frage ab, weil der Anbieter sie für dich gelöst hat. Die Abwägung zwischen Kaufen und Bauen haben wir an anderer Stelle ausführlich behandelt, sie gilt für Datenschutz genauso wie für Funktionen.
Und der naheliegende Einwand, dass Datenschutz Innovation bremst? In der Praxis ist es eher umgekehrt. Wer die Datenflüsse seines Produkts sauber kennt, baut robustere Systeme, findet Fehler schneller und kann gegenüber Geschäftskunden belegen, dass er seine Hausaufgaben gemacht hat. Bei B2B-Produkten fragt der Einkauf des Kunden ohnehin nach deinem AVV und deinem Datenstandort. Wer da vorbereitet ist, gewinnt Deals, statt sie zu verlieren.
So machst du den Anfang, ohne dich zu verlieren
Fang mit dem Datenverzeichnis an, bevor du über Tools oder Verträge nachdenkst. Drei Spalten reichen für den Start: welche Daten, warum, wie lange. Daraus ergibt sich fast alles Weitere von selbst, weil du dann siehst, welche Dienste du brauchst und welche AVV du einsammeln musst.
Wähle danach deinen Stack mit Datenstandort im Hinterkopf. EU oder Schweiz als Default, US-Dienste nur mit geprüfter Grundlage. Und sorge dafür, dass dein Datenmodell eine Person an einer Stelle bündelt, damit Auskunft und Löschung später kein Drama werden. Das ist kein Compliance-Theater, sondern saubere Produktarbeit, die sich im Betrieb auszahlt.
Wenn du an dem Punkt stehst, an dem dein Produkt von der Idee in den verlässlichen Dauerbetrieb übergeht, ist das genau der Moment, diese Grundlagen festzuziehen. Wir bauen und betreiben eigene Produkte und nehmen Datenschutz dabei als Teil des Handwerks, nicht als lästige Pflicht am Schluss. Das hier ersetzt keinen Anwalt, aber es gibt dir die Landkarte, mit der das Gespräch mit dem Anwalt kurz und konkret wird.