RGPD : un an après
Lors du prochain Congrès National de la Sécurité des SI de Santé de l’APSSIS, qui se tiendra au Mans du 2 au 4 avril 2019, Cédric CARTAU* délivrera une conférence intitulée « RGPD : un an après ». Cette intervention donnera suite à celle réalisée cette année, pendant le 6ème Congrès National, qui avait permis de présenter les travaux du CHU de Nantes.
Dans le but d’alimenter la réflexion sur la mise en œuvre opérationnelle du RGPD, Cédric nous propose une publication originale, une analyse emprunte d’un premier recul et pose une première série de diagnostics.
« Le RGPD un an après » : Un article original de Cédric CARTAU, Vice-Président de l’APSSIS, en préambule à la Conférence qu’il délivrera lors du 7ème Congrès National de la SSI Santé.
Le Règlement Général de Protection des Données introduit un changement majeur de paradigme dans la protection des traitements de données personnelles, puisque l’on passe d’une logique administrative à une approche par le risque. Il ne s’agit plus simplement de déclarer un traitement pour qu’il soit conforme, il s’agit de procéder à une appréciation des risques que l’on fait encourir aux personnes dont les données sont traitées (et le RGPD ne dit pas comment faire cette appréciation de risques), réduire les risques que l’on estime majeurs (et le RGPD ne dit pas lesquels) et procéder à une réévaluation périodique du dispositif (et, bien entendu, le RGPD ne dit pas comment). En d’autres termes, il s’agit d’une totale inversion de la charge de la preuve. Avec la réglementation précédente, une fois rempli l’imprimé, il appartenait à la CNIL de démontrer que le traitement était non conforme. Avec le RGPD c’est l’inverse : il appartient au responsable de traitement (RT) de démontrer qu’il a suivi le règlement dans l’esprit sinon à la lettre et qu’il a, en toute bonne foi, pris les mesures nécessaires pour sécuriser le traitement.
L’entropie pour première approche
Tous les délégués à la protection des données (DPD ou DPO selon l’acronyme anglais) ont abordé le RGPD peu ou prou de la même manière : par les fondamentaux. C’est ainsi que les consultants, les juristes et les DPO ont tout de suite évoqué les concepts de Privacy By Design, le registre des traitements (qui existait déjà du temps des Correspondants Informatique et Liberté – les CIL), les appréciations des risques, le Privacy Impact Assessment, etc. Mettre en place ce genre de brique ne présente pas de difficulté particulière au sein d’un établissement de santé, qui a déjà vécu des démarches qualité depuis le début des années 2000, car le RGPD n’est rien de plus qu’une démarche par le risque, donc une démarche qualité.
Par exemple, la mise en place du vote électronique dans les établissements de santé, pour les prochaines élections professionnelles, rentre exactement dans cette démarche et les DRH, pour ce que nous en savons, sont tout à fait sensibles à cette approche. Après tout, il faut bien sécuriser la distribution des identifiants sur la plateforme de vote (qui est quasi tout le temps externalisée en mode SaaS), il faut bien prévoir des systèmes de recouvrement des mots de passe, il faut bien sécuriser la phase de dépouillement. Tout le monde comprendra aisément que les contre-mesures aux risques identifiés ont leurs limites et qu’à un moment donné la MOA doit bien sortir de la phase d’appréciation des risques en acceptant les risques résiduels, car le RGPD ne parle jamais de risque zéro. Il arrive que le DPO doive « manger son chapeau », mais à cela rien d’anormal : le RGPD stipule qu’il n’a qu’un rôle de conseil et d’alerte, la MOA reste propriétaire de ses risques, pour le RGPD comme pour le reste.
Il y a certes la question de l’antériorité : quid des traitements déjà en place, dont une bonne partie sont sensibles et nécessiteraient dans l’idéal de passer à la moulinette du PIA ? En toute rigueur, les traitements déjà conformes n’ont pas à être révisés sauf modification substantielle, mais cela semble être un point de débat et en tout état de cause, une revue réduit considérablement le risque de contentieux, d’autant que la CNIL le recommande fortement. Selon nos estimations, un établissement de soins de grande taille aligne environ 35 traitements (qui couvrent donc tous les processus), dont à peine la moitié peuvent être estampillés « sensibles ». Paris ne s’étant pas fait en un jour, il est fortement conseillé de démarrer par les plus sensibles de cette liste, à savoir le DPI (volet administratif et médical), la médecine du travail, la gestion des fiches d’événements indésirables, l’Active Directory et les RH.
Cela se complique dès lors que l’on aborde l’épineuse question des relations contractuelles entre le responsable de traitement (RT) et le fournisseur (titulaire du marché, mais sous-traitant (ST) au sens du RGPD). Là encore, il y a l’antériorité, et le futur. Pour ce qui concerne l’antériorité, les juristes stipulent que l’ensemble des contrats existants est à revoir et doit faire l’objet d’avenants précisant la répartition des rôles entre le RT et le ST sur les traitements mis en œuvre. Dans un CHU, c’est tout bonnement impossible : il y a des milliers de marchés en cours et une telle charge de travail ne peut pas être assumée. Il va donc falloir faire des choix, évidemment dictés par les risques associés aux traitements les plus sensibles et aux fournisseurs en position de ST sur ces traitements.
Au premier stade, le DPO lutte contre l’entropie – le désordre – qui est l’état de fait à l’arrivée du RGPD, puisque les dispositions qu’il contient n’avaient jamais été prises en compte. Le DPO évolue en fait sur un puzzle dont il doit progressivement agencer les pièces, mais dans un environnement où les bords du puzzle bougent sans cesse, car il y a sens cesse de nouveaux traitements, de nouveaux marchés. Tout l’enjeu consiste à capter la mise en place de ces traitements.
Capter les traitements
Rapidement, le DPO comprend que la mise en conformité n’est ni sa seule tâche ni la plus compliquée : être en amont de tout nouveau traitement, donc en avoir connaissance, devient son enjeu principal. Penser que tout traitement nécessite un logiciel, tout logiciel une acquisition qui passe par la DSI et donc que la seule source des traitements dans un établissement est la DSI, est faux. Tous les logiciels ne sont pas forcément achetés par la DSI, tous les logiciels ne sont d’ailleurs pas forcément achetés (il existe de nombreux cas de prêts de logiciels ou de matériels qui ne passent par aucun circuit d’achat formalisé) et tout traitement n’a pas forcément pour origine une acquisition de logiciel.
C’est ainsi que l’on trouve des traitements issus de l’acquisition de matériels biomédicaux (qui ne passent la plupart du temps pas par la DSI), issus de requêtes sur des bases de données nominatives (entrepôt de données RH ou médicaux par exemple), issus d’acquisitions de prestations diverses (assurance en responsabilité civile pour les accidents médicaux, vote électronique, commande de matelas thérapeutiques par le biais d’un portail web, etc.), issus de projets de recherche clinique ne relevant pas des MR1 de la CNIL, issus de prêts de matériels – par exemple en génétique -, etc.
L’enjeu du DPO est de se positionner le plus possible en amont de ces traitements pour en capter l’existence. Si la DSI est le premier interlocuteur du DPO au sein de l’établissement, la Direction Générale (car elle voit passer tous les projets) et la Direction des achats (qui voit passer tous les marchés) sont sans aucun doute les suivants, sans parler bien entendu des équipes biomédicales, des services techniques, des équipes de sécurité – bref de toute l’ingénierie -, de la DRH, des équipes gérant les entrepôts de Big Data des données de santé, etc. Une intervention, renouvelée à minima tous les ans dans les staffs de ces équipes fait partie des actions incontournables du DPO.
Le DPO quitte forcément la casquette de pilote d’un processus administratif bordé, pour porter celle d’un accompagnant, d’un facilitateur, d’un pédagogue. Le DPO est en mode « soft power » : convaincre plutôt que contraindre, faire adhérer plutôt qu’être intrusif. La question n’est pas que le DPO ne doive pas être partie prenante dans un traitement, la question est que le job est plus facile pour lui s’il ne l’est pas : le DPO doit mettre en place des processus en mode roue de Deming, et veiller à ce que ces roues tournent. Pas vite, mais tout le temps.
A ce stade avancé, le second enjeu du DPO est de rassurer. L’expérience montre que les experts techniques (à entendre au sens large du terme, cela concernant aussi bien les informaticiens que les acheteurs ou les juristes) peinent à envisager une obligation réglementaire autrement que « tout tout de suite » au lieu de l’aborder sous l’angle de Deming en mode PDCA2. Le DPO doit faire preuve de pédagogie et amener ces équipes à aborder le RGPD – qui est un monstre de charge de travail – sous l’angle de Paréto : on va s’attaquer aux 20% les plus sensibles et compliqués et laisser 80% en standby, puis quand on aura terminé, on va prendre les 20% des 80% qui reste, etc. Le DPO est-il d’ailleurs autre chose qu’un qualiticien ?
Cela pose d’ailleurs la question des indicateurs à mettre en place. Au premier stade de maturité RGPD, il est tentant de compter les traitements conformes – c’est la vision statique des indicateurs. Au second stade de maturité, il faut surtout compter les roues qui tournent en plus - c’est la vision dynamique. Le DPO travaille sur le terrain de la gouvernance plutôt que de la technique. Et cette approche est majeure dès lors que l’on passe à l’échelon GHT.
L’échelon GHT
A l’échelon GHT surgissent deux difficultés supplémentaires : la taille, et la taille. La taille parce qu’aucun DPO ne peut mener dans un GHT, dans certains cas 50% plus large que son établissement d’origine, la même démarche : trop gros, trop éclaté, typologies d’activités trop diverses. Et la taille, une seconde fois, car si la démarche relative aux processus métiers au sein du GHT n’est pas engagée (marche vers une DSI unique, travaux RH communs, processus achat unifié, etc.), le DPO de l’établissement support va s’épuiser en pure perte.
La factorisation souhaitable du socle documentaire est indispensable : inutile de demander à chaque DPO ou relai-DPO des établissements périphériques de réinventer la roue, inutile que tout le monde refasse le PIA de son AD ou de des traitements RH, autant factoriser au niveau de l’établissement support. Le DPO « central » aura d’ailleurs assez à faire avec la résolution de questions pas si simples, telle le partage des données RH (qui est le RT ? quelle légitimité du traitement ?) ou la convergence du DPI (quelle politique d’habilitation ?), la responsabilité du DPO de l’établissement support en cas d’incident sur un établissement périphérique (les textes ne sont pas clairs), la réponse aux sollicitations des équipes de direction de tout le GHT sur l’implication des décideurs dans le RGPD. A ce sujet, le choix des relais DPO sur le terrain est une question cruciale, l’expérience montrant que les qualiticiens sont de bien meilleurs candidats que les informaticiens.
RSSI et DPO, RSSI ou DPO ?
Les travaux sur les projets tels le vote électronique, la mise en conformité du DPI et autres font apparaître une réalité étonnante : alors que le RGPD insiste bien sur le fait que les risques à évaluer sont ceux que l’on fait encourir aux personnes dont on traite les données, votre serviteur n’a pas un seul exemple, à l’heure de rédaction du présent article, d’un risque pour les personnes qui ne soit pas en même temps un risque pour l’établissement : après tout, si risque pour les personnes, il y a, par ricochet, un risque juridique à minima pour l’établissement ! La question de savoir si le DPO et le RSSI doivent être des personnes différentes n’est donc pas vraie ou fausse, elle est tout simplement hors de propos : le risque IT se confond avec le risque IL (Information Legacy) et il y a fort à parier que RSSI et DPO rejoignent dans les prochaines années une équipe « Conformité ». D’autant que le levier réglementaire du RGPD offre au RSSI des opportunités uniques de faire avancer la SSI, situation paradoxale à priori mais dans les faits tout à fait partagée. Quand on tombe sur un consultant qui commence sa démarche par cette question de recouvrement DPO / RSSI, c’est qu’il a clairement trois trains de retard en termes de maturité dans ce domaine : le DPO doit travailler avec le RSSI et conjointement. Et si c’est la même personne, cela ne gâte rien.
Conclusion
Si l’échelle COBIT (6 niveau, de 0 à 5) est faite pour mesurer la capacité de l’IT à s’aligner sur la stratégie de l’établissement, elle n’est pas adaptée à la mesure de la maturité du processus RGPD. Approche administrative, approche risque ou approche processus PDCA, c’est peut-être la bonne échelle, sur 3 niveaux. Avec les GHT, toute démarche qui n’est pas au niveau 3 ne pourra pas attaquer l’ensemble des établissements du groupement. Et à contrario, tout GHT qui n’a pas engagé une refonte des processus métier transversaux ne peut prétendre à une démarche RGPD de niveau 3. Le RGPD arrive en pleine mise en œuvre des GHT : opportunité ou contrainte ? Opportunité sans aucun doute.
Enfin, le RGPD est un galop d’essai (au sens où ce n’est pas le dernier) : attention à la directive NIS… des factorisations de socle documentaire, d’audit interne, d’équipe de mise en œuvre vont rapidement devenir obligatoires sous peine d’épuiser la technostructure de l’établissement.
Rendez-vous les 2, 3 et 4 avril 2019 au Mans, pour 20 conférences préparées pour l’événement : S’inscrire au Congrès 2019
1 Méthodologies de référence, qui concernent la recherche clinique
2 PDCA : Plan Do Check Act, ou l’amélioration continue symbolisée par la roue de Deming