Wann die Rechtsgrundlage für die Verarbeitung greift und was Sie dann tun sollten

Die Rechtsgrundlage greift immer dann, wenn Ihr SaaS-Unternehmen entscheidet, warum personenbezogene Daten verarbeitet werden und diese Entscheidung später auch Produktarbeit, Vendor-Reviews, Datenschutzhinweise und Audit-Nachweise tragen soll. Praktisch taucht die Frage deshalb früher und häufiger auf, als viele Teams annehmen. Sie stellt sich bei neuen Features, zusätzlichem Tracking, neuen Dienstleistern, geänderten Aufbewahrungsfristen, neuen Kundenszenarien oder einer späteren Zweckänderung.

Der nächste Schritt ist nicht, abstrakt über Rechtsbegriffe zu diskutieren. Der nächste Schritt ist, die konkrete Verarbeitung eng zu beschreiben, sie mit dem tatsächlichen Zweck zu verbinden, die Erforderlichkeit zu prüfen, die Begründung zu dokumentieren und sie an den realen Ablauf zu koppeln. Erst dann wird Artikel 6 DSGVO zu operativer Steuerung statt zu bloßer Policy-Sprache.

Wenn Ihrem Team zuerst die Grundidee fehlt, starten Sie mit dem Glossareintrag zur Rechtsgrundlage. Für das größere System helfen auch der Praxisleitfaden, die Checkliste und die häufigen Fehler.

Wann die Analyse der Rechtsgrundlage tatsächlich nötig ist

Artikel 6 DSGVO sagt, dass eine Verarbeitung nur rechtmäßig ist, wenn mindestens eine Rechtsgrundlage greift. Das klingt zunächst eindeutig, wird aber oft so missverstanden, als sei die Frage nur bei Policy-Entwürfen oder Datenschutzhinweisen relevant.

Tatsächlich ist die Analyse immer dann nötig, wenn das Unternehmen entscheidet:

• welche personenbezogenen Daten erhoben werden;
• warum die Verarbeitung stattfindet;
• ob die Aktivität für diesen Zweck wirklich erforderlich ist;
• wie lange die Daten im Ablauf bleiben;
• welche Systeme, Vendoren oder Teams Zugriff erhalten;
• ob dieselben Daten später für einen anderen Zweck erneut genutzt werden.

Damit gehört die Frage nicht in die Launch-Woche, sondern in Produktplanung, Vendor Intake, Marketing-Design, Retention-Reviews und Change Management. Die ICO-Leitlinie ist hier besonders praktisch: Die Grundlage soll vor dem Start der Verarbeitung feststehen, dokumentiert werden und nicht nachträglich einfach ausgetauscht werden.

Warum das operativ so wichtig ist

Die meisten Teams scheitern nicht daran, dass ihnen der Begriff unbekannt ist. Sie scheitern daran, dass die Antwort nie in eine benutzbare Regel übersetzt wurde.

Ein Produktteam weiß vielleicht, dass die Kontoerstellung eng an die Leistungserbringung gekoppelt ist, ist aber trotzdem unsicher:

• ob optionale Profilfelder wirklich erforderlich sind;
• ob Event-Tracking auf derselben Grundlage wie das Kernfeature läuft;
• ob Support-Daten später für Marketing oder Sales genutzt werden dürfen;
• ob ein neuer Vendor den Verarbeitungskontext so verändert, dass neu geprüft werden muss.

Ohne belastbare operative Antwort landet die Arbeit zur Rechtsgrundlage in Ausnahmen, Eskalationen und Last-Minute-Freigaben. Genau deshalb hängt sie eng mit Datenminimierung, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen sowie Privacy-Impact-Reviews in der Produktplanung zusammen.

Der praktische Test: Wann sollte Ihr Team anhalten und die Frage stellen?

Ihr Team sollte einen Check der Rechtsgrundlage durchführen, wenn eine der folgenden Situationen eintritt:

Ein neuer Ablauf verarbeitet personenbezogene Daten

Dazu gehören neue Onboarding-Schritte, Feature-Releases, Support-Automatisierungen, Zahlungsabläufe, Fraud-Kontrollen, CRM-Synchronisationen oder Änderungen interner Tools. Sobald ein neuer Zweck oder eine neue Verarbeitungstätigkeit entsteht, ist die Frage bereits da.

Ein bestehender Ablauf bekommt einen neuen Zweck

