Themen / Datenschutz

Für eine Digita­li­sie­rung des Daten­schutzes[1]

31. Dezember 2020

in: vorgänge Nr. 231/232 (3-4/2020), S. 117-129

Daten­schutz schützt die Grund­rechte bei der Digita­li­sie­rung. Der Daten­schutz selbst ist dagegen kaum digita­li­siert. Im Gegen­satz zu anderen Berei­chen – etwa dem Gesund­heits­wesen – gibt es keine Debatte über die ausblei­bende Digita­li­sie­rung des Daten­schut­zes. Im folgenden Beitrag eröffnen Jörg Pohle, Benjamin Berge­mann und Jan Schallaböck diese Debatte. Sie disku­tieren, warum die fehlende Digita­li­sie­rung des Daten­schutzes ein politi­sches Problem ist. Sie stellen Beispiele vor, wo und wie sich Digita­li­sie­rung für die Daten­schutz­kon­trolle nutzen lässt und welche Vorteile das für Bürger*innen, Daten­ver­a­r­beiter, Aufsichts­be­hörden und die gesell­schaft­liche Wirksam­keit des Daten­schutzes hätte.

Einleitung

Die prakti­sche Umset­zung des Daten­schutzes stützt sich noch immer weitge­hend auf Handa­r­beit und ist geprägt von einem Wildwuchs an Formaten und inkom­pa­ti­blen Syste­men. Es fehlt an einer verein­heit­lichten Praxis und an etablierten Standards für die Daten­schutz-­Fol­ge­n­ab­schät­zung (Artikel 35 DSGVO), für Daten­schutz by Design und by Default (Artikel 25), für die Infor­ma­tion der Betrof­fenen (Artikel 12–14) und für die Ausübung der Betrof­fe­nen­rechte (Artikel 15–18, 20–21). Ausgangs­punkt für all diese Mecha­nismen ist regel­mäßig eine Bestands­auf­nahme, die auch in die Verfah­rens­do­ku­men­ta­tion Eingang findet (Artikel 30).

Der europä­i­sche Gesetz­geber hat mit Einfüh­rung der Daten­schutz-­Grund­ver­ord­nung (DSGVO) sowohl die Pflicht zur Regis­trie­rung der Verfah­rens­do­ku­men­ta­tion als auch das ersatz­weise beste­hende allge­meine Recht auf Einsicht in die Verfah­rens­do­ku­men­ta­tion, welche im alten Bundes­da­ten­schutz­ge­setz (BDSG) noch enthalten waren, über Bord gewor­fen. Diese Möglich­keiten – zu Zeiten des BDSG recht unbekannt und wohl nur sehr selten genutzt – galten als reiner Forma­lismus, weswegen sie wohl als verzichtbar angesehen wurden. Es zeigt sich jedoch gerade in der Umset­zung der DSGVO, dass die Verfah­rens­do­ku­men­ta­tion als Bestands­auf­nahme eine unver­zicht­bare Voraus­set­zung für den rechts­kon­formen Umgang mit perso­nen­be­zo­genen Daten darstellt. Öffent­liche und elektro­nisch zugäng­liche Verfah­rens­do­ku­men­ta­ti­onen würden Austausch, Analyse und Verein­heit­li­chung erlau­ben. Sie könnten damit nicht nur die Einhal­tung und Kontrolle von Daten­schutz­vor­schriften erheb­lich erleich­tern, sondern auch den Weg für eine weiter­ge­hende Automa­ti­sie­rung des Daten­schutzes ebnen.

Kurz: Die Chancen der Digita­li­sie­rung bei der Umset­zung des Daten­schutzes werden nicht genutzt. Und das hat nicht nur Folgen für die Verant­wort­li­chen selbst, sondern auch für die Betrof­fenen und den Schutz ihrer Grund­rechte, sowie für die Aufsichts­be­hörden und nicht zuletzt auch für die Gesell­schaft insge­samt. Im Folgenden wollen wir den Versuch unter­nehmen, die Vision und die Wirklich­keit eines automa­ti­sierten Daten­schutzes aus verschie­denen Perspek­tiven zu kartieren und schlagen anschlie­ßend erste Schritte zu einer Automa­ti­sie­rung des Daten­schutzes vor. Wir wollen dazu beitragen, die Automa­ti­sie­rung des Daten­schutzes über Privacy Enhan­cing Techno­lo­gies (PETs) und formale Compliance hinaus zu denken und zu einer daten­schutzpolitischen Frage zu machen.

Daten­schutz und Automa­ti­sie­rung

Daten­schutz adres­siert die unerwünschten Folgen moderner Infor­ma­ti­ons­ver­a­r­bei­tung und zielt darauf ab, das Eintreten dieser Folgen durch die konkrete organi­sa­to­ri­sche und techni­sche Gestal­tung der Verar­bei­tung zu verhin­dern (Stein­müller et al. 1971: 44). Die DSGVO fokus­siert dabei, wie Artikel 1 Abs. 2 explizit formu­liert, auf Risiken für Grund­rechte und Grund­frei­heiten als Teilmenge aller gesell­schaft­lich unerwünschten Folgen.
Als Ausdeh­nung des Rechts­s­taats­prin­zips auf alle Infor­ma­ti­ons­ver­a­r­bei­tungen (Stein­müller 1976: 14), also auch auf dieje­nigen in privater Verant­wort­lich­keit, legt das Daten­schutz­recht einen starken Fokus auf Pflichten für Verar­beiter und die Kontrolle durch Aufsichts­be­hör­den. Aber auch die Gestal­tung von Organi­sa­ti­onen, Verar­bei­tungs­pro­zessen und infor­ma­ti­ons­tech­ni­schen Systemen wird adres­siert – und das schon seit den Anfängen der Daten­schutz­de­batte (Pohle 2015). „Soziale Freiheit ist nunmehr nur noch möglich, wenn sie von vornherein in die Konstruk­tion der Infor­ma­ti­ons­sys­teme einge­plant, auch mit den Mitteln der modernen Daten- und Kommu­ni­ka­ti­ons­tech­no­lo­gien technisch und organi­sa­to­risch abgesi­chert und schließ­lich in ihrem sozialen Umfeld recht­lich veran­kert und gewähr­leistet wird“ (Stein­müller et al. 1978: 2). Jede recht­liche, organi­sa­to­ri­sche und techni­sche Gestal­tung von Infor­ma­ti­ons­ver­a­r­bei­tung setzt jedoch voraus, dass Verar­bei­tungen beherrschbar gemacht werden, um ihre Folgen erfassen und entspre­chende Maßnahmen ergreifen zu können (Stein­müller 1979: 187).

