Haeufige Fehler bei Pruefungen berechtigter Interessen in SaaS-Teams

Der haeufigste Fehler bei Pruefungen berechtigter Interessen ist, das Ergebnis schon vor der Pruefung als offensichtlich zu behandeln. Artikel 6 Absatz 1 Buchstabe f DSGVO kann fuer SaaS-Teams nuetzlich sein, ist aber keine Abkuerzung um die Analyse der Rechtsgrundlage. Das Team muss ein berechtigtes Interesse benennen, die Erforderlichkeit zeigen und pruefen, ob Interessen, Rechte oder Freiheiten der Person ueberwiegen.

Das operative Risiko liegt selten darin, dass niemand den Begriff LIA kennt. Es liegt darin, dass die LIA zu spaet kommt, in einem Legal-Ordner verschwindet, zu vage formuliert ist oder Produkt, Logs, Lieferanten, Aufbewahrung, Hinweise und Zugriffsrechte nicht wirklich veraendert.

Fehler 1: Berechtigte Interessen als Standard behandeln

Berechtigte Interessen sind flexibel, aber nicht automatisch die Standardantwort. Die EDPB-Guidance beschreibt kumulative Bedingungen: ein berechtigtes Interesse, Erforderlichkeit fuer dieses Interesse und eine Abwaegung, bei der Rechte und Freiheiten der betroffenen Person nicht ueberwiegen.

Der Fehler entsteht oft, wenn Consent unpraktisch wirkt, Vertrag nicht ganz passt oder das Team die Nutzererfahrung nicht aendern moechte. Die Rechtsgrundlage sollte aber aus dem Verarbeitungskontext folgen, nicht aus dem einfachsten Implementierungspfad.

Die praktische Loesung ist ein kurzer Schritt zur Auswahl der Rechtsgrundlage vor der LIA. Pruefen Sie Vertrag, rechtliche Verpflichtung, Consent und andere Grundlagen. Wenn berechtigte Interessen uebrig bleiben, dokumentieren Sie warum.

Fehler 2: Den Zweck zu breit formulieren

"Produkt verbessern", "Kunden unterstuetzen" oder "Analytics betreiben" sind zu breit. Sie helfen nicht, Erforderlichkeit oder Abwaegung zu pruefen.

Besser ist ein konkreter Zweck: aggregierte Onboarding-Events nutzen, um Abbruchstellen bei Account-Admins zu erkennen; Login-Metadaten 30 Tage verarbeiten, um Credential Stuffing zu erkennen; oder Support-Metadaten fuer Kapazitaetsplanung auswerten.

Konkrete Zwecke helfen auch Engineering. Sie werden zu Feldern, Events, Retention, Rollen und Dashboard-Grenzen. Vage Zwecke fuehren fast immer zu Overcollection.

Fehler 3: Die Erforderlichkeit ueberspringen

Viele LIAs beschreiben den Business-Grund, zeigen aber nicht, warum genau diese Datenverarbeitung notwendig ist. Hilfreich ist nicht gleich erforderlich.

Pruefen Sie weniger eingriffsintensive Alternativen: aggregierte Metriken statt User-Level-Events, kuerzere Log-Aufbewahrung, Entfernung von Freitext, Pseudonymisierung, engere Lieferantenzugriffe oder rollenbasierte Dashboards.

Dokumentieren Sie Alternativen und Entscheidung. Wenn identifizierbare Daten noetig sind, erklaeren Sie, warum aggregierte oder weniger intensive Ansaetze den Zweck nicht erfuellen.

Fehler 4: Vernuenftige Erwartungen ignorieren

Erwaegungsgrund 47 lenkt den Blick auf vernuenftige Erwartungen im Verhaeltnis zwischen Person und Verantwortlichem. Nutzer erwarten vielleicht Account-Security-Logging, aber nicht automatisch detaillierte Verhaltensueberwachung, Training von Modellen mit Support-Inhalten oder breite interne Dashboards.

Dokumentieren Sie Beziehung, Erhebungskontext, Notice-Sprache, Nutzerkontrollen und Ueberraschungspotenzial. Wenn die Verarbeitung eine vernuenftige Person ueberraschen wuerde, braucht das Team staerkere Schutzmassnahmen, ein anderes Design, klarere Hinweise oder eine andere Rechtsgrundlage.

Fehler 5: Schutzmassnahmen als Versprechen behandeln

