Rechtsgrundlage für die Verarbeitung: Praxisleitfaden für SaaS-Teams

Die Rechtsgrundlage für die Verarbeitung ist für SaaS-Teams vor allem ein operatives Thema. Sie entscheidet, welche Datenverarbeitung für die Leistungserbringung nötig ist, wo Einwilligung gebraucht wird, welche Vorgänge auf gesetzlichen Pflichten beruhen und wo eine sorgfältige Interessenabwägung erforderlich ist. Wenn diese Zuordnung unklar bleibt, werden Launches langsamer, Vendor-Reviews unübersichtlich und Kundenfragen unnötig schwer zu beantworten.

Für die meisten Teams ist das Ziel nicht, juristische Schlagwörter auswendig zu lernen. Entscheidend ist, dass jede wesentliche Verarbeitung einen tragfähigen Zweck, einen klaren Owner und dokumentierte Nachweise hat. Genau dadurch wird Datenschutz von einer Debatte zu einem belastbaren Prozess.

Was die Rechtsgrundlage praktisch leistet

Nach der DSGVO braucht jede Verarbeitung personenbezogener Daten eine Rechtsgrundlage. Welche Grundlage gewählt wird, beeinflusst die Bedingungen der Verarbeitung, die Informationspflichten gegenüber Betroffenen und die praktische Ausgestaltung von Rechten. Auch der EDPB betont, dass die richtige Grundlage wichtig ist, weil jede Variante andere Anforderungen und Folgen mit sich bringt.

Praktisch erfüllt die Rechtsgrundlage drei Funktionen:

• sie erklärt, warum die Verarbeitung überhaupt stattfindet;
• sie definiert die Bedingungen, die für eine zulässige Verarbeitung gelten müssen;
• sie zeigt, welche Nachweise das Unternehmen bereithalten sollte.

Darum darf die Rechtsgrundlage nicht nur in einer Datenschutzerklärung oder Tabelle stehen. Wenn Billing, Onboarding, Analytics, Support und Vendor-Prozesse auf unterschiedlichen Annahmen beruhen, muss jemand diese Annahmen in wiederholbare Regeln übersetzen.

Als kurze Grundlage eignet sich zuerst der Glossareintrag zur Rechtsgrundlage. Danach lohnt sich der operative Ablauf unten.

Warum SaaS-Teams hier oft scheitern

Die meisten Teams scheitern nicht, weil ihnen Datenschutz egal ist. Das Problem ist eher, dass die tatsächliche Verarbeitungslandschaft breiter ist als die gedankliche Karte im Unternehmen.

Typische Verarbeitungen in einem SaaS-Produkt sind:

• Kontoerstellung und Authentifizierung;
• Zahlungs- und Abrechnungsprozesse;
• Produktanalyse und Telemetrie;
• Support-Tickets und CRM-Daten;
• Fehlerprotokolle und Security-Monitoring;
• Marketing-Automation und Lifecycle-E-Mails;
• Drittanbieter und Subprozessoren.

Für diese Vorgänge kann jeweils eine andere Rechtsgrundlage passend sein. Probleme entstehen, wenn eine Firma eine einzige Grundlage für das gesamte Produkt annimmt und nie prüft, ob dieselbe Begründung wirklich auf jeden Ablauf passt.

Wann die Analyse nötig ist und wann nicht

Die Prüfung der Rechtsgrundlage ist immer dann relevant, wenn das Unternehmen personenbezogene Daten neu erhebt, nutzt, teilt, speichert oder anders verarbeitet. Das betrifft neue Features, neue Tracking-Tools, neue Vendoren, längere Aufbewahrungsfristen und neue kommerzielle Use Cases.

Das bedeutet aber nicht, dass jede Verarbeitung dieselbe Antwort bekommt.

• Vertrag kann für Kontoerstellung, Kernfunktionalität, Billing oder echte vorvertragliche Schritte passen.
• Einwilligung kann für optionale Marketing-Abos oder optionales Tracking passend sein.
• Rechtliche Verpflichtung kann für steuerliche oder buchhalterische Aufbewahrung gelten.
• Berechtigtes Interesse kann bei bestimmten Security- oder Fraud-Use-Cases relevant sein, wenn Notwendigkeit und Abwägung nachvollziehbar sind.

Ein praktikabler Entscheidungsablauf

1. Die Verarbeitung eng beschreiben

Starten Sie nicht mit pauschalen Aussagen wie „wir verarbeiten Kundendaten für den Betrieb der Plattform“. Besser sind konkrete Aktivitäten wie:

• Nutzerkonten anlegen;
• Rechnungen versenden;
• Feature-Nutzung analysieren;
• verdächtige Logins erkennen;
• Newsletter versenden.

2. Den genauen Zweck festlegen

Der Zweck beschreibt, wofür die Verarbeitung stattfindet, nicht nur in welchem Tool Daten liegen. „Liegt in HubSpot“ ist kein Zweck. „Nachverfolgung von eingehenden Enterprise-Demo-Anfragen“ ist ein Zweck.

3. Die Notwendigkeit prüfen

Viele Teams verwechseln Nützlichkeit mit Notwendigkeit. Dass Daten hilfreich wären, reicht für eine Rechtsgrundlage nicht automatisch aus.