Zu all dem bedarf es nicht nur geeig­neter Methoden, sondern auch der Werkzeuge, die bei der Umset­zung helfen – von der indivi­du­ellen und syste­mi­schen Bestands­auf­nahme über die Risiko­ana­lyse und die Auswahl der geeig­neten Maßnahmen bis hin zur Kontrolle der Daten­ver­a­r­bei­tungs­pra­xis. Ebenso braucht es grund­le­gende Standards, die nicht nur die Vergleich­bar­keit von Trans­pa­renz­in­for­ma­ti­onen und ergrif­fenen Maßnahmen erlauben, sondern selbst auch als Treiber des Standes der Technik wirken können.

Für die Verantwortlichen geht es primär um die Erfül­lung ihrer daten­schutz­recht­li­chen Pflich­ten. Voraus­set­zung hierfür ist die Selbst­be­ob­ach­tung bezüg­lich ihrer Struk­turen und Praktiken, die das Daten­schutz­recht – weitge­hend implizit – als Vorbe­din­gung für den prakti­schen Grund­rechts­schutz einfor­dert. Viele, gerade kleinere, Verant­wort­liche sind damit überfor­dert – nicht zuletzt, weil sie sich mühsam selbst überlegen müssen, wie und mit welchen Werkzeugen sie Daten­schutz prakti­zieren sollen.

Für die Betroffenen geht es nicht allein um die Vergleich­bar­keit von Trans­pa­renz­in­for­ma­ti­onen, die bei manueller Erstel­lung ohnehin nicht erreichbar ist, sondern auch um die Wahrneh­mung ihrer Rechte gegen­über den Verant­wort­li­chen. Ohne entspre­chende Werkzeuge bleiben sie hierbei auf deren Koope­ra­tion angewie­sen.

Auch die Aufsichtsbehörden werden durch die fehlende Automa­tion des Daten­schutzes in ihrer Arbeit behin­dert. Das gilt intern, bei der Bearbei­tung von Vorgängen oder bei der Kontrolle von Verant­wort­li­chen, wenn sie sich erst durch Berge von Papier kämpfen müssen, bevor sie überhaupt zur inhalt­li­chen Prüfung schreiten können. Aber es gilt auch gegen­über der Öffent­lich­keit, wenn sie ihrer Aufgabe, „die Anwen­dung dieser Verord­nung [zu] überwa­chen“ (Artikel 57 Abs. 1 Buchstabe a DSGVO), nicht angemessen nachkommen können, weil sie ohne entspre­chende automa­ti­sierte Verfahren gar nicht die Möglich­keit haben, moderne Infor­ma­ti­ons­ver­a­r­bei­tung jenseits von Einzel­fällen zu unter­su­chen.

Und nicht zuletzt: Wie wir gerade erst wieder in der Corona-­Krise lernen, ist es unerläss­lich, eine vernünf­tige Daten­basis zu haben, auf deren Grund­lage die Gesellschaft über mögliche Maßnahmen disku­tieren und entscheiden kann. An einer solchen Daten­basis fehlt es aber für eine der wohl entschei­denden gesell­schaft­li­chen Entwick­lungen der vergan­genen Jahre und Jahrzehnte: Über den gesell­schaft­li­chen Stand der Daten­ver­a­r­bei­tung und deren Impli­ka­ti­onen gibt es überra­schen­der­weise keine vernünf­tige empiri­sche Grund­lage, obwohl das tragende Paradigma der Digita­li­sie­rung die Voller­he­bung zu sein scheint (Klumpp 2014: 277 ff.). Es grenzt an Absur­dität, dass Daten­ver­a­r­beiter nahezu jeden unserer Handlungs­schritte proto­kol­lieren, aber die Gesell­schaft nicht zur Kenntnis nehmen kann, was die Daten­ver­a­r­beiter tun.

Die Automa­ti­sie­rung des Daten­schutzes ist bisher – wenn überhaupt – Gegen­stand von Fachde­bat­ten. Dominie­rend ist hier der Diskurs zu Privacy Enhan­cing Techno­lo­gies (PETs), in dem die Automa­ti­sie­rung des Daten­schutzes aller­dings oft auf einen rein indivi­du­a­lis­tisch verstan­denen Begriff von „Privacy“ begrenzt wird (Diaz/­Gürses 2012), bei dem ein umfas­sen­deres Verständnis von Daten­schutz auf der Strecke bleibt. Versuche, das Thema ganzheit­li­cher zu disku­tieren (vgl. etwa Schartum 2001), sind in der Vergan­gen­heit schnell versan­det. Auch anläss­lich des zweiten Jahres­tages der Anwend­bar­keit der DSGVO wurde die Automa­ti­sie­rung des Daten­schutzes kaum thema­ti­siert (Ausnah­men: Privacy Company 2019; Digitale Gesell­schaft 2020).

Die Diskus­sion um die Digita­li­sie­rung des Daten­schutzes wollen wir im Folgenden aus diesen vier Perspek­tiven – Verant­wort­liche, Betrof­fene, Aufsichts­be­hörden und Gesell­schaft – aufgrei­fen.

Der gesell­schaft­liche Wert eines automa­ti­sierten Daten­schutzes

Die aufge­klärte bürger­lich-­li­be­rale Gesell­schaft unter­stellt, dass ihre politi­sche Delibe­ra­tion und Entschei­dungs­fin­dung auf der Basis umfas­sender und fundierter Infor­ma­ti­onen über die Phäno­mene, über die sie entscheiden soll oder will, statt­fin­det. Für den gesell­schaft­li­chen Stand der Digita­li­sie­rung liegen solche Infor­ma­ti­onen jedoch bisweilen kaum oder gar nicht vor. Dies beginnt schon bei der Schwie­rig­keit, den Stand der Technik zu bestimmen, da die Einsatz­sze­na­rien kaum syste­ma­ti­siert sind. Noch relevanter ist es für die Frage des konkreten Einsatzes von Verfahren, Systemen und „Code“ – vor allem in der Breite und nicht nur an ausge­wählten Beispie­len. Und es gilt für die Praktiken, die damit verbunden sind. Schließ­lich geht es vor allem um die Folgen für Indivi­duen, Gruppen und die Gesell­schaft, für indivi­du­elle Rechte und gesell­schaft­liche Struk­tu­ren.

