Haufige Fehler bei der Rechtsgrundlage fur die Verarbeitung, die SaaS-Teams immer noch machen

SaaS-Teams scheitern bei der Rechtsgrundlage selten daran, dass niemand Artikel 6 kennt. Das Problem ist meist praktischer: Die Entscheidung wird zu breit, zu spat oder zu schwach dokumentiert getroffen, um Produktanderungen, Vendor-Wechsel oder Kundendruck standzuhalten.

Darum tauchen dieselben Fehler immer wieder auf. Es geht nicht nur um juristische Auslegung, sondern darum, wie Privacy-Entscheidungen in echten Workflows getroffen, dokumentiert und erneut gepruft werden.

Warum diese Fehler bestehen bleiben

Die meisten Entscheidungen zur Rechtsgrundlage entstehen mitten in anderer Arbeit:

• ein Feature steht kurz vor dem Launch;
• ein neues Analytics-Tool wird eingerichtet;
• Marketing plant eine neue Zielgruppe;
• Procurement ist fast durch;
• Sales braucht schnell eine Antwort fur einen groBen Kunden.

In solchen Momenten wird oft eine schnelle statt eine belastbare Antwort gesucht.

Fehler 1: eine Grundlage als pauschale Antwort behandeln

"Unsere Grundlage ist Vertrag" oder "unsere Grundlage ist berechtigtes Interesse" klingt praktisch, passt aber selten fur alle Workflows.

Die Kerndienstleistung kann auf Vertrag beruhen. Werbekampagnen oft nicht. Sicherheitsprozesse konnen berechtigte Interessen stutzen. Gesetzliche Aufbewahrung kann auf rechtlicher Verpflichtung beruhen.

Die Grundlage sollte immer einen konkreten Zweck erklaren, nicht das ganze Unternehmen pauschal abdecken.

Fehler 2: die Notwendigkeit nicht wirklich prufen

Viele Teams wahlen zuerst die Grundlage und testen erst spater, ob die Verarbeitung dafur wirklich notwendig ist.

Genau das schwacht die Entscheidung:

• Vertrag wird fur Daten genutzt, die hilfreich, aber nicht notwendig sind;
• berechtigte Interessen werden ohne Prufung milderer Alternativen verwendet;
• Einwilligung wird eingesetzt, obwohl keine echte Wahl besteht;
• rechtliche Verpflichtung wird genannt, ohne das konkrete Gesetz zu benennen.

Fehler 3: zu vage Zwecke formulieren

Wenn der Zweck unklar ist, bleibt auch die Analyse unklar.

Vage Formulierungen wie:

• die Plattform verbessern;
• den Betrieb unterstutzen;
• das Kundenerlebnis verbessern;
• interne Risiken steuern;

helfen kaum weiter. Besser sind konkrete Zwecke wie verdachtige Logins erkennen, Rechnungen versenden oder Feature-Nutzung messen.

Fehler 4: Einwilligung fur die sicherste Option halten

Einwilligung klingt oft vorsichtig, ist aber nicht automatisch die beste oder sicherste Antwort.

Wenn betroffene Personen nicht wirklich ablehnen oder widerrufen konnen, ist Einwilligung meist nicht passend. Genau darauf weist auch die EDPB-Leitlinie hin.

Fehler 5: berechtigte Interessen ohne echte Abwagung nutzen

Berechtigte Interessen sind fur viele SaaS-Workflows nutzlich. Gerade deshalb werden sie oft zu locker verwendet.

Eine belastbare Bewertung sollte klar machen:

• welches konkrete Interesse verfolgt wird;
• warum die Verarbeitung dafur notwendig ist;
• was betroffene Personen vernunftigerweise erwarten;
• welche SchutzmaBnahmen die Auswirkungen begrenzen;
• warum die Rechte der Betroffenen nicht uberwiegen.

Fehler 6: neue Zwecke nicht neu prufen

Oft war die ursprungliche Grundlage vertretbar, aber dieselben Daten werden spater fur einen neuen Zweck genutzt.

Typische Beispiele:

• Produktnutzungsdaten werden spater fur Marketing-Segmentierung genutzt;
• Support-Daten werden fur Sales-Chancen ausgewertet;
• Account-Daten werden fur Werbekampagnen wiederverwendet.

Wenn sich der Zweck andert, sollte gepruft werden, ob auch eine neue Grundlage notwendig ist.

Fehler 7: nur das Label dokumentieren, nicht die Begrundung

Ein Dropdown-Feld in einer Tabelle reicht selten aus. Teams brauchen auch die Antwort auf die naheliegende Anschlussfrage: Warum passt diese Grundlage hier?

Eine nutzliche Dokumentation sollte mindestens enthalten:

• die konkrete Verarbeitung;
• den Zweck;
• die gewahlte Grundlage;
• warum sie passt;
• Bedingungen und Grenzen;
• beteiligte Systeme oder Vendoren;
• den Owner;
• Re-Review-Trigger.

Fehler 8: sensible Daten zu spat erkennen

Manche Teams betrachten nur Artikel 6 und ubersehen, dass bei sensiblen Daten zusatzlich Artikel 9 relevant wird.

Das passiert etwa bei Gesundheitsdaten, biometrischen Signalen, HR-nahen Prozessen oder Analysen, die den Sensibilitatsgrad der Daten erhohen.

Fehler 9: nachgelagerte Tools und Vendoren vergessen

Selbst wenn der Hauptworkflow sauber gepruft wurde, werden CRM, Support-Tools, Analytics, Logs, Marketing-Automation oder Subprozessoren oft nicht sauber mitgedacht.

Dann wirkt die Policy sauber, wahrend die reale Datenkette unsauber bleibt.

Fehler 10: Entscheidungen nach Workflow-Anderungen nicht mehr anfassen

Auch eine gute Entscheidung wird schwach, wenn sich der Workflow spater verandert.

Eine neue Prufung ist sinnvoll, wenn:

• neue Datenfelder hinzukommen;
• ein Vendor Verarbeitung oder Speicherort andert;
• sich Kundensegmente und Erwartungen verandern;
• Retention ausgeweitet wird;
• neue AI- oder Security-Anwendungsfalle den Umfang verandern.

Was besser aussieht

Die meisten Teams brauchen kein schweres Rechtsprogramm, sondern einige stabile Gewohnheiten:

• Verarbeitungen eng definieren;
• den Zweck klar aufschreiben;
• Notwendigkeit vor der Auswahl prufen;
• die Begrundung dokumentieren;
• sensible Daten gesondert prufen;
• Systeme und Vendoren mitdenken;
• bei Zweck- oder Workflow-Anderungen erneut prufen.

Praktisches Fazit

Die groBten Fehler bei der Rechtsgrundlage sind meist kleine operative Abkurzungen, die sich aufsummieren: vage Zwecke, kopierte Annahmen, veraltete Eintrage und fehlende Re-Reviews.

Fur SaaS-Teams liegt die Losung weniger in einer besseren Privacy-Parole als in einem besseren Entscheidungsprozess.