Rz. 42
Die Zielsetzung dieses Werkes liegt in der Unterstützung des Lesers im Rahmen der praktischen Handhabung des Datenschutzrechtes in der täglichen Beratungs- und Umsetzungspraxis, gleichwohl kann man sich dem Themenkomplex des "data privacy by design" auch praktisch nicht nähern, ohne die historischen Grundlagen des dahinter stehenden Konzeptes näher zu beleuchten. Der europäische Gesetzgeber tut nicht viel dafür – sowohl in Art. 25 DSGVO, als auch in den hierauf bezogenen Erwägungsgründen -, dem Begriff eine genaue Kontur zu verleihen. Vielmehr wird der Begriff als "bekannt" vorausgesetzt. Dies enttäuscht anlässlich des Stellenwertes, den der Gesetzgeber den Regelungen in Art. 25 DSGVO beigemessen hat und macht eine intensivere Befassung mit dem Konzept des data protection by design erforderlich.
Rz. 43
Der Begriff "data privacy by design" wird auf die wissenschaftlichen Arbeiten der langjährigen Informationsfreiheits- und Datenschutzbeauftragten der kanadischen Provinz Ontario, Ann Cavoukian, die zwischenzeitlich als Executive Director of the Privacy and Big Data Institute an der kanadischen Ryerson University tätig ist, zurückgeführt.
Tatsächlich, so kann es in der siebenteiligen Abhandlung "Privacy by Design: Vom Recht zum Code" von Schulzki-Haddouti nachgelesen werden, wurde der Begriff wohl von einer kanadischen IT-Firma im Jahre 2000 geprägt und von Cavoukian lediglich übernommen, fortentwickelt und vor allem in die internationale Datenschutzdiskussion eingeführt.
Rz. 44
Cavoukian vertritt im Zusammenhang mit ihrem Privacy by Desgin (PbD)-Ansatz insgesamt sieben Kernthesen:
| 1. |
Proactive not Reactive; Preventative not Remedial |
| 2. |
Privacy as the Default |
| 3. |
Privacy Embedded into Design |
| 4. |
Full Functionality—Positive-Sum, not Zero-Sum |
| 5. |
End-to-End Lifecycle Protection |
| 6. |
Visibility and Transparency |
| 7. |
Respect for User Privacy |
Rz. 45
PbD umfasst in diesem Sinne sowohl software-technische Maßnahmen in Bezug auf die (internen) Verarbeitungsvorgänge des Verantwortlichen, als auch Maßnahmen zur Schaffung von effektiven Kontrollmöglichkeiten der betroffenen Person, wobei letztere im Europäischen Kontext wohl eher im Rahmen des – ebenfalls in Art. 25 DSGVO beschriebenen – Grundsatzes des "Data Privacy by Default" Geltung erlangen.
Rz. 46
Bezogen auf die vom Verantwortlichen zu treffenden Maßnahmen beschreibt PbD einen proaktiven Ansatz und sieht in der Beachtung von Datenschutzfragen bereits in der Planungsphase von neuen IT-Projekten einen entscheidenden Vorteil gegenüber dem bislang maßgeblich verfolgten sanktionierenden Datenschutz. Gerade weil die automatisierte Verarbeitung immer mehr an Bedeutung gewinnt, ist es entscheidend, dass bereits in der Planungsphase Risiken ermittelt und angemessene Schutzmaßnahmen ergriffen werden.
Rz. 47
Ein anschauliches Beispiel der (an die vom Verantwortlichen eingesetzte Softwareumgebung und damit auch an die Softwarehersteller gestellten) Rahmenbedingungen liefert ein Beitrag von Cavoukian/Jonas aus dem Jahre 2012 zur Umsetzung von PbD-Technologien in Big Data Anwendungen. Der Beitrag beschreibt die von Jonas, Chief Scientist of the IBM Entity Analytics, bereits im Jahre 2008 begonnene Entwicklung eines "sinnstiftenden" Softwaredesigns, das dabei helfen soll, schnellere und zugleich aus Sicht des Datenschutzes bessere Entscheidungen im Rahmen der Verarbeitung von Daten zu treffen. PbD folgt hier dem Prinzip, dass sich die Daten selbst finden und die für einen Verarbeitungsschritt relevanten Informationen erst dann den Systemnutzer "finden" ("the data finds the data, and the relevance finds the unser"). Das von Jonas entwickelte PbD-System folgt dabei sieben Grundprinzipien:
Rz. 48
| 1) |
"Full Attribution": Jedes Datum wird im System so abgelegt, dass jederzeit bestimmt werden kann, von wo und wann es in das System gelangte. |
| 2) |
"Data Tethering": Jede Veränderung eines Datums im Hauptsystem führt zwangsläufig zu einer Änderung des Datums in jedem Unter- und Folgesystem, welches das Datum verwendet. |
| 3) |
Analytics on anonymized Data: Um die Risiken, die mit der Verarbeitung von Daten einhergehen zu vermindern, werden – überall dort, wo es technisch möglich ist – Anonymisierungs- oder Pseudonymisierungstechniken eingesetzt. Jedes Datenfeld innerhalb eines Systems kann administrativ – auch für einzelne Verarbeitungsschritte – anonymisiert oder pseudonymisiert werden. |
| 4) |
Tamper Resistant Audit Logs: Jeder Zugriff auf ein Datum durch einen Nutzer im System wird durch das System manipulationssicher (anhand des Datums) protokolliert und erfasst. Auch Administratoren des Systems können nicht "unbemerkt" auf Daten zugreifen. |
| 5) |
False Negative Favoring Methods: Das System sollte so eingestellt sein, dass es eher dazu tendiert, Daten nicht zu verarbeiten, als sie zu verarbeiten. |
| 6) |
Self Correcting False Positives: Das System sollte so eingestellt sein, dass es fälschlicherweise zum Gegenstand einer Verarbeitung gem... |