Datenschutzrecht für SaaS-Builder: DSGVO, CCPA und mehr

Ein Kunde schreibt an Ihren Support: „Schicken Sie mir alle Daten, die Sie über mich haben, und löschen Sie mein Konto.“ Der Support-Mitarbeiter leitet die Mail an das Engineering weiter. Jetzt muss jemand die Daten dieser Person über Stripe (Zahlungen), Salesforce (CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen →), Segment (Event-Tracking) und ein Snowflake-Warehouse hinweg finden, das Ihre Analytics-Dashboards speist. Das ist ein Data Subject Access Request (DSAR), und nach DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen → haben Sie 30 Tage Zeit zu antworten. Die meisten Mid-Market-SaaS-Unternehmen stellen in genau diesem Moment fest, dass niemand wirklich weiß, wo überall personenbezogene Daten liegen.

Diese Lektion zeigt, warum das passiert und wie Sie es beheben, bevor die Anfrage eintrifft.

Die Regulierungslandschaft, kurz gefasst

DSGVO (Datenschutz-Grundverordnung) ist das EU-Datenschutzrecht, in Kraft seit 2018, durchgesetzt von nationalen Datenschutzbehörden (DPAs), lose koordiniert über den Europäischen Datenschutzausschuss. Sie gilt für jedes Unternehmen, das personenbezogene Daten von Personen in der EU verarbeitet, unabhängig vom Sitz des Unternehmens.

CCPA (California Consumer Privacy Act), geändert und erweitert durch den CPRA (California Privacy Rights Act, wirksam seit 2023), gibt Einwohnern Kaliforniens ähnliche Rechte. Durchgesetzt wird ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → von der California Privacy Protection Agency (CPPA). Andere US-Bundesstaaten (Virginia, Colorado, Connecticut, Utah und eine wachsende Liste Stand 2026) haben eigene, ähnliche, aber nicht identische Datenschutzgesetze verabschiedet.

Kernpunkt für Builder: Diese Gesetze sind nicht gleich, aber sie reimen sich. Beide geben Personen Rechte über ihre Daten. Beide verlangen, dass Sie wissen, was Sie haben und wo.

Die Rechte, die tatsächlich Engineering-Arbeit auslösen

• Auskunftsrecht: der Person eine Kopie ihrer Daten geben (DSGVO Art. 15, CCPA „right to know“).
• Recht auf Löschung: auf Anfrage löschen (DSGVO Art. 17 „Recht auf Vergessenwerden“, CCPA „right to delete“).
• Recht auf Berichtigung: unrichtige Daten korrigieren.
• Recht auf Datenübertragbarkeit: Daten in einem nutzbaren Format exportieren.
• Recht auf Widerspruch gegen Verkauf/Weitergabe (CCPA-spezifisch): relevant, wenn Sie Daten mit Ad-Networks oder Datenbrokern teilen.

Jedes davon ist ein technischer Workflow, nicht nur eine rechtliche Policy. Genau das unterschätzen nicht-technische Teams.

Wo es weh tut: die Multi-Tenant-Realität

Die meisten SaaS-Produkte sind multi-tenant: eine Codebasis und oft ein Datenbankschema bedient viele Kundenorganisationen, mit Zeilen, die über eine tenant_id oder account_id markiert sind. Für das Engineering ist das effizient, für die Datenschutzarbeit auf zwei Wegen kompliziert.

Erstens verteilen sich personenbezogene Daten über Systeme, die keine gemeinsame ID haben. Die E-Mail eines Nutzers ist vielleicht der Schlüssel in Salesforce, eine customer_id in Stripe, eine anonyme user_id in Segment, die erst später identifiziert wird, und ein gehashter Wert in Ihrem Warehouse für Analytics. „Was wissen wir über diese Person“ zu beantworten heißt, die Identität über alle vier hinweg aufzulösen.

Zweitens ist Löschen nicht einfach Löschen. Stripe bewahrt Transaktionsdaten aus steuer- und buchhaltungsrechtlichen Gründen auf (in den USA sind 7 Jahre eine verbreitete Aufbewahrungspraxis; in der EU verlangen nationale Steuergesetze oft ähnliche Fristen). Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen eine bezahlte Rechnung nicht löschen, nur weil jemand ein DSGVO-Löschbegehren stellt. Die DSGVO selbst regelt diesen Konflikt: Artikel 17(3) erlaubt Aufbewahrung, wo sie gesetzlich vorgeschrieben ist. „Alles löschen“ heißt also in Wahrheit: „löschen oder anonymisieren, was erlaubt ist, und dokumentieren, was nicht“.

