Wann Pruefungen berechtigter Interessen gelten und was Sie als Naechstes tun sollten

Eine Pruefung berechtigter Interessen gilt, wenn ein SaaS-Team berechtigte Interessen als Rechtsgrundlage fuer eine konkrete Verarbeitung personenbezogener Daten nutzen will. Die Frage lautet nicht, ob der Begriff in der Datenschutzerklaerung stehen kann. Die Frage ist, ob das Team ein echtes Interesse benannt, die Notwendigkeit der Verarbeitung geprueft, die Rechte und Freiheiten der betroffenen Personen abgewogen und die passenden Schutzmassnahmen dokumentiert hat.

Artikel 6(1)(f) DSGVO erlaubt Verarbeitung, wenn sie fuer berechtigte Interessen des Verantwortlichen oder eines Dritten erforderlich ist, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person ueberwiegen. Fuer SaaS-Teams bedeutet das: Die Pruefung ist kein Ersatz fuer Consent, Vertrag oder DPIA. Sie ist ein Entscheidungsworkflow.

Wann die Pruefung ausgeloest wird

Eine LIA sollte vor Beginn der Verarbeitung stattfinden. Typische Ausloeser sind Account-Security-Monitoring, Betrugspraevention, Missbrauchserkennung, Produktzuverlaessigkeits-Analytics, Customer-Success-Prozesse, Support-Ticket-Analysen, begrenztes B2B-Marketing, interne Administration, Vendor-Integrationen, Retention-Aenderungen und AI-gestuetzte Auswertungen betrieblicher Datensaetze.

Sie gilt auch, wenn sich ein bestehender Workflow veraendert. Ein Support-Prozess kann fuer Kundenservice bewertet worden sein, aber nicht fuer das Training eines internen Klassifikators. Ein Security-Log kann fuer Incident Response gerechtfertigt sein, aber nicht automatisch fuer langfristige Verhaltensanalysen. Wenn Zweck, Datenkategorien, Vendor, Retention oder Nutzererwartung wechseln, reicht die alte Antwort oft nicht mehr.

Wann sie nicht der richtige Weg ist

Berechtigte Interessen sind nicht richtig, nur weil Einwilligung unbequem oder Vertrag zu eng wirkt. Wenn eine andere Rechtsgrundlage besser passt, sollte das Team dort anfangen. Bei besonderen Kategorien personenbezogener Daten, Kinderdaten, Employee Monitoring, aufdringlichem Profiling, automatisierten Entscheidungen oder unerwarteter Zweitnutzung braucht die Analyse deutlich mehr Sorgfalt und kann gegen Artikel 6(1)(f) sprechen.

Eine LIA ersetzt auch keine Datenschutz-Folgenabschaetzung. Wenn die Verarbeitung voraussichtlich ein hohes Risiko erzeugt, kann eine DPIA zusaetzlich noetig sein.

Was als Naechstes zu tun ist

Benennen Sie die Verarbeitung eng. "Plattform verbessern" ist zu breit. "Aggregierte Support-Ticket-Themen nutzen, um Dokumentation zu priorisieren" ist pruefbar. Danach formulieren Sie das legitime Interesse in klarer Sprache: Wer profitiert, warum ist das Interesse real und gegenwaertig, und warum stuetzt die Verarbeitung dieses Interesse?

Pruefen Sie anschliessend die Notwendigkeit. Braucht der Zweck wirklich personenbezogene Daten? Kann das Team aggregieren, Retention kuerzen, Felder reduzieren, Daten pseudonymisieren oder Zugriff begrenzen? Wenn eine weniger eingreifende Variante denselben Zweck erreicht, ist das urspruengliche Design schwerer zu verteidigen.

Danach folgt die Abwaegung. Beruecksichtigen Sie Art der Daten, Beziehung zum Nutzer, Kontext der Erhebung, vernuenftige Erwartungen, moegliche Auswirkungen, Umfang der Verarbeitung, Sensibilitaet des Kontexts und betroffene schutzbeduerftige Personen. Schutzmassnahmen zaehlen nur, wenn sie echte Controls mit Ownern und Nachweisen sind.

Nachweise, die die Entscheidung tragen

Gute Nachweise koennen ein Data-Flow-Vermerk, Product Ticket, Vendor Review, Update der Datenschutzerklaerung, Screenshot der Zugriffskontrolle, Retention-Regel, DPIA-Screening, Risk Acceptance oder Implementation Ticket sein. Wenn die LIA auf kurzer Retention beruht, verlinken Sie die Retention-Konfiguration. Wenn sie auf begrenztem Zugriff beruht, verlinken Sie das Access Model.

Haeufige Fehler

Der erste Fehler ist, mit der gewuenschten Rechtsgrundlage zu starten statt mit der Verarbeitung. Der zweite ist ein zu breites Interesse wie "Business Operations". Der dritte ist, vernuenftige Erwartungen zu ignorieren. Der vierte ist, Schutzmassnahmen als Versprechen statt als Controls zu behandeln. Der fuenfte ist, Review-Trigger zu vergessen.

FAQ

Was ist der praktische Zweck einer LIA?

Sie macht aus Artikel 6(1)(f) eine dokumentierte Betriebsentscheidung: Interesse, Notwendigkeit, Abwaegung, Schutzmassnahmen, Owner und Review-Trigger.

Wann gilt sie fuer SaaS-Teams?

Wenn ein Team berechtigte Interessen fuer einen Workflow mit personenbezogenen Daten nutzen will, etwa Security Monitoring, Fraud Prevention, Service Analytics, Support Operations oder begrenzte B2B-Kommunikation.

Was sollte zuerst dokumentiert werden?

Aktivitaet, Zweck, Interesse, Notwendigkeit, Abwaegungsfaktoren, Schutzmassnahmen, Owner, Freigabe und Review-Trigger.

Sources

• General Data Protection Regulation, Article 6 and Recital 47
• EDPB: Guidelines 1/2024 on processing based on Article 6(1)(f)
• ICO: How do we apply legitimate interests in practice?