Explizite Benennung der RGL/DV infolge Umsetzung Betroffenenrechte in DS-Information?

Moin.

Kontext: Nach Art. 13/14 I c), d) sind die Rechtsgrundlage und die Datenkategorien einer DV zu benennen.

Frage: jeder datenverarbeitende Prozess ist proaktiven/reaktiven Betroffenenrechten ausgesetzt. Muss ich nun bei jeder Datenschutzinformation (DSI) nach Artt. 13 f. DSGVO auch explizit erwähnen, dass zur Umsetzung der Betroffenenrechte im Prozess ‘natürlich’ auch Daten auf Basis von Art. 6 I c) DSGVO verarbeitet werden - oder muss der Betroffene nach Art. 13 IV bzw. Art. 14 V a) DSGVO mit dieser DV bei jedem Prozess rechnen, da sich dies als objektive Pflicht für den Controller aus eben jenen Vorschriften ergibt?

Art 13 + 14 betreffen die Erhebung. Eventuell ist eine Auskunftsanfrage gemeint?

Wobei ich bevorzuge, dass man zunächst auf §§-Kram verzichtet, sondern Inhalte verständlich nennt.

Nein. Und: das hilft mir bei der Ausgangsfrage nicht weiter. Es ging (ohne Normen) im Kern darum, ob ich in Informationstemplates immer über inhärente Datenverarbeitungsvorgänge informieren muss, die bei jedem Prozess anhängig sind oder sein können, wie etwa die Umsetzung von Betroffenenrechten als Reaktion auf den Prozess.

Was ist, wenn ich jetzt “Ja!” sage? Es wäre doch wünschenswert, bei jedem Punkt dazuzuschreiben, worauf er anwendbar ist.

Man sieht viele Datenschutzinformationen, die insgesamt möglichst viel aufführen. Alle möglichen Zwecke, alle möglichen (leider auch die unmöglichen) Rechtsgrundlagen, den maximalen Umfang der Empfänger, alle Fristen bzw. nur die längste der Verarbeitungsdauern, usw. Welche davon auf die spezifische Situation der Betroffenen zutreffen ist nicht ersichtlich. (“Such dir was raus!”) Transparent ist das nicht.

Man müsste sie also so zusammenstellen, dass alles abgedeckt ist, aber nach Möglichkeit die Verarbeitungen /Zielgruppen /Situationen benennen, wann einzelne Bereiche zutreffen. Evtl. gilt “alles” für die gerade beschriebene Haupt-Verarbeitung; und was nur unter bestimmten Bedingungen relevant ist, das steht dann dabei.

D., der noch auf der Suche nach dem Mittelweg ist. Insgesamt alles zu textlastig und damit nicht unbedingt tauglich.

Guter Punkt. Ggf. macht es wie im QM Sinn, nach Kern- und Support-Prozessen zu unterscheiden. Kernprozess (z.B. Onboarding) - volles Programm des Art. 13/14, Supportprozess (z.B. Umsetzung Betroffenenrechte) - auch Info nach Art. 13/14, aber an anderer Stelle (z.B. in der allgemeinen Datenschutz-Info für alle Beschäftigten oder platziert am Widerrufs-/Widerspruchs-Kanal). Das entlastet am Ende auch, ja.

1 „Gefällt mir“

Datenschutzerklärungen versuchen manchmal ja alle Verarbeitungen eines Verantwortlichen abzudecken; auch wenn diese vielfältig sind und in Teilen mit Auftragsverarbeitungsverhältnissen oder gemeinsamer Verantwortung zu tun haben können. Das geht schon, wenn man sie sauber segmentiert; z. B. die einzelnen Zielgruppen oder Tätigkeitsbereiche zum “Ausklappen” gestaltet.

Beispiel Auskunft: Dabei sollen die Betroffenen nur über Verarbeitungen informiert werden, denen sie tatsächlich unterliegen. Das wird bei z. B. Kunden eine Mainstream-Verarbeitung in dieser Rolle sein. Umfang, Zwecke, Rechtsgrundlage(n), Empfänger, Fristen. Dazu kommt nun aber noch der neue Zweck, dass die Daten zum Abwickeln des Auskunftsantrags verarbeitet werden. Das beschreibe ich in einem extra Absatz, in dem es nochmal um den speziellen Zweck, die Rechtsgrundlage, Empfänger und Dauer der Dokumentation zum Umsetzen von Betroffenenrechten geht. Also getrennt; nicht in der jeweiligen Kategorie der viel umfangreicheren Auskunftsstruktur.

D., der es nicht jedem recht machen kann.