Als Beispiel könnte man die gegen­wär­tige „Algo­rithmen“-Debatte heran­ziehen, in der über „ethi­sche“ Anfor­de­rungen an „Algo­rithmen“ disku­tiert wird, ohne dass eine Bestands­auf­nahme zugrunde gelegt wurde. Wir wissen nicht viel über die konkreten Risiken, die in konkreten Situa­ti­onen von konkreten Akteuren durch den Einsatz konkreter Infor­ma­tik­sys­teme für je konkrete Betrof­fene oder gesell­schaft­liche Werte erzeugt, verstärkt oder verste­tigt werden – geschweige denn über deren Relevanz.

Angemes­sener erscheint es, wenn Verant­wort­liche ihre Bestands­auf­nahme und Risiko­ana­lyse technik­ge­stützt und auf der Basis offener und frei verfüg­barer Standards vornähmen und die Ergeb­nisse maschi­nen­lesbar zugäng­lich machten, damit diese zusam­men­ge­tragen und ausge­wertet werden können. Auf der gesell­schaft­li­chen Ebene geht es dabei nicht – oder nicht vorrangig – darum, bei einzelnen Verant­wort­li­chen Probleme, Versäum­nisse oder gar Geset­zes­ver­stöße aufzu­de­cken, sondern um das Feststellen eines „State of the digital World“: Wie sieht die Infor­ma­ti­ons­ver­a­r­bei­tung eigent­lich in der Praxis aus? Wie ist sie organi­siert? Welche Daten werden verar­beitet, für welche Zwecke, in welchem Umfang, mit welchen Betrof­fe­nen? Welche Risiken ergeben sich daraus konkret? Welche der Risiken werden im Zuge von Organi­sa­ti­ons-, Verfah­rens- und Technik­ge­stal­tung abgemil­dert oder verhin­dert – und welche bleiben trotz der erfor­der­li­chen organi­sa­to­ri­schen und techni­schen Maßnahmen beste­hen? Welche der Maßnahmen stellen dabei den Stand der Technik dar und welche fallen dahinter zurück? An welchen Stellen oder in Bezug auf welche Risiken gibt es deutliche Lücken in der Abdeckung durch techni­sche und organi­sa­to­ri­sche Maßnahmen, die es zu schließen gilt – und deren Schlie­ßung gesell­schaft­lich organi­siert und mögli­cher­weise auch finan­ziert werden sollte?

Poten­tiale für Daten­ver­a­r­beiter

Für Verant­wort­liche und Auftrags­ver­a­r­beiter ergibt sich das Inter­esse an einer Automa­ti­sie­rung des Daten­schutzes pragma­tisch aus der Bewäl­ti­gung der Komple­xität des Daten­schutz­rechts und seinen Anfor­de­run­gen. Insbe­son­dere für größere Organi­sa­ti­onen ist die Umset­zung des Daten­schutz­rechts oft nur ein weiteres Compliance-Projekt, das es zu managen gilt – mit allen Vor- und vor allem Nachteilen, die eine solche Ratio­na­li­sie­rung des Grund­rechts­schutzes in Organi­sa­ti­onen mit sich bringt (Waldman 2019).

Die DSGVO sieht für Verant­wort­liche und Auftrags­ver­a­r­beiter eine Vielzahl von Pflichten vor, deren Einhal­tung sie auch nachweisen müssen. Vielfach herrscht erheb­liche Uneinig­keit darüber, was Daten­ver­a­r­beiter genau tun müssen, um recht­mäßig zu handeln.[2] Grund­vor­aus­set­zung ist jedoch immer die Selbst­be­ob­ach­tung der eigenen Daten­ver­a­r­bei­tung. Erst die Bestands­auf­nahme erzeugt Trans­pa­renz und damit Prüfbar­keit. Sie ist notwen­dige Voraus­set­zung für eine beherrsch­bare IT. Auch die DSGVO verlangt – teilweise explizit (etwa unter den Voraus­set­zungen des Artikel 30), teilweise implizit – die Identi­fi­ka­tion und Dokumen­ta­tion der eigenen Verar­bei­tungs­tä­tig­kei­ten. Je nach Blick­winkel gehören dazu etwa die Daten und Daten­flüsse, die Prozesse, die verwen­deten IT-Sys­teme, die betei­ligten Akteure, die Rechts­grund­lagen, aber auch bereits ergrif­fene techni­sche und organi­sa­to­ri­sche Maßnahmen (TOM) und ein Lösch­kon­zept.

Softwa­re­ge­stützte Daten­schutz-­Ma­na­ge­ment­sys­teme könnten die Bestands­auf­nahme nicht nur erleich­tern, sondern auch für mehr Selbst­be­ob­ach­tung und -refle­xion bei den Daten­ver­a­r­bei­tern sorgen. Sie könnten durch Schnitt­stellen zu einge­setzten Anwen­dungen und deren Proto­kol­lie­rungs­funk­ti­onen die Daten und Daten­flüsse sowie die verwen­deten techni­schen Kompo­nenten automa­ti­siert erfas­sen. Die verbrei­teten Systeme bieten vor allem Vorlagen und Fragen­ka­ta­loge zur Dokumen­ta­tion der eigenen Prozesse und Systeme. Ihr Fokus liegt häufig auf der Erstel­lung der Verar­bei­tungs­ver­zeich­nisse. Sie verstärken damit die in der Praxis oft anzutref­fende Engfüh­rung der Bestands­auf­nahme auf das Führen eines Verzeich­nisses der Verar­bei­tungs­tä­tig­keiten nach Artikel 30.

Daten­schutz-­Ma­na­ge­ment­sys­teme könnten die Selbs­t­re­fle­xion des Verant­wort­li­chen fördern, wenn sie die dokumen­tierten Infor­ma­ti­onen aufbe­reiten und durch Prüfrou­tinen und -fragen auf begrün­dungs­be­dürf­tige Zusam­men­hänge hinweisen, etwa wenn ein Verein keine Mitglie­der­ver­wal­tung als Verfahren führt, die Berufung auf die eigenen „berech­tigten Inter­essen“ nicht begründet (Artikel 6 Abs. 1 lit. f) oder alle seine Verfahren auf einem einzigen IT-System betreibt. Einige Softwa­re­pro­dukte generieren bereits heute Auswer­tungen auf Basis der einge­tra­genen Infor­ma­ti­o­nen. Was hier erfasst und hervor­ge­hoben wird, hängt ohne Standar­di­sie­rung jedoch vom Daten­schutz­ver­ständnis des Herstel­lers ab.