Das ist einer der häufigsten Fehler. Daten, die zuerst für die Serviceerbringung erhoben wurden, werden später für Analytics, Expansion, Cross-Sell, Security-Analysen oder Modellverbesserung wiederverwendet. In diesem Moment reicht die ursprüngliche Antwort oft nicht mehr.

Das Team möchte sich auf Erforderlichkeit stützen

Mehrere Grundlagen aus Artikel 6 hängen in unterschiedlicher Form von Erforderlichkeit ab, etwa Vertrag, rechtliche Verpflichtung oder berechtigte Interessen. Wenn das Unternehmen nicht erklären kann, warum die Verarbeitung für den Zweck wirklich nötig ist, wirkt die gewählte Grundlage schnell schwächer als gedacht.

Ein neuer Vendor oder ein neues Tool verändert den Verarbeitungskontext

Auch bei gleichbleibendem Zweck kann ein neues System den Zugriff ausweiten, Daten in neue Umgebungen kopieren, Datensätze anreichern oder Aufbewahrungsfristen verändern. Genau dort kippt eine zuvor tragfähige Datenschutzposition oft.

Sensible oder risikoreichere Daten kommen hinzu

Sobald besondere Kategorien personenbezogener Daten betroffen sind, reicht Artikel 6 allein nicht mehr. Dann kann zusätzlich Artikel 9 relevant werden, ebenso mehr Dokumentation und frühere Eskalation.

Was Sie dann tun sollten: ein wiederholbarer Ablauf

Sobald die Frage greift, sollten die nächsten Schritte praktisch und konsistent sein. Ein kleiner wiederholbarer Ablauf hilft meistens mehr als ein langes Memo.

1. Die Verarbeitung eng beschreiben

Starten Sie nicht mit "wir verarbeiten Kundendaten für die Plattform". Beschreiben Sie lieber die konkrete Tätigkeit:

• Nutzerkonten anlegen;
• Logins authentifizieren;
• Rechnungen versenden;
• verdächtiges Verhalten erkennen;
• Feature-Nutzung messen;
• Demo-Anfragen an Sales weiterleiten.

Je enger die Beschreibung, desto leichter lassen sich Zweck, Erforderlichkeit und Erwartung prüfen.

2. Den tatsächlichen Zweck in klarer Sprache festhalten

Der Zweck sollte erklären, warum die Aktivität existiert, nicht nur, in welchem Tool die Daten liegen. "Liegt in HubSpot" ist kein Zweck. "Eingehende Enterprise-Demo-Anfragen nachverfolgen" ist einer.

Genau das ist wichtig, weil die Rechtsgrundlage zum echten Zweck und Kontext passen muss. Auch die EDPB-Leitlinie koppelt die Prüfung immer wieder an konkrete Zwecke und konkrete Verarbeitungssituationen.

3. Prüfen, ob die gewählte Grundlage wirklich passt

Je nach Grundlage sollten unterschiedliche Fragen gestellt werden:

• Bei Vertrag: Ist die Verarbeitung wirklich nötig, um den Dienst zu erbringen oder vorvertragliche Schritte umzusetzen?
• Bei Einwilligung: Hat die betroffene Person eine echte Wahl, und kann die Verarbeitung bei Verweigerung oder Widerruf tatsächlich stoppen?
• Bei rechtlicher Verpflichtung: Welches Gesetz verlangt die Verarbeitung?
• Bei berechtigten Interessen: Welches Interesse wird verfolgt, warum ist die Verarbeitung nötig und warum überwiegen im konkreten Fall nicht die Rechte der betroffenen Person?

Wenn die Antwort hier schon vage bleibt, wird sie unter Kunden-, Audit- oder Behördenfragen später kaum stabiler.

4. Die Bedingungen dokumentieren, unter denen die Entscheidung trägt

Ein guter Entscheidungsnachweis nennt nicht nur die Grundlage. Er dokumentiert:

• die Aktivität;
• den Zweck;
• die gewählte Grundlage;
• warum sie passt;
• den Owner;
• die beteiligten Systeme oder Vendoren;
• welche Bedingungen dauerhaft erfüllt bleiben müssen;
• was eine erneute Prüfung auslöst.

So wird auch Accountability praktisch. Artikel 5 Absatz 2 DSGVO verlangt, dass der Verantwortliche die Einhaltung nachweisen kann. Häufig gelingt das erst durch genau diesen kurzen, aber brauchbaren Nachweis.

5. Die Entscheidung an den realen Ablauf anbinden

