EDSA: 2. Ver­si­on der Leit­li­ni­en zu Pri­va­cy by Design und Pri­va­cy by Default / Anmer­kun­gen zur Syste­ma­tik

Der EDSA hat eine neue Ver­si­on 2.0 der bereits 2019 erschie­nen Leit­li­ni­en zu Pri­va­cy by Design und Pri­va­cy by Default ver­öf­fent­licht. Eine Ver­gleichs­fas­sung (Del­ta­view, PDF) fin­det sich hier.

Die Leit­li­ni­en sind in vie­len Punk­ten nach wie vor recht luf­tig, ent­hal­ten aber Hin­wei­se, auf wel­che Wei­se die Ein­hal­tung der Bear­bei­tungs­grund­sät­ze kon­kret sicher­ge­stellt wer­den kann.

Was die Leit­li­ni­en nicht aus­drück­lich erläu­tern, ist das Ver­hält­nis von Pri­va­cy by Design, Pri­va­cy by Default, Daten­si­cher­heit, Accoun­ta­bi­li­ty und Fol­gen­ab­schät­zun­gen. Nach mei­ner Ansicht lässt sich die­ses Ver­hält­nis am ein­fach­sten wie folgt dar­stel­len:

  • Pri­va­cy by Design ist der über­grei­fen­de Grund­satz und Aus­gangs­punkt der Betrach­tung. Im Wesent­li­chen ver­langt die­ser Grund­satz, dass der Ver­ant­wort­li­che sich früh­zei­tig Gedan­ken macht, wie er die Ein­hal­tung des Daten­schut­zes – beson­ders die Bear­bei­tungs­grund­sät­ze, aber auch die wei­te­ren Pflich­ten wie z.B. die Erfül­lung der Betrof­fe­nen­rech­te – über den gesam­ten Daten-Life­cy­cle sicher­stellt (EDSA: “Con­trol­lers need to imple­ment the princi­ples to achie­ve DPbDD. The­se princi­ples inclu­de: trans­pa­ren­cy, law­ful­ness, fair­ness, pur­po­se limi­ta­ti­on, data mini­mi­sa­ti­on, accu­ra­cy, sto­rage limi­ta­ti­on, inte­gri­ty and con­fi­dentia­li­ty, and accoun­ta­bi­li­ty”). In die­sem Sin­ne ist Pri­va­cy by Design weni­ger ein Bear­bei­tungs­grund­satz, son­dern ein Meta­grund­satz, die auf die Ver­wirk­li­chung der mate­ri­el­len Grund­sät­ze zielt und im die­sem Sin­ne den System­da­ten­schutz sicher­stellt. Wel­che Anfor­de­run­gen – d.h. wel­che tech­ni­schen und/oder orga­ni­sa­to­ri­schen Anfor­de­run­gen – sich dar­aus kon­kret erge­ben, hängt vom kon­kre­ten Vor­ha­ben ab, aber jeden­falls muss der Ver­ant­wort­li­che die Risi­ken für die Betrof­fe­nen abschät­zen und sich Gedan­ken machen, wie er sie ange­mes­sen miti­gie­ren kann.
  • Der Grund­satz der Daten­si­cher­heit über­schnei­det sich stark mit dem Grund­satz von Pri­va­cy by Design, weil die Daten­si­cher­heit – als all­ge­mei­ner Grund­satz ver­stan­den – die tech­ni­sche und orga­ni­sa­to­ri­sche Absi­che­rung des Daten­schut­zes ins­ge­samt ver­langt. In die­sem Sin­ne ist er nicht auf die Ein­hal­tung des tech­ni­schen Daten­schut­zes im Sin­ne der IT Secu­ri­ty beschränkt. Die ent­spre­chen­de Grund­la­gen­norm ist Art. 24 DSGVO. Die­se wird dadurch kon­kre­ti­siert, dass Art. 5 Abs. 1 lit. f und Art. 32 DSGVO bestimm­te Schutz­zie­le und Mass­nah­men auf­greift, die in erster Linie den tech­ni­schen Daten­schutz im Auge haben, also die klas­si­schen Schutz­zie­le der Inte­gri­tät und Ver­trau­lich­keit (neben der Ver­füg­bar­keit und je nach Sicht­wei­se wei­te­rer Schutz­zie­le). Die­se enge­re Daten­si­cher­heit (IT Safe­ty und IT Secu­ri­ty) ist ein Teil­be­reich des all­ge­mei­nen Daten­schut­zes und daher im Rah­men der Pri­va­cy by Design mit­zu­be­rück­sich­ti­gen.
  • Der Grund­satz von Pri­va­cy by Default sei­ner­seits ist eine Aus­prä­gung des Ver­hält­nis­mä­ssig­keits­grund­sat­zes, oder viel­mehr eine Kon­kre­ti­sie­rung die­ses Grund­sat­zes spe­zi­fisch im Zusam­men­hang mit “Vor­ein­stel­lun­gen”. Er ist auf letz­te­re beschränkt und ver­langt daher bspw. nicht, Ein­wil­li­gun­gen ein­zu­ho­len, die nach Art. 6, 9 oder 44 ff. DSGVO nicht erfor­der­lich sind. Wie die ande­ren Bear­bei­tungs­grund­sät­ze ist sei­ne Ein­hal­tung unter dem Titel von Pri­va­cy by Design zu pla­nen und ange­mes­sen sicher­zu­stel­len.
  • Unter dem Titel der Accoun­ta­bi­li­ty  muss der Ver­ant­wort­li­che sei­ne Über­le­gun­gen und Ent­schei­dun­gen im Sin­ne einer selb­stän­di­gen Pflicht ange­mes­sen doku­men­tie­ren (in Bezug auf Sicher­heits­mass­nah­men z.B. durch pas­sen­de Metri­ken, KPIs, wie der EDSA in den Gui­de­li­nes anmerkt). Je höher die Risi­ken, desto höher die mate­ri­el­len Anfor­de­run­gen an den Ver­ant­wort­li­chen (und ggf. den Auf­trags­be­ar­bei­ter) und desto höher auch die Accoun­ta­bi­li­ty-Anfor­de­run­gen.
  • Eine DSFA ist vor die­sem Hin­ter­grund kei­ne neue oder ande­re Pflicht, son­dern in erster Linie eine durch hohe Brut­to­ri­si­ken aus­ge­lö­ste For­ma­li­sie­rung der im Rah­men von Pri­va­cy by Design ohne­hin bestehen­den Pflicht, Risi­ken zu beur­tei­len, ihre Miti­gie­rung zu pla­nen und bei­des zu doku­men­tie­ren. So ver­stan­den ist die Pflicht zur Durch­füh­rung der DSFA in erster Linie eine Kon­kre­ti­sie­rung des Accoun­ta­bi­li­ty-Grund­sat­zes. Eigen­stän­dig ist dem­nach fast nur die Pflicht, die Daten­schutz­be­hör­den ggf. – bei hohen Net­to­ri­si­ken – zu infor­mie­ren. So betrach­tet dient die Durch­füh­rung einer DSFA in vie­len Fäl­len eigent­lich nur der an sich ohne­hin erfor­der­li­chen Doku­men­ta­ti­on des all­ge­mei­ne­ren Risi­ko­ma­nage­ments. Die frei­wil­li­ge Durch­füh­rung einer DSFA kann daher häu­fig sinn­voll sein (wobei die Frei­wil­lig­keit aus­drück­lich fest­ge­hal­ten wer­den soll­te, z.B. als Teil eines ent­spre­chen­den For­mu­lars). Im Ergeb­nis besteht des­halb zwi­schen dem all­ge­mei­nen Vor­ge­hen und einer DSFA weni­ger ein kate­go­riel­ler Unter­schied, son­dern eher ein Unter­schied bei der Tie­fe und beim Detal­lie­rungs­grad der Durch­füh­rung und Doku­men­ta­ti­on des Risi­ko­ma­nage­ments (abge­se­hen von der erwähn­ten Mel­de­pflicht ggü. den Behör­den, die nach dem revDSG aber ent­fal­len kann, wenn ein Daten­schutz­be­ra­ter bestellt wur­de).