Die Pflicht zur Bestands­auf­nahme geht über in die Pflicht des Verant­wort­li­chen, die durch die eigene Daten­ver­a­r­bei­tung erzeugten Risiken für die Betrof­fenen zu erkennen und durch techni­sche und organi­sa­to­ri­sche Maßnahmen zu beherr­schen (Artikel 24). Bei beson­ders riskanten Verfahren muss die Risiko­ana­lyse und -behand­lung in Form einer Daten­schutz-­Fol­ge­n­ab­schät­zung erfolgen (Artikel 35). Das wiederum setzt eine Vorab-Ri­si­ko­be­wer­tung bei allen Verfahren voraus, um überhaupt die riskanten unter ihnen identi­fi­zieren zu können (Wybitul 2017: 543 f.).

Der Nutzen standar­di­sierter Abfragen und Repor­tings bei der Risiko­be­wer­tung, die einige der verfüg­baren Systeme heute schon bieten, ist offen­kun­dig: Sie leiten den Verant­wort­li­chen an und erzeugen einheit­liche und damit vergleich­bare Risiko­ana­ly­sen. Jedoch ist die Risiko­ana­lyse eine der Anfor­de­rungen der DSGVO, über deren recht­mä­ßige Umset­zung die Meinungen häufig ausein­an­der­ge­hen. Ein Vergleich von drei gängigen Methoden zur Durch­füh­rung von Daten­schutz-­Fol­ge­n­ab­schät­zungen in Frank­reich, Großbri­tan­nien und Deutsch­land hat gezeigt, dass selbst die Aufsichts­be­hörden unter­schied­liche Auffas­sungen dazu vertreten, was überhaupt ein Daten­schutz­ri­siko darstellt, von welchen Angrei­fern sie ausgehen und wie man sie am besten identi­fi­ziert (Martin et al. 2020).

Softwa­re­ge­stützte Daten­schutz-­Ma­na­ge­ment­sys­teme müssten den Verant­wort­li­chen helfen, diese Unsicher­heiten zu bewäl­ti­gen. Das geht nur, wenn sie ihre Methode zur Risiko­ana­lyse ausweisen oder erklä­ren: Welche Angreifer werden betrach­tet? Welche Risiken werden betrachtet – die für alle Grund­rechte oder nur die Infor­ma­ti­ons­si­cher­heits- oder Priva­t­heits­ri­si­ken? Wie wird die Abschät­zung der Schwere und Eintritts­wahr­schein­lich­keit opera­ti­o­na­li­siert? Das ist nicht nur eine notwen­dige Voraus­set­zung für externe Prüfbar­keit, etwa durch Aufsichts­be­hörden, sondern auch um den Verant­wort­li­chen den Gegen­stand und die Grenzen der eigenen Risiko­ana­lyse zu verdeut­li­chen. Derzeit ist uns keine Software bekannt, die diese Anfor­de­rungen erfüllt.[3]

Nicht zuletzt müssten zukünf­tige Systeme sicher­stellen, dass sie die Risiko­ana­lyse nicht auf eine Check­liste reduzie­ren. Zwar ratio­na­li­sieren sie den Prüfungs­pro­zess, sie verleiten Verant­wort­liche aber auch dazu, abzuhaken statt abzuwägen und nur das Abhaken zu dokumen­tie­ren. Zukünf­tige Systeme müssten die Verant­wort­li­chen deshalb per Design zu Refle­xion, Abwägung und Begrün­dung zwingen. Durch Anlei­tung, Verein­heit­li­chung und maschi­nen­les­bare Dokumen­ta­tion könnten sie trotzdem ihr Ratio­na­li­sie­rungs­ver­spre­chen einlö­sen.

Werkzeuge für Aufsichts­be­hörden

Auch die Aufsichts­be­hörden würden von einer stärkeren Automa­ti­sie­rung des Daten­schutzes in ihrer Arbeit profi­tieren – und als Folge die Betrof­fenen, die Gesell­schaft, aber auch die Verant­wort­li­chen. Sie begleiten zwar die Digita­li­sie­rung von Verwal­tung und Wirtschaft, aber als Avant­garde ihrer eigenen Digita­li­sie­rung fallen sie bisher nicht auf. Die Frage, wie die Daten­schutz­be­hörden technisch arbeiten, ist weitge­hend unbekannt, denn auch die Verfah­rens­do­ku­men­ta­ti­onen der Aufsichts­be­hörden sind nicht öffent­lich. Vielleicht ist die Situa­tion ja besser als gedacht. Für eine umfas­sende Automa­ti­sie­rung des Daten­schutzes müssten die Aufsichts­be­hörden in die Fußstapfen der ersten Genera­tion von Daten­schüt­zer*innen treten und wie diese zu „begeis­terten Automa­ti­sie­rungs­be­für­wor­te­rinnen“ werden (Pohle 2018: 238).

Nahelie­gen­der­weise kann eine stärkere Digita­li­sie­rung des aufsichts­be­hörd­li­chen Daten­schutzes insbe­son­dere die Vermei­dung von Medien­brü­chen fördern, die derzeit noch einen nicht unerheb­li­chen Mehrauf­wand sowohl in der tägli­chen Arbeit der Behörden, aber auch in der Kommu­ni­ka­tion mit ihnen verur­sa­chen. Bislang beschränkt sich dies prima facie auf die Möglich­keit, die Berufung von betrieb­li­chen Daten­schutz­be­auf­tragten online zu melden – und nicht mehr nur per Brief oder Fax. Aber selbst hierbei handelt es bislang nur um ein Webfor­mu­lar.

Sinnvoll erschiene jedoch ein übergrei­fendes Gesamt­kon­zept, in dem es möglich wird, über definierte techni­sche Schnitt­stellen („Appli­ca­tion Program­ming Inter­faces“, APIs) softwa­re­ge­stützte Daten­schutz-­Ma­na­ge­ment­sys­teme an ein aufsichts­be­hörd­li­ches System anzubin­den. Neben Berufungs­mel­dungen könnte so die gesamte Bandbreite der Kommu­ni­ka­tion automa­ti­siert werden.