Die Anfrage konkret durchgehen

1. Person identifizieren. Die E-Mail aus dem DSAR mit internen IDs abgleichen: Stripe (Customer-Objekt), Salesforce (Kontaktdatensatz), Segment (identifizierte User-Traits) und Warehouse-Tabellen (über einen aufgelösten Identity Graph, falls vorhanden).
2. Daten ziehen. Stripe hat eine APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → zum Export des Customer-Objekts und der Charges. Salesforce exportiert Kontakt- und Aktivitätshistorie. Das Warehouse ist der schwierige Teil: personenbezogene Daten können über Dutzende Tabellen aus Jahren von Ad-hoc-Pipelines verstreut sein.
3. Ausnahmen anwenden. Finanzdaten mit steuerlichen Pflichten bleiben. Alles, was nicht gesetzlich aufbewahrt werden muss, geht.
4. Innerhalb der Frist antworten. 30 Tage nach DSGVO (einmalig um 60 weitere Tage verlängerbar bei komplexen Anfragen). CCPA gibt 45 Tage, einmalig um weitere 45 verlängerbar.
5. Alles protokollieren. Regulatoren können verlangen, dass Sie einen Prozess nachweisen, nicht nur dass Sie eine Anfrage gut bearbeitet haben.

Ein minimaler technischer Check: finden Sie die Person überhaupt?

Eine einfache Diagnose, bevor ein Regulator fragt: Lassen Sie diese Art von Query gegen Ihr Warehouse laufen und schauen Sie, wie lange es dauert und wie viele Tabellen Sie anfassen müssen.

-- grobes Beispiel: jede Tabelle finden, die auf einen bestimmten Nutzer verweist
-- (gegen Warehouse-Metadaten ausführen, z. B. Snowflakes INFORMATION_SCHEMA)
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY ('%email%', '%user_id%', '%customer_id%')
ORDER BY table_schema, table_name;

Wenn das 60 Tabellen über fünf Schemas ohne jede Data-Lineage-Dokumentation zurückgibt, ist das Ihre Governance-Lücke. Reife Teams lösen das mit einem Data CatalogData CatalogEin zentrales Inventar der Datenbestände eines Unternehmens, angereichert mit Metadaten, das Menschen hilft, die benötigten Daten zu finden, zu verstehen und ihnen zu vertrauen.Vollständige Definition ansehen → (Tools wie Atlan, Collibra oder das Open-Source-Tool OpenMetadata), der Spalten mit personenbezogenen Daten (PII, personally identifiable information) taggt und die Lineage von der Quelle bis zum Dashboard verfolgt.

Data GovernanceData GovernanceData Governance umfasst die Regeln, Rollen und Prozesse, die sicherstellen, dass Daten in einer Organisation korrekt, sicher, klar definiert und verantwortungsvoll genutzt werden.Vollständige Definition ansehen →: die langweilige Infrastruktur, die Sie rettet

Governance ist die Menge an Policies und Kontrollen, die bestimmen, wer auf welche Daten zugreifen darf, wie lange und warum. Für SaaS zählen vor allem drei praktische Checks:

Data Mapping. Ein lebendes Dokument (kein einmaliges PDF), das jedes System auflistet, das personenbezogene Daten berührt, was es enthält, die Rechtsgrundlage der Verarbeitung (die DSGVO verlangt eine: Einwilligung, Vertrag, berechtigtes Interesse usw.) und die Aufbewahrungsfrist. Das britische Information Commissioner's Office hat dazu einen kostenlosen, praktischen Leitfaden: ICO's guide to data mapping.

Löschfristen im Code durchgesetzt, nicht in Policy-Dokumenten. Wenn Ihre Datenschutzerklärung sagt „wir löschen inaktive Accounts nach 2 Jahren“, aber kein Cronjob das tatsächlich tut, haben Sie eine Compliance-Lücke, und im Streitfall eine auffindbare.

