• Accueil 
  • -
  • Sécu­ri­té et résilience 
  • -
  • EDSA : 2e ver­si­on des lignes direc­tri­ces sur le respect de la vie pri­vée dès la con­cep­ti­on et le respect de la vie pri­vée par défaut / Remar­ques sur la systématique 

EDSA : 2e ver­si­on des lignes direc­tri­ces sur le respect de la vie pri­vée dès la con­cep­ti­on et le respect de la vie pri­vée par défaut / Remar­ques sur la systématique

L’EDSA a publié une nou­vel­le ver­si­on 2.0 de l’ou­til d’ai­de à la décis­i­on déjà exi­stant. paru en 2019 publié des lignes direc­tri­ces sur le respect de la vie pri­vée dès la con­cep­ti­on et le respect de la vie pri­vée par défaut. Une ver­si­on com­pa­ra­ti­ve (Del­ta­view, PDF) est dis­po­ni­ble à l’adres­se sui­van­te ici.

Les lignes direc­tri­ces restent assez légè­res sur de nombreux points, mais elles con­ti­en­nent des indi­ca­ti­ons sur la maniè­re dont le respect des prin­cipes de trai­te­ment peut être assu­ré concrètement.

Ce que les lignes direc­tri­ces n’ex­pli­quent pas expli­ci­te­ment, c’est la rela­ti­on ent­re le respect de la vie pri­vée dès la con­cep­ti­on, le respect de la vie pri­vée par défaut, la sécu­ri­té des don­nées, la responsa­bi­li­té et les ana­ly­ses d’im­pact. Selon moi, la maniè­re la plus simp­le de pré­sen­ter cet­te rela­ti­on est la suivante :

  • Respect de la vie pri­vée dès la con­cep­ti­on est le prin­ci­pe géné­ral et le point de départ de la réfle­xi­on. Pour l’e­s­sen­tiel, ce prin­ci­pe exi­ge que le responsable réflé­chis­se suf­fi­sam­ment tôt à la maniè­re de garan­tir le respect de la pro­tec­tion des don­nées – en par­ti­cu­lier les prin­cipes de trai­te­ment, mais aus­si les aut­res obli­ga­ti­ons tel­les que le respect des droits des per­son­nes con­cer­nées – tout au long du cycle de vie des don­nées (EDSA : “Con­trol­lers need to imple­ment the prin­ci­ples to achie­ve DPbDD. Ces prin­cipes com­pren­nent : la trans­pa­rence, la léga­li­té, l’é­qui­té, la limi­ta­ti­on des fina­li­tés, la mini­mi­sa­ti­on des don­nées, l’e­xac­ti­tu­de, la limi­ta­ti­on du stocka­ge, l’in­té­gri­té et la con­fi­den­tia­li­té, et la responsa­bi­li­té”). Dans ce sens, le respect de la vie pri­vée dès la con­cep­ti­on n’est pas tant un prin­ci­pe de trai­te­ment qu’un méta­prin­ci­pe qui vise à la réa­li­sa­ti­on des prin­cipes maté­ri­els et qui assu­re en ce sens la pro­tec­tion des don­nées du système. Les exi­gen­ces – c’est-à-dire les exi­gen­ces tech­ni­ques et/ou orga­ni­sa­ti­on­nel­les – qui en décou­lent con­crè­te­ment dépen­dent du pro­jet con­cret, mais en tout état de cau­se, le responsable doit éva­luer les ris­ques pour les per­son­nes con­cer­nées et réflé­chir à la maniè­re de les atté­nuer de maniè­re adéquate.
  • Le prin­ci­pe de la Sécu­ri­té des don­nées se recou­pe for­te­ment avec le prin­ci­pe de Pri­va­cy by Design, car la sécu­ri­té des don­nées – com­pri­se com­me un prin­ci­pe géné­ral – exi­ge la sécu­ri­sa­ti­on tech­ni­que et orga­ni­sa­ti­on­nel­le de la pro­tec­tion des don­nées dans son ensem­ble. En ce sens, il ne se limi­te pas au respect de la pro­tec­tion des don­nées tech­ni­ques au sens de la sécu­ri­té infor­ma­tique. La nor­me de base cor­re­spond­an­te est l’ar­tic­le 24 du RGPD. Cel­le-ci est con­cré­ti­sée par le fait que l’art. 5, al. 1, let. f et l’art. 32 RGPD repren­nent cer­ta­ins objec­tifs de pro­tec­tion et mesu­res qui visent en pre­mier lieu la pro­tec­tion tech­ni­que des don­nées, c’est-à-dire les objec­tifs de pro­tec­tion clas­si­ques de l’in­té­gri­té et de la con­fi­den­tia­li­té (en plus de la dis­po­ni­bi­li­té et, selon le point de vue, d’aut­res objec­tifs de pro­tec­tion). Cet­te sécu­ri­té plus étroi­te des don­nées (IT Safe­ty et IT Secu­ri­ty) est un domaine par­tiel de la pro­tec­tion géné­ra­le des don­nées et doit donc être pri­se en comp­te dans le cad­re de la Pri­va­cy by Design.
  • Le prin­ci­pe de Pro­tec­tion de la vie pri­vée par défaut est quant à lui une expres­si­on du prin­ci­pe de pro­por­ti­on­na­li­té, ou plutôt une con­cré­ti­sa­ti­on de ce prin­ci­pe, spé­ci­fi­quement dans le con­tex­te des “pré­rég­la­ges”. Il est limi­té à ces der­niè­res et n’e­xi­ge donc pas, par exemp­le, de recu­eil­lir des con­sen­te­ments qui ne sont pas néces­saires en ver­tu des artic­les 6, 9 ou 44 et sui­vants du RGPD. RGPD ne sont pas néces­saires. Com­me les aut­res prin­cipes de trai­te­ment, son respect doit être pla­ni­fié et assu­ré de maniè­re adé­qua­te dans le cad­re du respect de la vie pri­vée dès la conception.
  • Sous le tit­re de la Responsa­bi­li­té  le responsable doit docu­men­ter ses réfle­xi­ons et ses décis­i­ons de maniè­re appro­priée, au sens d’u­ne obli­ga­ti­on auto­no­me (en ce qui con­cer­ne les mesu­res de sécu­ri­té, par exemp­le par des métri­ques appro­priées, des indi­ca­teurs clés de per­for­mance, com­me le note l’ED­SA dans ses lignes direc­tri­ces). Plus les ris­ques sont éle­vés, plus les exi­gen­ces maté­ri­el­les impo­sées au responsable (et, le cas échéant, au sous-trai­tant) sont importan­tes et plus les exi­gen­ces en matiè­re de responsa­bi­li­té sont éga­le­ment élevées.
  • Une DSFA n’est pas, dans ce con­tex­te, une obli­ga­ti­on nou­vel­le ou dif­fé­ren­te, mais avant tout une for­ma­li­sa­ti­on, déclen­chée par des ris­ques bruts éle­vés, de l’ob­li­ga­ti­on exi­stant de tou­te façon dans le cad­re du Pri­va­cy by Design d’éva­luer les ris­ques, de pla­ni­fier leur atté­nua­ti­on et de docu­men­ter les deux. Ain­si com­pri­se, l’ob­li­ga­ti­on de pro­cé­der à la DSFA est en pre­mier lieu une con­cré­ti­sa­ti­on du prin­ci­pe de responsa­bi­li­té. Par con­sé­quent, seu­le l’ob­li­ga­ti­on d’in­for­mer les auto­ri­tés de pro­tec­tion des don­nées, le cas échéant, en cas de ris­ques nets éle­vés, est pres­que indé­pen­dan­te. De ce point de vue, la réa­li­sa­ti­on d’u­ne AIPD ne sert en fait, dans de nombreux cas, qu’à docu­men­ter la gesti­on des ris­ques plus géné­ra­le, qui est de tou­te façon néces­saire. La réa­li­sa­ti­on volon­tai­re d’u­ne DSFA peut donc sou­vent s’a­vé­rer uti­le (mais le carac­tère volon­tai­re doit être expli­ci­te­ment men­ti­onné, par exemp­le dans le cad­re d’un for­mu­lai­re appro­prié). En fin de comp­te, il n’y a donc pas tant une dif­fé­rence de caté­go­rie ent­re la pro­cé­du­re géné­ra­le et la DSFA qu’u­ne dif­fé­rence dans la pro­fon­deur et le degré de détail de la mise en œuvre et de la docu­men­ta­ti­on de la gesti­on des ris­ques (abstrac­tion fai­te de l’ob­li­ga­ti­on de noti­fi­ca­ti­on aux auto­ri­tés men­ti­onnée ci-des­sus, qui peut tou­te­fois être sup­p­ri­mée en ver­tu de la loi révi­sée sur la pro­tec­tion des don­nées si un con­seil­ler à la pro­tec­tion des don­nées a été désigné).