Ein gutes Beispiel sind Melde­pflichten zu Daten­schutz­ver­let­zungen nach Artikel 33 und 34 DGSVO. Die Meldung von Daten­schutz­ver­let­zungen stößt behör­den­in­tern Verfah­rens- und Dokumen­ta­ti­ons­schritte an. Oft erfor­dern sie auch die Kommu­ni­ka­ti­onen mit den Verant­wort­li­chen und den Betrof­fe­nen. Techni­sche Schnitt­stellen würden diese Prozesse erleich­tern und struk­tu­rie­ren. Zugleich würden die generierten Daten dabei helfen, umfas­sende Aussagen über Häufig­keit, Schwere und Auswir­kungen solcher Daten­schutz­ver­let­zungen, mögli­cher­weise auch statis­ti­sche Aussagen über beson­ders häufig betrof­fene Branchen, Systeme oder Verar­bei­tungs­tä­tig­keiten zu gewin­nen. Wenn die bei den Verant­wort­li­chen einge­setzten Systeme dann auch noch die techni­schen Proto­koll­da­teien mitlie­fern würden, dann könnten die Aufsichts­be­hörden darüber auch mehr, genauere und damit sicher hilfrei­chere Infor­ma­ti­onen über die Vorfälle erhalten, als dies derzeit bei manueller Meldung durch Verant­wort­liche der Fall ist. Für solch ein vertrau­ens­wür­diges Self-Reporting bedarf es aller­dings techni­scher Prüfanker in den betref­fenden Systemen, die an standar­di­sierten Schnitt­stellen integre Infor­ma­ti­onen über System­zu­stände liefern können – und diese müssen entwi­ckelt werden (Rost in Pohle/Knaut 2014: 270, Rn. 185).

Eine stärkere Digita­li­sie­rung des Daten­schutzes würde auch dabei helfen, die beschränkten Ressourcen der Aufsichts­be­hörden zielge­rich­teter einzu­setzen, weil die Automa­ti­sie­rung von Teilen der Aufsichts­tä­tig­keit Zeit schafft, sich den wesent­li­chen Problemen zu widmen und nicht im Klein-Klein der Forma­lismen zu verhar­ren. Die Aufsichts­be­hörden könnten Register für die Verzeich­nisse der Verar­bei­tungs­tä­tig­keiten (Artikel 30) und die Daten­schutz-­Fol­ge­n­ab­schät­zungen (Artikel 35) einrichten und betreiben, die dort in maschi­nen­les­barer Form hochge­laden werden müssen, um dann einfache Prüfungen, etwa auf Vollstän­dig­keit, Wider­spruchs­frei­heit oder auch fehlende Begrün­dungen bei einem Bezug auf das berech­tigte Inter­esse (Artikel 6 Abs. 1 lit. f), automa­ti­siert durch­führen zu können. Zugleich ließe sich damit eine Vergleich­bar­keits­grund­lage schaffen, etwa über Branchen, einge­setzte Systeme oder Organi­sa­ti­ons­größen, die bei der Identi­fi­zie­rung des Standes der Technik helfen, an dem sich Verar­beiter bei Auswahl und Einsatz von Daten­schutz- und Sicher­heits­maß­nahmen (Artikel 25 und 32) orien­tieren müssen, und damit gleich­zeitig auch als dessen Treiber wirken kann.

Wenn diese Infor­ma­ti­onen darüber hinaus in öffentlichen Regis­tern bereit­ge­stellt würden, ließen sie sich von den Verant­wort­li­chen auch mit ebenso öffent­li­chen wie standar­di­sierten Daten­schut­z­er­klä­rungen verknüpfen, aus denen die mögli­chen Grund­rechts­ri­siken klar erkennbar sind, die aber zugleich von Aufsichts­be­hörden oder Gruppen aus der Zivil­ge­sell­schaft mit weiteren Erklä­rungen oder Infor­ma­ti­onen versehen sind und somit die Allge­mein­ver­ständ­lich­keit noch einmal erhöhen.

Chancen für Betrof­fene

Die seit vielen Jahren disku­tierten und entwi­ckelten Hilfs­mittel für Betrof­fene basieren auf einer rechts­po­li­tisch fragwür­digen Verschie­bung des Daten­schutz­pro­blems: sie indivi­du­a­li­sieren Verant­wor­tung. Statt die Daten­ver­a­r­beiter zu zwingen, den Schutz der Grund­rechte der Betrof­fenen sicher­zu­stellen, zwingen die Vertre­ter*innen des sogenannten „Selbst­da­ten­schutzes“ (grund­le­gend: Roßnagel 1997) die Betrof­fenen, sich selbst um den Schutz ihrer Grund­rechte zu kümmern. Zu den Systemen, die dieser Idee folgen, gehören etwa Anony­mi­sie­rungs- und Verschlüs­se­lungs­sys­teme, Identi­täts­ma­na­ge­ment­sys­teme oder Selbst­be­ob­ach­tungs­sys­teme. Hierzu gehören etwa Apps auf Smart­phones, die Daten­flüsse anderer Apps mitpro­to­kol­lieren, in der Hoffnung, damit den „Daten­schatten“ (Anér 1972) der Betrof­fenen bei Verar­bei­tern offen­zu­le­gen. Solche Systeme können deshalb als geschei­tert gelten, da sie sich in der Praxis nicht breit durch­ge­setzt haben, aber auch praktisch kaum zu einer Verbes­se­rung des Grund­rechts­schutzes beitragen können. Sie ignorieren völlig, dass der Daten­schutz nicht nur indivi­du­elle Beein­träch­ti­gungen, sondern auch gesell­schaft­liche Folgen im Blick haben muss. Statt die Betrof­fenen zur digitalen Selbst­ver­tei­di­gung zu nötigen, müsste es um Ansätze gehen, die den Betrof­fenen helfen, die Daten­ver­a­r­beiter zu zwingen, ihrer Verant­wor­tung gerecht zu werden.