Wenn Einwilligung nötig ist, muss es einen tatsächlichen Consent-Mechanismus geben. Wenn Vertrag die Grundlage ist, sollten Produkt- und Operations-Teams wissen, welche Felder wirklich nötig und welche nur optional sind. Wenn berechtigte Interessen genutzt werden, müssen Guardrails und Abwägung verständlich im Ablauf auftauchen.

Erst an dieser Stelle wird Datenschutz operativ.

6. Re-Review-Trigger definieren

Gehen Sie nicht davon aus, dass die Antwort ewig gilt. Prüfen Sie neu, wenn:

• sich der Zweck ändert;
• sich die Datenkategorie ändert;
• der Vendor wechselt;
• die Aufbewahrungsfrist wächst;
• sich Nutzererwartungen oder Zielgruppe verändern;
• der Ablauf intrusiver oder stärker kommerziell wird.

Diese kurze Trigger-Liste verhindert oft mehr Probleme als eine lange Richtlinie.

Typische Szenarien und was sie meist bedeuten

Kernleistung des Dienstes

Wenn ein Nutzer Ihr Produkt aktiv bestellt, sind Kontoanlage, Authentifizierung, Billing und Service-Mitteilungen oft am leichtesten einzuordnen, weil die Beziehung klar ist. Trotzdem bleibt die Frage nach der Erforderlichkeit zentral. "Kernleistung" darf nicht stillschweigend auf jedes Feld und jeden Folge-Use-Case ausgedehnt werden.

Optionale Analytics und Telemetrie

Hier wird die Argumentation oft unsauber. Manche Telemetriedaten sind für Sicherheit, Debugging oder Stabilität plausibel nötig. Andere Auswertungen sind vor allem nützlich. Der sicherste Weg ist, Zweck für Zweck zu prüfen, statt alle Produkt-Analytics in denselben Topf zu werfen.

Marketing und Lifecycle-Kommunikation

Viele Teams verwischen die Grenze zwischen Service-Kommunikation und Werbung. Wenn der echte Zweck Produktadministration ist, kann eine Grundlage passen. Wenn es um Marketing, Cross-Sell oder Reaktivierung geht, kann die Bewertung anders ausfallen.

Security-Monitoring und Fraud Prevention

Diese Abläufe sind oft gut vertretbar, wenn Zweck, Erforderlichkeit und Schutzmaßnahmen sauber dokumentiert sind. Sie werden schwieriger, wenn der Umfang still wächst, die Aufbewahrungslogik unklar bleibt oder niemand erklären kann, warum das Ziel nicht weniger eingriffsintensiv erreicht werden könnte.

Wie gute Evidenz nach der Entscheidung aussieht

Starke Arbeit zur Rechtsgrundlage hinterlässt meist einfache, aber nützliche Evidenz:

• ein Processing Inventory mit sinnvollen Feldern zu Zweck und Grundlage;
• kurze Entscheidungsnachweise für riskante oder unklare Vorgänge;
• Intake-Fragen für Produkt- oder Vendor-Prozesse, die das Thema früh sichtbar machen;
• Datenschutzhinweise, die zum realen Ablauf passen;
• benannte Owner, die erklären können, wie die Regel in der Praxis funktioniert.

Diese Evidenz ist wichtig, weil es nicht nur darum geht, einmal die richtige Antwort zu finden. Entscheidend ist, dass dieselbe Antwort später über Teams und Zeit hinweg konsistent erklärt werden kann.

FAQ

Was ist der praktische Zweck der Rechtsgrundlage?

Der praktische Zweck ist, dass jede wesentliche Verarbeitung einen belastbaren Grund, einen klaren Owner und eine Dokumentation erhält, die erklärt, warum die Verarbeitung unter der DSGVO zulässig ist.

Wann greift die Rechtsgrundlage für SaaS-Teams?

Immer dann, wenn ein SaaS-Team personenbezogene Daten erhebt, nutzt, teilt, speichert oder für einen neuen Zweck weiterverwendet. Neue Features, neue Vendoren, neues Tracking, neue Marketing-Nutzung oder geänderte Aufbewahrungsregeln sind typische Auslöser.

Was sollten Teams zuerst dokumentieren oder ändern?

Starten Sie mit Aktivität, Zweck, gewählter Grundlage, Begründung, Owner und Re-Review-Triggern. Anschließend sollte der Ablauf so verändert werden, dass die Entscheidung nicht nur in einer Policy steht, sondern in der Umsetzung sichtbar wird.

Quellen

• General Data Protection Regulation
• EDPB: Process personal data lawfully
• ICO: A guide to lawful basis