Bei Vertrag sollte gefragt werden, ob die Leistung ohne diese Daten tatsächlich erbracht werden kann. Bei rechtlicher Verpflichtung muss klar sein, welches Gesetz die Verarbeitung verlangt. Bei berechtigtem Interesse braucht es ein klares Interesse, eine echte Notwendigkeit und eine tragfähige Abwägung.

4. Die reale Erwartung der Nutzer prüfen

Nutzer erwarten bei der Kontoerstellung, dass die für den Service notwendigen Daten verarbeitet werden. Sie erwarten aber nicht automatisch, dass jede spätere Analyse, jedes zusätzliche Feld und jede Marketing-Kampagne auf derselben Begründung beruht.

5. Die Entscheidung dokumentieren

Für jede wesentliche Verarbeitung sollte dokumentiert werden:

• der Zweck;
• die gewählte Rechtsgrundlage;
• warum diese Grundlage passt;
• der Owner;
• die beteiligten Systeme und Vendoren;
• Bedingungen, die dauerhaft erfüllt bleiben müssen.

6. Produkt- und Vendor-Prozesse daran ausrichten

Eine Entscheidung zur Rechtsgrundlage muss sich in der Umsetzung wiederfinden. Wenn Einwilligung erforderlich ist, brauchen Produkt- und Marketing-Team einen belastbaren Consent-Flow. Wenn Vertrag die Grundlage ist, sollten die Datenfelder zu dem passen, was der Service wirklich braucht.

7. Bei Änderungen erneut prüfen

Neue Features, neue Subprozessoren, neue Aufbewahrungslogik oder neue kommerzielle Nutzungen können frühere Annahmen unbrauchbar machen. Genau deshalb gehört die Prüfung in die Launch-Planung und nicht in die Aufräumarbeit danach.

Häufige Fehler

Eine Grundlage als Pauschalantwort verwenden

Viele Teams sagen pauschal „unsere Grundlage ist Vertrag“. Das kann für Kernabläufe stimmen, aber nicht automatisch für jeden späteren Daten-Use-Case.

Einwilligung ohne echte Wahl nutzen

Wenn der Service ohne die Verarbeitung nicht funktioniert, ist Einwilligung oft keine saubere Wahl.

Berechtigtes Interesse ohne belastbare Abwägung nutzen

Berechtigtes Interesse ist kein Freifahrtschein. Das Team muss Interesse, Notwendigkeit und die Auswirkungen auf Betroffene erklären können.

Nebenprozesse und Vendoren übersehen

Oft wird nur der Hauptproduktfluss analysiert. Support-Tools, CRM-Syncs, Marketing-Automation oder Security-Logging bleiben außen vor und erzeugen später die größten Lücken.

Beispiele aus dem SaaS-Alltag

Kontoerstellung und Billing

Wenn ein Nutzer Ihr Produkt aktiv bestellt, liegt es nahe, die für Kontoanlage, Authentifizierung und Rechnungsverwaltung nötigen Daten eng an die Servicebeziehung zu knüpfen. Die operative Frage bleibt aber: Sind genau diese Daten wirklich erforderlich?

Produktanalyse und Telemetrie

Hier greifen Teams oft zu weit. Manche Telemetriedaten sind für Sicherheit, Fehlersuche oder Stabilität plausibel. Andere Analysen sind optionaler und brauchen eine getrennte Prüfung.

Marketing und Upsell-E-Mails

Gerade im Marketing verschwimmen Servicemitteilungen und Werbung. Wenn der eigentliche Zweck Promotion ist, sollte nicht automatisch dieselbe Grundlage gelten wie für die Kernleistung.

Security-Logging und Fraud Prevention

Security-Use-Cases lassen sich besser vertreten, wenn Zweck, Notwendigkeit und Umfang sauber dokumentiert sind. Entscheidend ist, die Maßnahme verhältnismäßig zu halten.

Gute Nachweise sehen meist simpel aus

Ein belastbarer Prozess hinterlässt oft einfache, aber nützliche Evidenz:

• ein Processing Inventory mit aussagekräftigen Zweck- und Basisfeldern;
• kurze Begründungen für riskante oder unklare Vorgänge;
• Produktanforderungen, die die Datenschutzentscheidung widerspiegeln;
• Vendor-Review-Notizen mit klar beschriebenem Zweck und Datenfluss;
• Datenschutzhinweise, die zum tatsächlichen Betrieb passen.

FAQ

Was sollten Teams zur Rechtsgrundlage verstehen?

Teams sollten verstehen, wann eine Rechtsgrundlage greift, welche operativen Folgen sie hat und welche Nachweise belegen, dass der Ablauf wirklich so umgesetzt wird.

Warum ist das praktisch wichtig?

Die Rechtsgrundlage prägt, wie Teams Risiko eingrenzen, Verantwortung zuweisen, Entscheidungen dokumentieren und Fragen von Kunden, Auditoren oder Aufsichtsbehörden beantworten.

Was ist der häufigste Fehler?

Der häufigste Fehler ist, die Rechtsgrundlage als einmalige juristische Einordnung zu behandeln, statt sie in einen wiederholbaren Prozess mit Ownern, Triggern, Nachweisen und Eskalationswegen zu übersetzen.

Weiterführende Ressourcen

• Glossareintrag Rechtsgrundlage
• GDPR-Hub
• Compliance-Glossar

Quellen

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