Eine den Betrof­fenen dienende Digita­li­sie­rung des Daten­schutzes müsste zualle­r­erst Werkzeuge zur Verfü­gung stellen, mit denen Betrof­fene ihre Rechte gegen­über den Verar­bei­tern wahrnehmen und durch­setzen können. Um dabei nicht von der „Gnade“ der Verar­beiter abhängig zu sein, bedarf es dazu in den Systemen der Verar­beiter techni­scher Schnitt­stellen, mit denen sich Assis­tenz­sys­teme der Betrof­fenen verbinden können, ohne dass diese Verbin­dung von den Verar­bei­tern kontrol­liert oder gar unter­bunden werden könnte. Über diese Schnitt­stellen würden die Systeme der Verar­beiter nicht nur „Auskunft“ über die beim Verar­beiter über die Betrof­fenen gespei­cherten perso­nen­be­zo­genen Daten erteilen, sondern vor allem auch über die Funkti­ons­weise des Systems selbst, also über die Zwecke, die Verar­bei­tungs­pro­zesse („Algo­rithmen“) und über den Stand der Schutz­maß­nah­men. Zugleich könnten die Betrof­fenen darüber auch ihre in der DSGVO statu­ierten Rechte wahrnehmen, etwa auf Korrektur, Wider­spruch oder Löschung. Ein Betrof­fe­nen-As­sis­tenz­system setzt demnach eine entspre­chende Technik­ge­stal­tung aufseiten des Verar­bei­ters voraus, der damit Eigen­schaften – und dazu gehören auch die damit erzeugten Grund­rechts­ri­siken – nicht einfach in einer Daten­schut­z­er­klä­rung behaupten, sondern über die gleichen Systeme abrufbar machen muss, die die Daten verar­beiten (für einen frühen Vorschlag für ein solches System, das aller­dings nie praktisch zum Einsatz kam, siehe Nguyen/­My­natt 2002). Dabei lässt sich die Integrität der Ausgaben des Systems aufseiten der Verar­beiter gegen­über den Betrof­fenen dann wieder von den Aufsichts­be­hörden überprü­fen.

Die Bereit­stel­lung von standar­di­sierten techni­schen Schnitt­stellen in den Daten­ver­a­r­bei­tungs­sys­temen der Verant­wort­li­chen würde zugleich verhin­dern, dass es zu einem Wildwuchs an Assis­tenz­sys­temen für Betrof­fene kommt, die dann weniger oder gar nicht einge­setzt werden, oder dass Daten­ver­a­r­beiter die Gestal­tung dieser Systeme kontrol­lie­ren. Eine solche Situa­tion gibt es heute schon bei Platt­for­men: Wenn die Betrof­fenen dort Accounts haben, können sie nach Anmel­dung auf einen Teil der über sie gespei­cherte Daten zugreifen und diese teilweise korri­gieren oder löschen. Jedoch folgen die Platt­formen jeweils eigenen Vorstel­lungen, welche Daten sie wie darstellen und welche Möglich­keiten sie dabei Betrof­fenen gewäh­ren. Standar­di­sierte techni­sche Schnitt­stellen würden es erlauben, dass es einzelne Assis­tenz­sys­teme bei den Betrof­fenen gibt, mit denen sich die Daten­ver­a­r­bei­tungs­praxis einer Vielzahl von Verar­bei­tern kontrol­lieren lässt (vgl. das Prinzip der „Unter­wa­chung“, Luhmann 1969/ 2016).

Ungeklärt ist aller­dings die Frage, wie mit techni­schen Werkzeugen auch Kollek­tiv­in­ter­essen wie die Verei­ni­gungs­frei­heit gestärkt werden könnten.

Der Weg zum Ziel

Automa­ti­sie­rung beein­flusst immer das Infor­ma­ti­ons- und Macht­gleich­ge­wicht einer Gesell­schaft und ihrer Teilbe­reiche (Stein­müller 1975: 510). Das gilt auch für die Automa­ti­sie­rung des Daten­schutzes selbst. Wie wir versucht haben zu zeigen, kann eine Automa­ti­sie­rung des Daten­schutzes dabei helfen, die Macht­ver­hält­nisse bei der Umset­zung des Daten­schutzes zugunsten der Gesell­schaft und der Betrof­fenen zu verschie­ben. Diese Poten­tiale sind jedoch keine lineare, selbs­t­er­fül­lende Erfolgs­ge­schichte. Sie müssen errungen werden. Zudem kann – und wird – es auch zu Verselbst­stän­di­gungen, Anoma­lien und nicht inten­dierten Neben­folgen bei der Automa­ti­sie­rung des Daten­schutzes kommen. Neben der bereits angedeu­teten Reduk­tion auf Selbst­da­ten­schutz und formale Compliance könnte eine Automa­ti­sie­rung des Daten­schutzes etwa auch zu einer nicht akzep­ta­blen Überwa­chung durch Aufsichts­be­hörden führen oder Missbrauch­spo­ten­tiale im unter­neh­me­ri­schen Bereich durch übergrif­fige Konkur­renten oder neue Monopo­listen schaf­fen. Aus unserer Sicht sind das jedoch keine Argumente gegen, sondern für eine wachsame Aushand­lung und Erpro­bung eines digita­li­sierten Daten­schut­zes. Wir schlagen vor, diesen Prozess durch Typisie­rung, Standar­di­sie­rung und die Betei­li­gung an Softwa­re­ent­wick­lungs­pro­jekten zu begin­nen.

Im Daten­schutz mangelt es bisher an Typisierung, vor allem in der Breite. Als Typisie­rung im Daten­schutz verstehen wir Anfor­de­rungs- und Umset­zungs­be­schrei­bungen für wieder­keh­rende Daten­ver­a­r­bei­tungen (z. B. beim Betrieb einer Website) in wieder­keh­renden Kontexten (z. B. bei Vereinen und kleinen Unter­nehmen) und unter Einsatz verbrei­teter Mittel (z. B. auf Basis von WordPress). Typisie­rung könnte auch in die Bereit­stel­lung von Konfi­gu­ra­ti­ons­da­teien münden, mit denen sich die Daten­schutz­kon­for­mität der Systeme auch für ressour­cen­schwache Verar­beiter wie Vereine herstellen lässt. Die Typisie­rung deckt konkrete Standard­fälle ab, aber auch nur diese. Sie bleibt damit immer unvoll­ständig, was sie von der stärker auf Verall­ge­mei­ne­rung zielenden Standar­di­sie­rung unter­schei­det. Die Typisie­rung kann der Standar­di­sie­rung, der Zerti­fi­zie­rung oder Codes of Conduct (Artikel 40) als erster Ordnungs­ver­such voraus­gehen oder sie zusätz­lich konkre­ti­sie­ren. Die bishe­rigen verein­zelten Versuche von Typisie­rungen, etwa Genera­toren für Daten­schut­z­er­klä­rungen, vorge­fer­tigte Verar­bei­tungs­ver­zeich­nisse oder Handrei­chungen von Aufsichts­be­hörden, sind ein Tropfen auf den heißen Stein.

