Privacy by Design und Privacy by Default.

Zwei Pflichten, nicht eine

Privacy by Design und Privacy by Default sind als eine einzige Pflicht der DSGVO formuliert, verlangen aber zwei verschiedene Dinge, und Praktiker geraten in Schwierigkeiten, wenn sie beide zusammenwerfen. By Design bedeutet, dass Datenschutzvorkehrungen bereits in der Anforderungsphase in ein System eingebaut werden, bevor eine Zeile Code geschrieben oder ein Anbieter ausgewählt wird, statt nachträglich angesetzt zu werden, sobald die Auskunftsersuchen der betroffenen Personen eintreffen.

By Default bedeutet, dass das System sich bereits in seiner schützendsten Einstellung befindet, wenn ein Nutzer nichts unternimmt: die engste Datenerhebung, die kürzeste Speicherung, die strikteste Weitergabe. Das eine betrifft, wie Sie bauen; das andere, was das System am ersten Tag ohne jede Konfiguration tut.

Die Unterscheidung ist wichtig, weil ein Team die eine Pflicht erfüllen und die andere verfehlen kann. Sie können eine gründliche Designprüfung durchführen, eine DSFA dokumentieren und dennoch ein Produkt ausliefern, dessen Standardschalter allesamt auf maximale Weitergabe gesetzt sind, weil das Wachstumsteam genau das verlangt hat. Dieses Produkt ist Privacy by Design, aber nicht by Default, und es ist nicht konform. Auch der umgekehrte Fall kommt vor: Eine vorsichtige Standardeinstellung, die nachträglich auf ein nie bewertetes System gesetzt wird, lässt den Verantwortlichen außerstande, nachzuweisen, wie die Entscheidung getroffen wurde.

Was sich dadurch in der Praxis tatsächlich ändert

Die praktische Verschiebung besteht darin, den Datenschutz nach vorn zu verlagern. Statt dass die Rechtsabteilung eine fertige Funktion prüft, werden Datenschutzanforderungen zu Designvorgaben, die Entwicklung und Produkt vom ersten Sprint an mittragen. Datenminimierung ist kein Schlagwort mehr, sondern wird zur Frage an jedes Feld jedes Formulars: Brauchen wir das, um den Dienst zu erbringen, und wenn nicht, warum ist es da. Die Zweckbindung wird zu einer Einschränkung dafür, wofür ein Datenbestand später weiterverwendet werden darf. Die Speicherung wird zu einem standardmäßigen Zeitplan, den das System durchsetzt, und nicht zu einer manuellen Bereinigung, an die niemand denkt.

• Erheben Sie die minimale Anzahl an Feldern, die der Dienst wirklich benötigt, und begründen Sie jedes einzelne.
• Legen Sie Speicherfristen als durchgesetzte Standardwerte fest, mit automatischer Löschung oder Anonymisierung bei deren Ablauf.
• Stellen Sie die Standardeinstellungen für Weitergabe, Sichtbarkeit und Profiling auf die am wenigsten freizügige Option ein und überlassen Sie es dem Nutzer, mehr zu erlauben.
• Setzen Sie Pseudonymisierung und Verschlüsselung als architektonische Standardentscheidungen ein, nicht als Ausnahmen.
• Begrenzen Sie den Zugriff auf personenbezogene Daten nach Zweck, sodass ein System nur das offenlegt, was eine bestimmte Funktion erfordert.

Wie es sich zu benachbarten Konzepten verhält

Privacy by Design lässt sich am leichtesten im Kontrast zu dem verstehen, womit man es verwechselt. Es ist nicht dasselbe wie eine DSFA, die ein Nachweisstück dafür ist, dass die umfassendere Pflicht für eine bestimmte Verarbeitungstätigkeit mit höherem Risiko erfüllt wurde. Es ist nicht Security by Design, die Daten vor Angreifern schützt, unabhängig davon, ob diese Daten überhaupt hätten erhoben werden dürfen; Privacy by Design setzt einen Schritt früher an, indem es die Erhebung selbst hinterfragt. Und es ist kein einmaliges Tor. Da Systeme sich weiterentwickeln, ist die Pflicht fortlaufend: Jede neue Funktion, Integration oder jeder neue Datenfluss wirft dieselben Fragen nach Minimierung, Zweck und Standardeinstellungen erneut auf.

In einem ausgereiften Programm wird Privacy by Design zu einer im Entwicklungslebenszyklus verankerten Gewohnheit statt zu einem Kontrollpunkt in der Hand der Rechtsabteilung. Produkt und Entwicklung werfen die Fragen selbst auf, die DSFA wird automatisch ausgelöst, wenn die Verarbeitung eine Risikoschwelle überschreitet, und die Standardkonfiguration wird als Teil des Releases überprüft, statt in der Produktion entdeckt zu werden. Das ist der Unterschied zwischen einer Organisation, die das Prinzip nachweisen kann, und einer, die es lediglich behauptet.