Checkliste fuer Pruefungen berechtigter Interessen fuer Gruender und Compliance-Leads

Eine Pruefung berechtigter Interessen ist nur dann nuetzlich, wenn sie dem Team vor Beginn der Verarbeitung bei der Entscheidung hilft, ob Artikel 6 Absatz 1 Buchstabe f DSGVO fuer eine konkrete Verarbeitung tragfaehig ist. Die Checkliste sollte drei Fragen erzwingen: welches berechtigte Interesse verfolgt wird, ob die Verarbeitung fuer diesen Zweck erforderlich ist und ob Interessen oder Rechte der betroffenen Person ueberwiegen.

Fuer Gruender und Compliance-Leads geht es nicht darum, aus jeder Produktidee ein Rechtsgutachten zu machen. Es geht um einen wiederholbaren Nachweis, den Product, Legal, Security und Operations nutzen koennen, wenn ein neues Feature, ein Lieferant, Analytics, Betrugspraevention, Support oder Account-Security auf berechtigte Interessen gestuetzt werden soll.

Nutzen Sie diese Checkliste, wenn berechtigte Interessen als Rechtsgrundlage in Betracht kommen, wenn eine fruehere LIA veraltet ist oder wenn Kunden-Due-Diligence fragt, wie Datenschutzentscheidungen dokumentiert werden. Sie passt gut zu data protection by design and default, Privacy-Reviews in der Produktplanung und breiterer GDPR-Compliance-Planung.

1. Bestaetigen, dass berechtigte Interessen der richtige Kandidat sind

Pruefen Sie zuerst, ob das Team wirklich zwischen Rechtsgrundlagen waehlt oder nur zur flexibel klingenden Antwort greift. Berechtigte Interessen sind kein Ausweg aus Consent- oder Vertragsanalyse. Sie passen nur, wenn der Verantwortliche oder ein Dritter ein echtes Interesse hat, die Verarbeitung dafuer erforderlich ist und die Interessen, Rechte und Freiheiten der Person nicht ueberwiegen.

Beschreiben Sie die Verarbeitung in einfacher Sprache. Nennen Sie Produktbereich, System, Datenkategorie, betroffene Gruppe, Zweck, Owner, Lieferantenbeteiligung, Aufbewahrung und geplantes Launch- oder Aenderungsdatum. Wenn sich die Aktivitaet nicht klar beschreiben laesst, ist das Team fuer die Bewertung noch nicht bereit.

Pruefen Sie auch, ob eine andere Rechtsgrundlage naeher liegt. Vertrag kann besser sein, wenn die Verarbeitung fuer die angeforderte Leistung erforderlich ist. Rechtliche Verpflichtung kann gelten, wenn ein Gesetz die Verarbeitung verlangt. Consent kann noetig sein, wenn Nutzer echte Wahl haben muessen, besonders bei ePrivacy, Cookies, Tracking oder Direktmarketing.

2. Das berechtigte Interesse genau definieren

Der Zwecktest sollte ein konkretes Interesse nennen, keine vage Geschaeftsprioritaet. "Produkt verbessern" ist zu breit. "Aggregierte Onboarding-Events nutzen, um Abbruchstellen bei Business-Nutzern zu finden" ist pruefbar. "Security" ist zu vage. "Login-Metadaten 30 Tage verarbeiten, um Credential Stuffing und auffaellige Kontozugriffe zu erkennen" beschreibt den Fall.

Dokumentieren Sie, wer profitiert. Das Unternehmen kann durch Betrugspraevention, Account-Security, Serviceverbesserung oder B2B-Support profitieren. Kunden oder Nutzer koennen durch sicherere Konten, zuverlaessigere Dienste, weniger Missbrauch oder bessere Produktleistung profitieren. Auch Dritte koennen ein berechtigtes Interesse haben, aber der Record muss dieses Interesse erklaeren.

Das Interesse sollte rechtmaessig, spezifisch und aktuell sein. Es darf nicht auf einem Zweck beruhen, der anderem Recht widerspricht, der Datenschutzerklaerung entgegensteht oder Daten in einer fuer Nutzer unerwarteten Weise umwidmet.

3. Erforderlichkeit vor Kontrollen pruefen

Erforderlichkeit bedeutet nicht Bequemlichkeit. Sie bedeutet, dass der Zweck nicht vernuenftig mit weniger eingriffsintensiven Mitteln erreicht werden kann. Fragen Sie vor der Freigabe, ob weniger Daten, kuerzere Aufbewahrung, Aggregation, Pseudonymisierung, ein kleineres Event-Set, eingeschraenkter Zugriff, lokale Verarbeitung oder ein anderer Ablauf reichen.

Dokumentieren Sie Alternativen und warum sie angenommen oder abgelehnt wurden. Genau dieser Teil wird spaeter oft wichtig. Wenn ein Kunde oder eine Aufsichtsbehoerde fragt, warum User-Level-Daten statt aggregierter Metriken noetig waren, sollte das Team die Begruendung nicht Monate spaeter rekonstruieren muessen.

Typische Alternativen in SaaS sind aggregierte Analytics statt User-Level-Analytics, Stichproben-Logs statt vollstaendige Logs, kuerzere Diagnoseaufbewahrung, rollenbegrenzte Dashboards, Opt-outs, Feature Flags, spaetere Anreicherung und der Ausschluss sensibler Felder aus Data Warehouses.