Die Situa­tion im Bereich der Standardisierung ist kaum besser. Es gibt origi­näre Daten­schutz­stan­dards wie das Standard-­Da­ten­schutz­mo­dell, die bisher noch wenig verbreitet sind. Daneben existieren daten­schutz­re­le­vante ISO-Stan­dards, deren Verhältnis zur DSGVO nicht geklärt ist. Bei den Standar­di­sie­rungs­ver­fahren stellt sich zudem die Frage nach der Governance inklu­sive der demokra­ti­schen Kontrolle, also die Frage, wie die Standar­di­sie­rungs­or­ga­ni­sa­ti­onen eigent­lich ihre Entschei­dungen fällen und wer zu betei­ligen ist. In dieser Frage überzeugen klassi­sche Standar­di­sie­rungs­pro­zesse nicht immer. Oft betei­ligen sich nur die großen Marktak­teure, weil sie über ausrei­chend Personal, Finanzen und Know-How verfügen, was zu einem entspre­chenden Ungleich­ge­wicht in den Ergeb­nissen führen dürfte. Zudem sind viele Standards nicht frei zugäng­lich, was die gesell­schaft­liche Ausein­an­der­set­zung mit ihnen und nicht zuletzt auch die Integra­tion in freie Software verun­mög­licht. Es bedarf öffent­li­cher Förde­rung, um auch Akteuren aus der Zivil­ge­sell­schaft und der Wissen­schaft den Zugang zu Standar­di­sie­rungs­pro­zessen zu erleich­tern. Denn nicht zuletzt sind es am ehesten diese Akteure, die das gesell­schaft­liche Inter­esse an auffind­baren, zugäng­li­chen, inter­ope­ra­blen und wieder­ver­wend­baren Standards in diesen Prozessen vertreten können.

Um die Jahrtau­send­wende war in der Daten­schutz­de­batte kurzzeitig eine Forde­rung populär, die es verdient, als dezidiert politi­sche Forde­rung wieder erhoben zu werden: Daten­schutz­auf­sichts­be­hörden sollen sich aktiv in die Softwa­re­ent­wick­lung einbringen (Kessel 1998, Schartum 2001). Eine aktive Betei­li­gung an Softwa­re­ent­wick­lungs­pro­jekten würde es Aufsichts­be­hörden nicht nur erlauben, das Prinzip der „Programm­kon­trolle“ (Stein­müller et al. 1978: 91 f.) in die Praxis zu tragen, damit sicher­ge­stellt wird, dass Anwen­dungs­sys­teme nur genau das tun können, was sie tun sollen (Daten­schutz by Design, Artikel 25). Wie schon bei der Frage der Typisie­rung geht es bei einer solchen Betei­li­gung nicht darum, alles abzude­cken, also sich etwa in alle Softwa­re­ent­wick­lungen einzu­mi­schen. Ziel sollte eher sein, nach strate­gi­schen Krite­rien solche Projekte auszu­wählen, die als Treiber des Standes der Technik in möglichst großen Berei­chen über das einzelne Projekt hinaus wirken können – als „stra­tegic software develop­ment“ vergleichbar zu „stra­tegic litiga­tion“. Sinnvol­ler­weise sollte es sich dabei um Freie-­Soft­wa­re­-Pro­jekte handeln, um einer­seits einen breiten Einsatz in der Praxis und anderer­seits eine Weiter­nut­zung des in die Software geflos­senen Wissens im Rahmen weiterer Projekte zu ermög­li­chen. Die gleichen Krite­rien sollten zivil­ge­sell­schaft­liche Akteure leiten, wenn sie sich – was sie dringend sollten – in die Softwa­re­ent­wick­lung einbrin­gen.

Ende der infor­ma­ti­o­nellen Selbst­be­schrän­kung

Daten­schutz ist entstanden, um den gesell­schaft­li­chen Problemen von IT-Sys­temen gerecht zu werden. Was ist nahelie­gender, als dafür auch IT-Sys­teme zu benut­zen? Daten­schutz dient der Einhe­gung von Machtun­gleich­ge­wichten bei der automa­ti­sierten Infor­ma­ti­ons­ver­a­r­bei­tung. Ein Daten­schutz, der sich selbst der Automa­tion verwei­gert, droht das Machtun­gleich­ge­wicht, das er einzu­hegen sucht, noch zu vergrö­ßern. Der Aufruf zur Aneig­nung geeig­neter Produk­ti­ons­mittel gilt, wie wir gezeigt haben, nicht nur für die Aufsichts­be­hör­den. Auch die Daten­schüt­zer*innen bei den Verant­wort­li­chen, in der Zivil­ge­sell­schaft und in der Wissen­schaft müssen die Digita­li­sie­rung des Daten­schutzes zu ihrer Aufgabe machen.

JÖRG POHLE   Jahrgang 1979, Dr. rer. nat., Forschungs­pro­gramm­leiter „Daten, Akteure, Infra­s­truk­turen“ am Alexander von Humboldt Institut für Internet und Gesell­schaft, Berlin; jüngste Veröf­fent­li­chung: Daten­schutz-­Fol­ge­n­ab­schät­zung für die Corona-App (2020) mit K. Bock, C. R. Kühne, R. Mühlhoff, M. R. Ost und R. Rehak.

BENJAMIN BERGE­MANN   Jahrgang 1990, M. A., ehren­amt­li­cher Vorstand der Digitalen Gesell­schaft e. V., Berlin; engagiert sich für Grund­rechte in der digitalen Welt.

JAN SCHALLABÖCK   ist Rechts­an­walt mit Tätig­keits­schwer­punkt im Daten­schutz­recht.

Quellen

Anér, Kerstin 1972: Attack is the best defence; in: Manage­ment Infor­ma­tics, Jg. 1, H. 5, S. 179–180.

Commis­sion Natio­nale Infor­ma­tique et Liberté (CNIL) 2019: The open source PIA software helps to carry out data protec­tion impact assess­ment, abrufbar unter: https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment.

Diaz, Claudia; Gürses, Seda 2012: Under­stan­ding the lands­cape of privacy techno­lo­gies;in: Procee­dings of the Infor­ma­tion Security Summit 2012, S. 58–63.

Digitale Gesell­schaft 2020: Verbes­se­rung der DSGVO zum Schutz unserer Grund­rechte: Empfeh­lungen der Digitalen Gesell­schaft und des Verbrau­cher­zen­trale Bundes­ver­bands (vzbv), abrufbar unter: https://digitalegesellschaft.de/2020/05/verbesserung-der-dsgvo-zum-schutz-unserer-grundrechte/.