Eine LIA kann nur wirken, wenn Schutzmassnahmen umgesetzt werden. "Zugriff wird beschraenkt" ist schwach, wenn keine Gruppe, kein Owner und kein Review-Datum existieren. "90 Tage Aufbewahrung" ist schwach, wenn keine Konfiguration oder Loeschaufgabe verlinkt ist.

Machen Sie jede Schutzmassnahme zu einem Task oder Evidenzlink. Product aendert Defaults, Engineering entfernt Felder, Security begrenzt Rollen, Legal aktualisiert Notices, Compliance speichert den Record. So wird data protection by design and default praktisch.

Fehler 6: Die LIA erst nach dem Bau starten

Spaete LIAs sind schwach. Wenn Datenmodell, Vendor-Integration oder Dashboard bereits gebaut sind, wird die Bewertung zur Verteidigung des Bestehenden. Starten Sie die LIA in Product Intake, Launch Review, Vendor Review, Analytics Intake, Security-Monitoring-Aenderungen und AI-Workflow-Review.

Fruehe Pruefung reduziert Rework. Spaete Pruefung erzeugt Launch-Delay, Kundenstress und Ausnahmen. Deshalb sollten Privacy-Reviews in der Produktplanung starten.

Fehler 7: ePrivacy, Marketing und lokale Regeln vergessen

Eine GDPR-LIA loest nicht automatisch Cookies, Tracking, elektronische Direktwerbung oder nationale Kommunikationsregeln. Fuegen Sie deshalb einen kurzen Adjacent-Rules-Check ein: Cookies, aehnliche Technologien, Direct Marketing, sensitive Daten, Mitarbeiter-Monitoring, Kinder, regulierte Sektoren oder Transfers.

Wenn einer dieser Punkte betroffen ist, muss der richtige Policy Owner einbezogen werden. Die LIA beantwortet nicht jede Datenschutzfrage.

Fehler 8: Negative und bedingte Entscheidungen nicht festhalten

Teams speichern Freigaben, verlieren aber "nein", "nicht auf berechtigte Interessen" oder "ja, nur nach Schutzmassnahmen". Diese Entscheidungen sind wertvolle Evidenz.

Bedingte Freigaben brauchen Nachverfolgung. Wenn Retention verkuerzt, Notice aktualisiert oder User-Level-Daten durch aggregierte Metriken ersetzt werden muessen, bleibt die LIA offen, bis die Tasks abgeschlossen sind.

Fehler 9: Alte LIAs driften lassen

SaaS-Produkte aendern sich staendig. Zweck, Datenkategorien, Lieferanten, Retention, AI-Workflows und interne Zugriffe koennen wachsen. Jede LIA braucht Review-Trigger: Zweckwechsel, neue Daten, laengere Aufbewahrung, neue Lieferanten, breiterer Zugriff oder andere Nutzererfahrung.

Setzen Sie zusaetzlich einen Review-Rhythmus. Niedrigeres Risiko kann jaehrlich reichen. Security Monitoring, Fraud Prevention, Enrichment, AI-Support und User-Level-Analytics brauchen haeufiger Review.

Fehler 10: Den Record von Evidenz trennen

Eine isolierte LIA ist im Audit schwer nutzbar. Sie sollte auf Product Brief, Data-Flow, Vendor Review, Zugriffskonfiguration, Retention Controls, Notice-Update, DPIA-Screening und Implementation Tickets zeigen.

Speichern Sie die LIA dort, wo operative Teams sie finden. Das unterstreicht auch, warum GDPR nicht nur Cookie-Banner ist.

FAQ

Was sollten Teams ueber Pruefungen berechtigter Interessen verstehen?

Eine LIA ist ein Entscheidungsworkflow. Sie prueft Zweck, Erforderlichkeit, Abwaegung, Schutzmassnahmen, Ownership und Review-Trigger fuer eine konkrete Verarbeitung.

Warum ist das praktisch wichtig?

Sie hilft SaaS-Teams, Rechtsgrundlagen frueh genug zu klaeren, damit Produktdesign, Lieferanten, Retention, Zugriffe, Notices und Kundenaussagen noch angepasst werden koennen.

Was ist der groesste Fehler?

Der groesste Fehler ist, berechtigte Interessen als einfache Standardantwort zu behandeln. Eine belastbare LIA zeigt, warum diese Grundlage fuer diese Verarbeitung passt.

Quellen

• Europaeische Union, Datenschutz-Grundverordnung, Artikel 6 und Erwaegungsgrund 47.
• European Data Protection Board, Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR.
• Information Commissioner's Office, detaillierte Guidance zu legitimate interests, aktualisiert am 23. Maerz 2026.