4. Die Abwaegung durchfuehren

Die Abwaegung fragt, ob Interessen, Grundrechte oder Freiheiten der Person das berechtigte Interesse ueberwiegen. Erwaegungsgrund 47 betont vernuenftige Erwartungen auf Basis der Beziehung zwischen Person und Verantwortlichem. Das Team sollte deshalb fragen, was Nutzer, Admins, Mitarbeitende, Interessenten oder Kundenkontakte im Erhebungskontext erwarten duerfen.

Bewerten Sie die Art der Daten. Besondere Kategorien, strafrechtliche Daten, Kinderdaten, Finanzdaten, Standortdaten, Kommunikationsinhalte, sensible Support-Tickets und detaillierte Verhaltensprofile brauchen genauere Pruefung. Beruecksichtigen Sie auch, ob die Daten direkt von der Person, von einem Kundenadmin, aus Drittquellen oder aus beobachtetem Produktverhalten stammen.

Bewerten Sie die Wirkung. Koennte die Verarbeitung den Zugang zum Service beeinflussen, unfaires Profiling erzeugen, vertrauliche Informationen offenlegen, Rechteausuebung erschweren, Nutzer ueberraschen, interne Ueberwachung ausweiten oder Sicherheitsrisiken schaffen? Je schwerer die Wirkung, desto staerker muessen Interesse und Schutzmassnahmen sein.

5. Schutzmassnahmen und Umsetzung definieren

Eine LIA sollte nicht mit "freigegeben" enden. Sie sollte konkrete Schutzmassnahmen erzeugen, die Engineering, Product, Legal, Security und Operations umsetzen koennen. Dazu gehoeren Datenminimierung, Aggregation, Pseudonymisierung, Zugriffsbeschraenkung, Aufbewahrungslimits, klare Datenschutzhinweise, Opt-out- oder Suppression-Kontrollen, Lieferantenregeln, Monitoring und Review-Daten.

Machen Sie daraus Tickets oder Kontrollaufgaben. Wenn die Bewertung auf 90 Tagen Aufbewahrung beruht, verlinken Sie die Konfiguration oder den Implementation Task. Wenn sie auf beschraenktem internem Zugriff beruht, verlinken Sie Rolle oder Gruppe. Wenn ein Datenschutzhinweis aktualisiert werden muss, vergeben Sie Owner und Frist.

Hier wird GDPR jenseits von Cookie-Bannern operativ. Der staerkste Nachweis ist kein perfektes PDF, sondern ein kurzer Entscheidungsrecord, der mit den Systemaenderungen verbunden ist.

6. Entscheidung, Freigabe und Record

Die Entscheidung muss ausdruecklich sein. Halten Sie fest, ob sich das Team auf berechtigte Interessen stuetzen kann, sich nicht darauf stuetzen kann oder dies nur nach bestimmten Schutzmassnahmen darf. Erfassen Sie Owner, Reviewer, Datum, Evidenzlinks und naechsten Review-Ausloeser.

Vermeiden Sie bedingte Freigaben ohne Nachverfolgung. Wenn die Antwort lautet "ja, sobald Aufbewahrung verkuerzt und Notice aktualisiert ist", bleibt die LIA offen, bis diese Aufgaben abgeschlossen sind. Wenn die Antwort "nein" lautet, dokumentieren Sie die alternative Rechtsgrundlage oder die Entscheidung, Verarbeitung zu stoppen oder neu zu gestalten.

Der Record sollte kurz genug bleiben, um gepflegt zu werden. Bei moderatem Risiko reicht oft eine strukturierte Seite. Hohes Risiko kann eine tiefere Pruefung oder DSFA verlangen.

7. Bei geaenderten Fakten auffrischen

LIAs veralten, wenn sich die Fakten aendern. Oeffnen Sie den Record erneut, wenn Zweck, Datenkategorien, Aufbewahrung, Lieferanten, Modelle, Automatisierung, interne Zugriffe, betroffene Gruppen oder Nutzererfahrung wesentlich wechseln.

Setzen Sie auch fuer stabile Verarbeitung ein Review-Datum. Bei niedrigem Risiko kann jaehrliche Pruefung reichen. Bei Security Monitoring, Betrugspraevention, Enrichment, KI-gestuetztem Support, User-Level-Analytics oder sensiblen Betriebsdaten sollte haeufiger oder bei grossen Releases geprueft werden.

FAQ

Was sollten Teams ueber Pruefungen berechtigter Interessen verstehen?

Sie sollten verstehen, dass eine LIA ein strukturierter Entscheidungsrecord ist. Sie prueft Zweck, Erforderlichkeit, Abwaegung, Schutzmassnahmen, Ownership und Review-Ausloeser fuer eine konkrete Verarbeitung.

Warum sind Pruefungen berechtigter Interessen praktisch wichtig?

Sie helfen SaaS-Teams, Rechtsgrundlagen zu klaeren, bevor Produktdesign, Lieferanten, Analytics, Security Monitoring oder Kundenzusagen schwer aenderbar werden.

Was ist der groesste Fehler bei Pruefungen berechtigter Interessen?

Der groesste Fehler ist, die LIA erst nach der eigentlichen Entscheidung als Papierarbeit zu behandeln. Sie sollte das Design beeinflussen, nicht nur dokumentieren.

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.