Kessel, Werner 1998: Koope­ra­tion der Daten­schutz­be­auf­tragten mit Hard- und Softwa­re­ent­wick­lern; in: Bäumler, Helmut (Hrsg.), „Der neue Daten­schutz“ – Daten­schutz in der Infor­ma­ti­ons­ge­sell­schaft von morgen, Neuwied, S. 182–189.

Klumpp, Dieter 2014: Aufhalt­samer Abstieg zur Hetero­nomie in einer Softwa­re­welt?; in: Garstka, Hansjürgen; Coy, Wolfgang (Hrsg.), Wovon – für wen – wozu. System­denken wider die Diktatur der Daten. Wilhelm Stein­müller zum Gedächtnis, Berlin, S. 267–284.

Luhmann, Niklas 1969: Unter­wa­chung. Oder die Kunst, Vorge­setzte zu lenken. Vortrag in Berlin 07.11.1969, Manuskript, posthum erschienen in: Der neue Chef. Heraus­ge­geben und mit einem Nachwort von Jürgen Kaube, Berlin 2016.

Martin, Nicholas et al. 2020: Methoden der Daten­schutz-­Fol­ge­n­ab­schät­zung: Welche Unter­schiede weisen die verschie­denen metho­di­schen Ansätze auf?; in: Daten­schutz und Daten­si­cher­heit, Jg. 44, H. 3, S. 154–160.

Nguyen, David H.; Mynatt, Elizabeth D. 2002: Privacy Mirrors: Under­stan­ding and Shaping Socio-­tech­nical Ubiqui­tous Compu­ting Systems. GVU Technical Report GIT-G­VU-02-16, Georgia Insti­tute of Techno­logy, Atlanta.

Pohle, Jörg 2015: Das Schei­tern von Daten­schutz by Design: Eine kurze Geschichte des Versa­gens; in: FIfF Kommu­ni­ka­tion, Jg. 32 , H. 2, S. 41–44.

Pohle, Jörg 2018: Daten­schutz und Technik­ge­stal­tung: Geschichte und Theorie des Daten­schutzes aus infor­ma­ti­scher Sicht und Folge­rungen für die Technik­ge­stal­tung. Disser­ta­tion, HU Berlin, abrufbar unter https://edoc.hu-berlin.de/handle/18452/19886.

Pohle, Jörg; Knaut, Andrea (Hrsg.) 2014: Funda­ti­ones I: Geschichte und Theorie des Daten­schutzes, Münster.

Privacy Company 2019: Open letter to the European Commis­sion: ten sugge­s­tions for impro­ve­ment of the GDPR, abrufbar unter: https://www.privacycompany.eu/blogpost-en/open-letter-to-the-european-commission-ten-suggestions-for-improvement-of-the-gdpr.

Roßnagel, Alexander 1997: Globale Daten­netze: Ohnmacht des Staates – Selbst­schutz der Bürger; in: Zeitschrift für Rechts­po­litik, Jg. 30, Heft 1, S. 26–30.

Roßnagel, Alexander 2018: DSGVO – was bewirkt sie fu?r den Daten­schutz?; in: vorgänge Zeitschrift für Bürger­rechte und Gesell­schafts­po­litik, Jg. 57, H. 221/222, S. 17–29.

Rost, Martin 2018: Risiken im Daten­schutz; in: vorgänge Zeitschrift für Bürger­rechte und Gesell­schafts­po­litik, Jg. 57, H. 221/222, S. 79–91.

Schartum, Dag Wiese 2001: Privacy Enhan­cing Employ­ment of ICT: Empowe­ring and Assis­ting Data Subjects; in: Inter­na­ti­onal Review of Law, Compu­ters & Techno­logy, Jg. 15, H. 2, S. 157–169.

Stein­müller, Wilhelm 1974: Daten­schutz­recht­liche Anfor­de­rungen an die Organi­sa­tion von Infor­ma­ti­ons­zen­tren; in: Schmitz, P. (Hrsg.), Inter­na­ti­o­nale Fachta­gung: Infor­ma­ti­ons­zen­tren in Wirtschaft und Verwal­tung, Berlin, S. 187–205.

Stein­müller, Wilhelm 1975: Automa­ti­ons­un­ter­stützte Infor­ma­ti­ons­sys­teme in privaten und öffent­li­chen Verwal­tun­gen: Bruch­stücke einer alter­na­tiven Theorie des Daten­zeit­al­ters; in: Leviathan, Jg. 3, H. 4, S. 508–43.

Stein­müller, Wilhelm 1976: Infor­ma­ti­ons­recht und Infor­ma­ti­ons­po­litik; in: Stein­müller, Wilhelm (Hrsg.), Infor­ma­ti­ons­recht und Infor­ma­ti­ons­po­litik, München, S. 1–20.

Stein­müller, Wilhelm 1979: Legal Problems of Computer Networks: A Metho­do­lo­gical Survey; in: Computer Networks, Jg. 3, S. 187–198.

Stein­müller, Wilhelm et al. 1971: Grund­fragen des Daten­schut­zes. Gutachten im Auftrag des Bundes­mi­nis­te­riums des Innern, BT-Drs. VI/3826, Anlage 1.

Stein­müller, Wilhelm et al. 1978: Daten­schutz bei riskanten Syste­men. Eine Konzep­tion entwi­ckelt am Beispiel eines medizi­ni­schen Infor­ma­ti­ons­sys­tems, Berlin.

Waldman, Ari Ezra 2020: Privacy Law’s False Promise; in: Washington Univer­sity Law Review, Jg. 97, H. 2, S. 773–834.

Wybitul, Tim (Hrsg.) 2017: EU-Da­ten­schutz-­Grund­ver­ord­nung: Handbuch, Frank­furt am Main.

Anmerkungen

1 Die Autoren danken Mareike Lisker für die Unter­stüt­zung bei der Recherche und der Endre­dak­tion des Textes.

2 Zur Rechts­un­si­cher­heit (und dort auch zur Unter­kom­ple­xität der DSGVO) statt vieler insbe­son­dere Roßnagel (2018: 23 ff.).

3 Einzig die PIA-Soft­ware der franzö­si­schen Daten­schutz­auf­sichts­be­hörde folgt einer offen­ge­legten Methode (CNIL 2019).

Dateien