Access Audits. Regelmäßig prüfen, wer intern im Unternehmen (nicht nur externe Auftragsverarbeiter) rohe Kundendaten abfragen kann. Ein Support-Engineer mit uneingeschränktem Warehouse-Zugriff auf Produktions-PII ist ein häufiger Befund in Security-Reviews und ein echter Verstoß gegen die DSGVO-Datenminimierung (Artikel 5(1)(c): nur verarbeiten, was notwendig ist).

Vendors sind Teil Ihrer Compliance-Oberfläche

Nach DSGVO sind Stripe und Salesforce Ihre Auftragsverarbeiter; Sie sind der Verantwortliche (die Stelle, die entscheidet, warum und wie Daten verarbeitet werden). Sie brauchen mit jedem Vendor einen Auftragsverarbeitungsvertrag (DPA), Standard in deren Enterprise-Verträgen. Aber der DPA entlastet Sie nicht: Wenn Salesforce Daten falsch behandelt, weil Sie es falsch konfiguriert haben (z. B. einen Report öffentlich gemacht), haften Sie weiterhin gegenüber dem Regulator.

Deshalb ist „wir nutzen konforme Vendors“ nicht dasselbe wie „wir sind konform“. Ein Durchsetzungsmuster der EU-Datenschutzbehörden von 2023: Mehrere Unternehmen wurden nicht deshalb mit Bußgeldern belegt, weil ihr Cloud-Vendor unsicher war, sondern wegen eigener Fehlkonfiguration (öffentliche S3-Buckets, zu großzügige Salesforce-Sharing-Regeln).

Bußgelder sind real und spürbar. Die DSGVO-Höchststrafen liegen bei bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes, je nachdem, was höher ist (das ist eine gesetzliche Obergrenze, kein typisches Bußgeld; die tatsächlichen Beträge variieren stark je nach Fall und Schwere, laut den Durchsetzungsunterlagen des Europäischen Datenschutzausschusses). CCPA/CPRA-Bußgelder sind pro Verstoß niedriger (rund 2.500 $ pro unbeabsichtigtem Verstoß, 7.500 $ pro vorsätzlichem, Beträge nach kalifornischem Gesetz, periodisch anpassbar), summieren sich aber bei Consumer-Datenmengen schnell, da jede betroffene Person als eigener Verstoß zählen kann.

Die praktische Audit-Checkliste

Für eine Data- oder Product-Führungskraft, die die SaaS-Datenschutzreife bewertet:

• Können Sie eine vollständige Data MapMapEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen → erstellen, die zeigt, wo personenbezogene Daten liegen, innerhalb eines Tages, nicht einer Woche?
• Haben Sie einen dokumentierten, getesteten DSAR-Workflow mit einem Owner und einem SLA?
• Werden Aufbewahrungsfristen durch automatisierte Jobs durchgesetzt, nicht nur durch Policy-Text?
• Haben Sie unterzeichnete DPAs mit jedem Auftragsverarbeiter, der personenbezogene Daten berührt (Payment, CRM, Analytics, E-Mail, Support-Tools)?
• Ist der Warehouse-Zugriff auf rohe PII rollenbeschränkt und protokolliert?
• Haben Sie für jede Verarbeitungskategorie eine dokumentierte Rechtsgrundlage?

Key Takeaways

• Ein DSAR ist ein Systemproblem, bevor es ein Rechtsproblem ist: Sie müssen Identität über Payment-, CRM-, Event- und Warehouse-Systeme auflösen, die selten einen gemeinsamen Schlüssel haben.
• „Löschen“ ist nicht absolut. Gesetzliche Aufbewahrungspflichten (Steuer, Buchhaltung) können Löschbegehren überlagern; dokumentieren Sie die Ausnahmen, statt alles oder nichts zu löschen.
• DSGVO und CCPA/CPRA unterscheiden sich in der Mechanik (Fristen, Bußgeldstruktur, Durchsetzungsbehörden), aber beide verlangen, dass Sie wissen, welche Daten Sie haben und warum, und das ist im Kern eine Data-Governance-Fähigkeit.
• Vendor-Verträge (DPAs mit Stripe, Salesforce usw.) steuern rechtliches Risiko, beseitigen es aber nicht; Fehlkonfiguration auf Ihrer Seite ist eine häufige, reale Ursache für Durchsetzungsmaßnahmen.
• Bauen Sie die langweilige Infrastruktur früh: eine gepflegte Data Map, automatisierte Löschjobs und Access Audits sind günstiger, als sie unter der Frist eines Regulators zu rekonstruieren.