Le chapitre IV, section 1, article 24 et l’article 32 dans la section 2 du Règlement Général pour la Protection des Données, formalisent les obligations générales du responsable du traitement en matière de sécurité : la mise en œuvre de mesures techniques et organisationnelles appropriées, au regard des risques pour la vie privée des personnes concernées, la définition et l’application de politiques adaptées au contexte et surtout la capacité de démontrer que le traitement est effectué en conformité avec le Règlement. Le responsable du traitement doit mettre en œuvre des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité ainsi que la résilience constante des systèmes et des services de traitement. Nous nous attacherons ici à analyser comment le Délégué à la Protection des Données (DPD) doit concevoir l’ensemble des règles de protection de la vie privée et de sécurité des données à caractère personnel en interaction et en cohérence avec les exigences stratégiques, fonctionnelles, opérationnelles et techniques de la SSI.
1. L’étude de la nature des données et du contexte des traitements
La CNIL en cohérence avec les articles 4, 9 et 10 du RGPD, respectivement 2, 3, 7§1, 8 et 9 de la loi Informatique et Libertés formalise 3 types ou natures de données à caractère personnel. Premièrement, les données courantes (l’état civil, l’identité, les données d’identification, les informations concernant la vie personnelle (les habitudes de vie, la situation familiale, hors données sensibles, très sensibles ou dangereuses…), les renseignements d’ordre économique et financier (les revenus, la situation financière, la situation fiscale...), les données de connexion (les adresses IP, les journaux d’évènements…), les données de localisation (les informations liées aux déplacements, données GPS, GSM…). Deuxièmement, les données hautement personnelles (les données relatives aux difficultés sociales ou les données bancaires). Troisièmement, les données très sensibles (les opinions philosophiques, politiques, religieuses, syndicales, les informations concernant la vie sexuelle, les données de santé, les renseignements concernant les origines ethniques, ou la vie sexuelle, les données biométriques, génétiques, ou concernant les infractions ou condamnations pénales).
1.1 Les risques pour la vie privée
L’article 35 du RGPD, en complément des articles précités prévoit la conduite d’une analyse d’impact relative à la protection des données (AIPD), lorsqu’un traitement de données personnelles est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes concernées.
Cette analyse de risques doit conduire à la mise en œuvre de règles adaptées et formalisées dans les politiques.
1.2 Définitions des risques sur la vie privée et les libertés fondamentales
Un « risque sur la vie privée » est un scénario décrivant un événement redouté (atteinte plus ou moins grave à la confidentialité, la disponibilité ou l’intégrité des données, et ses impacts potentiels sur les droits et libertés des personnes). Il est estimé en termes de gravité et de vraisemblance. La gravité doit être évaluée pour les personnes concernées, et non pour l’organisme. On voit ici une grande différence avec l’estimation qui est classiquement faite dans l’approche SSI (qui évalue les impacts plutôt du point de vue de l’organisme). Dans la démarche AIPD (Analyse d’Impact pour la Protection des Données), l’estimation de la gravité doit être évaluée par les impacts pour les personnes concernées (et pour la structure du responsable du traitement en cas de non-conformité).
La CNIL a publié une liste des traitements à risques où une AIPD est obligatoire.
1.3 Les impacts pour la vie privée et les libertés fondamentales
La CNIL formalise trois axes d’impact pour la personne concernée par le traitement. Les impacts corporels, matériels ou moraux. L’autorité de contrôle modélise trois niveaux sur quatre représentant des impacts significatifs pour les libertés des personnes concernées. Le premier niveau est qualifié de négligeable, le deuxième limité, le troisième important et le dernier maximal. Dans ces contextes, le responsable du traitement doit donc faire un travail important de définitions de politiques appropriées afin de limiter la vraisemblance des impacts sur la vie privée et les droits fondamentaux des personnes concernées.
2. L’architecture du référentiel protection de la vie privée et sécurité système d’information
L’approche proposée peut être adaptée en fonction de la culture sécurité de l’entreprise ou de l’organisme. Nous proposerons des alternatives dans la conception des différents textes en fonction des contextes. Mais le schéma général de l’architecture documentaire répond toujours à des orientations stratégiques, fonctionnelles, opérationnelles puis techniques.
2.1 Vision globale du référentiel protection de la vie privée en cohérence avec le référentiel SSI
2.1.1 La lettre d’engagement pour la sécurité de l’information et la protection de la vie privée
Les objectifs de ce document, qui a notre sens peut être communiqué au public, mais doit être systématiquement diffusé en interne et doit être bien compris par les collaborateurs sont de montrer l’engagement de responsabilité de la direction générale et du soutien nécessaire de chacun(e) dans l’organisation puis de formaliser le périmètre des traitements et des données pour avoir un impact sur la protection de la vie privée et de la sécurité de l’information.
Ce document doit être le plus fédérateur possible autour de la personne juridiquement responsable et le plus mobilisateur possible. Il cherche à montrer que l’objectif de la sécurité ne « s’auto-suffit pas », l’objectif de la protection ou de la sécurité est de protéger des valeurs fondamentales communes ou des engagements d’entreprise.
2.1.2 La politique générale pour la protection de l’information
Ce texte est destiné aux directions métiers. Il montre que la direction générale est consciente de sa responsabilité, juridique et opérationnelle. Elle est responsable non seulement des dommages ou des infractions éventuelles, mais aussi des moyens qu’elle affecte à la protection de l’information et à la sécurité des systèmes d’information. Elle formalise que les directions métiers sont responsables de la formalisation des besoins et des risques. Celles-ci sont « propriétaires » de leurs risques et ce sont donc à elles d’évaluer les niveaux d’impact de ces risques. Les impacts sont à l’origine des besoins. Il est important de noter que la définition des mesures de sécurité est de la responsabilité du RSSI, cependant la mise en œuvre des mesures de sécurité est de la responsabilité de la direction des systèmes d’information ou du sous-traitant. Le contrôle de l’application des mesures de sécurité est de la responsabilité du RSSI.
La validation des risques résiduels après l’application des mesures de sécurité est de la responsabilité de la direction générale ou des directions métiers. Ce texte devra faire référence à la politique de protection de la vie privée à usage interne, notamment pour les AIPD. Ce texte n’est pas strictement nécessaire pour la démarche de protection de la vie privée Son analyse ici cherche à montrer sa grande cohérence avec la protection de la vie privée, la démarche AIPD et la politique de protection de la vie privée à usage interne. Nous tenons à souligner le caractère opposable de cette politique. Les directions métiers ou la DSI ne peuvent mettre en place des applications ou des systèmes d’information sans respecter la démarche.
Certains lecteurs pourraient aussi être un peu effrayés par l’importance de la tâche de conception et d’applicabilité du document. Il s’agit souvent de petites structures peu habituées à la démarche méthodologique de sécurité système d’information. Dans ce cas, une alternative est possible en intégrant la démarche dans une directive de la PSSI expliquée plus bas. L’inconvénient est alors qu’il ne soit pas lu par les directions métiers voyant la SSI comme une démarche d’experts informatiques.
2.1.3 La politique de protection de la vie privée à usage interne
Nous proposons que la politique soit structurée en directives, chacune composée d’une ou de plusieurs règles. Les directives devraient être formalisées par thèmes : la classification des données à caractère personnel, l’obligation de formalisation du registre des traitements, les demandes d’exercices de droit des personnes concernées et les procédures de notifications de violations de données à caractère personnel, le renforcement de la culture « protection de la vie privée », la définition des prérogatives pour engager contractuellement le sous-traitant, l’évolution et le contrôle de la politique et enfin la sécurité. Cette dernière directive fera référence à la Politique Sécurité Système d’Information. Chaque directive devra faire l’objet a minima d’un objectif. Chaque règle dans la directive doit faire l’objet d’une table RACI (R pour réalise, A pour approuve, C pour consulté(e), I pour informé(e)). Le terme DOIT devra être utilisé afin d’être clairement auditable et opposable. Il est absolument majeur pour chaque règle d’identifier si possible les éléments de preuve du respect de l’obligation (fiche de description de traitement, registre, rapport d’AIPD, fondement juridique, preuve du consentement, contrats, feuilles de signatures des collaborateurs ayant été formés, rapport d’audit…), ainsi que l’acteur responsable de la production de l’élément de preuve. Nous proposons qu’à chaque directive et à ses objectifs soient associés un ou plusieurs objectifs mesurables et l’indication de qui est responsable de la production de l’indicateur de mesures.
2.1.4 La politique de protection de la vie privée à usage externe
Cette politique est souvent nommée politique de confidentialité. Nous déconseillons d’utiliser cette dénomination. La protection de la vie privée et le respect des libertés fondamentales ne peuvent se résumer à la protection de la confidentialité. La perte de disponibilité ou d’intégrité de données à caractère personnel peut être tout aussi grave qu’une perte de confidentialité. Les exemples sont nombreux où une perte d’intégrité sur des données bancaires entraîne des impacts matériels conséquents pour la vie privée de la personne concernée, la perte de disponibilité de santé rend les soins irréalisables avec des conséquences gravissimes.
L’objectif de la politique de protection de la vie privée à usage externe est non seulement de communiquer aux personnes concernées, l’identité du responsable du responsable du traitement, voire du DPD en démontrant la conformité avec les articles 13 et 14 du RGPD (article 32 de la loi Informatique et Libertés), mais surtout de montrer que le responsable du traitement s’engage à la plus grande transparence et loyauté vis-à-vis de la personne concernée.
Aussi les points suivants doivent être développés :
- le respect des principes relatifs aux traitements de données à caractère personnel, notamment il est important de bien souligner l’engagement du respect de principe de minimisation, de durée de conservation limitée et de sécurité ;
- les types de données à caractère personnel collectées et traitées ;
- les cas particuliers de collecte indirecte, en indiquant la source des données ;
- les fondements juridiques du traitement, le consentement, le contrat, l’intérêt légitime du responsable du traitement, la sauvegarde des intérêts vitaux de la personne concernée…
- les destinataires ;
- les tiers autorisés ;
- les transferts en dehors de l’Espace Économique Européen ;
- l’exercice des droits des personnes concernées, doit faire l’objet de la plus grande attention. La direction générale doit montrer sa bonne compréhension que les droits des personnes concernées prévalent sur ses droits de responsable des traitements ;
- les évolutions de la réglementation feront l’objet immédiate d’une application ;
- les contacts.
La difficulté est d’utiliser un langage clair, compréhensible pour un non initié. Cette politique ne peut se substituer à la fourniture obligatoire d’informations présentée dans les articles 13 et 14 du RGPD, traitement par traitement. Elle montre au public l’engagement du responsable du traitement dans la conformité et par-dessus tout à respecter les droits des personnes concernées. Elle doit être « poussée » à la personne concernée qui doit faire le minimum d’efforts pour la récupérer pour en prendre connaissance.
2.1.5 La politique sécurité système d’information
Elle doit être constituée de règles fonctionnelles opposables. L’aspect fonctionnel et non technique trouble parfois certains acteurs techniques. L’aspect fonctionnel permet une grande pérennité du texte, alors qu’une règle orientée produits est liée à l’évolution du produit. L’approche fonctionnelle est bien adaptée au contexte international, puisque dans certains pays, un nombre important de produits sont interdits et par-dessus tout, elle garantit la séparation des devoirs, concept essentiel à la sécurité et à son amélioration continue : la direction métier déléguée par le responsable des traitements exprime les évènements redoutés (démarche EBIOS) ou les impacts potentiels (démarche MEHARI) gradés selon les échelles présentées dans les politiques de niveau supérieur destinées aux directions métiers, le RSSI définit les règles fonctionnelles, le maître d’œuvre (la direction des systèmes d’information ou le service informatique) ou le sous-traitant les implémente, ce qui permet au RSSI de les contrôler, en évitant de se retrouver en position d’auto-contrôle.
La forme de la règle doit être impérative et le verbe « DOIT » doit être utilisé. À chaque règle une table RACI devrait être définie. À chaque thème (chapitre de la norme ISO 27002) doivent être liés un ou plusieurs objectifs. À chaque thème et aux objectifs identifiés doit être formalisé un sous-objectif mesurable et si possible la fonction responsable de la fourniture de l’indicateur de mesure. Quand cela est possible, l’élément de preuve de conformité à la règle doit être identifié.
Le lecteur en fonction du niveau de maturité SSI de son organisme pourrait être effrayé par la complexité ou la richesse du document. Face à ce constat, l’ANSSI a formulé le document des 42 règles d’hygiène de sécurité informatique et la CNIL a mis à disposition 17 fiches de recommandations de sécurité. Ces documents doivent être compris comme des synthèses de la norme ISO 27002.
2.1.6 Le cas de la sous-traitance, l’externalisation ou le cloud
Le sous-traitant, dans l’annexe au contrat formalisant les prérogatives respectives, qu’il doit signer avec le responsable du traitement, doit démontrer par la transcription effective orientée organisation, architectures et produits sa conformité avec les règles de la PSSI de son client.
Le sous-traitant démontre la transcription effective des règles de sécurité formalisées par le responsable des traitements dans le Plan d’Assurance Sécurité (PAS).
Il est clair qu’un nombre important de clients n’a pas atteint ce niveau de contractualisation. Le sous-traitant s’orientant alors vers la définition de sa propre PSSI ou de son propre PAS en application de normes de sécurité issues de la norme ISO 27002, mais adaptées au contexte de l’hébergement (ISO 27018, concernant la protection des données à caractère personnel dans l'informatique en nuages, ISO/CEI 27017 qui traite des aspects de la sécurité de l'information en nuage).
L’ANSSI propose un PAS minimal pour les organismes à maturité faible n’ayant pas formalisé de PSSI.
2.1.7 La charte « informatique »
Nous suggérons de ne plus l’appeler informatique. L’utilisateur doit être conscient que l’usage d’un grand nombre de composants informatiques ou non (chargeur de cigarettes électroniques avec port USB, appareils photo connectables au poste de travail…) d’applications externes (réseaux sociaux) ou les comportements généraux (parler en public, gérer des visiteurs…) doit être règlementé. La terminologie « charte d’utilisation des données et ressources système d’information » ou mieux « code de protection de l’information » nous semble plus adéquate.
La difficulté du rédacteur est de concevoir la charte de façon à être opposable, mais pas trop détaillée, car il ne sera pas possible de présenter tous les cas possibles. De plus si une règle détaillée doit faire l’objet d’un changement, il faudra alors la modifier et reconduire tout le processus de discussion collective avec les Instances Représentatives du Personnel, la présentation en toute transparence aux utilisateurs leur démontrant la proportionnalité de la règle à la finalité.
Le lecteur doit noter que la CNIL a toujours préféré l’approche d’explication de la charte par une sensibilisation qu’une unique action de signature par l’utilisateur. L’autorité de contrôle considère que le collaborateur dans son lien de subordination avec son employeur signera ce que l’on lui demande de signer.
La charte mise en annexe au contrat de travail est donc bien sûr possible s’il y a eu explication en toute transparence.
Nous recommandons de présenter la charte comme une suite de principes structurants consécutifs aux droits et aux devoirs de l’employeur d’une part, et de l’utilisateur d’autre part. La mise en avant de cet équilibre permet à l’utilisateur d’identifier les responsabilités respectives et donc aussi ses droits, ce qui est toujours plus fédérateur et mobilisateur.
Les sanctions éventuelles doivent être évoquées.
Nous conseillons, en complément de la charte, la conception d’un guide détaillé des bonnes pratiques opérationnelles et concrètes consécutives aux principes structurants liés aux droits et aux devoirs de l’employeur et de l’employé.
2.1.8 Les procédures de satisfaction des demandes d’exercices des droits des personnes concernées
Elles sont fondamentales pour la conformité au RGPD et à la Loi Informatique et Libertés. Elles doivent permettre l’exercice des droits d’accès, de rectification, de destruction, de limitation des traitements, de portabilité pour les organismes privés et refuser le profilage.
Elles devront prendre en considération les cas de demandes manifestement abusives et le recueil de preuves démontrant l’abus et les actions à prendre en compte, les demandes par téléphone (où elles devront refuser de répondre, car dans l’impossibilité de contrôler l’identité du demandeur), en face à face, par courrier, par e-mail, ce cas était déjà possible depuis la loi pour la république numérique, par une personne mandatée par la personne concernée.
Ces procédures doivent prendre en compte les délais de réponse, allant d’un à trois mois suivant les cas.
À chaque étape de la procédure, une responsabilité doit être identifiée et les délais de réponse pris en compte. Ces procédures devront bien sûr être régulièrement testées et améliorées si nécessaire.
2.1.9 La procédure AIPD
Elle doit constituer non plus l’engagement de responsabilité du responsable du traitement, mais le guide opérationnel de la méthode, les acteurs et leurs responsabilités dans une table RACI pour chaque étape ainsi que les livrables et documents attendus pour chaque étape.
Le lecteur doit bien comprendre ici que ces documents sont opposables à la fois à la maîtrise d’ouvrage ou la direction métier déléguée par le responsable du traitement et à la maîtrise d’œuvre en cas de non-conformité.
2.1.10 Les procédures de notification de violation de données à caractère personnel
Ces procédures répondent aux obligations de notification de violation de données à caractère personnel à la CNIL, et quand cela est possible aux personnes concernées.
Elles doivent définir les rôles et responsabilités ainsi que les mécanismes de remontées d’informations et de réaction, en cas de violation de données à caractère personnel. La mise en place de la voie fonctionnelle et non hiérarchique représentée par le DPD et ses éventuels relais doit permettre d’éviter les ressentis de culpabilité ou de délation parfois identifiés dans les structures peu matures sur ces sujets.
Les procédures doivent permettre de qualifier les violations de données selon leurs impacts sur les libertés et la vie privée des personnes concernées et prendre en compte l’amélioration des mesures de sécurité en fonction des violations de données. Elles définissent l’inventaire des violations de données dans un registre.
L’ensemble doit être testé régulièrement afin d’être amélioré.
2.1.11 Les politiques pour la continuité d’activité
Les politiques de continuité d’activité étaient orientées pour faire face aux crises ou sinistres pour l’organisme. Ces sinistres sont évalués par des BIA, appelés en français Bilan d’Impact pour l’Activité.
Le prisme de vision et d’analyse doit maintenant mieux prendre en compte la vie privée et les libertés fondamentales des personnes concernées. Les plans de continuité d’activité intégraient les crises potentielles concernant la responsabilité juridique de l’organisme en cas d’indisponibilité, mais de leur point de vue. Or les intérêts de l’organisme et de la personne concernée ne sont pas toujours convergents. Le droit à la disponibilité de la portabilité pour la fonction privée ou la mise à disposition de la limitation du traitement pour le public ou le privé sont clairement des exigences importantes pour les personnes concernées et une véritable contrainte pour le responsable des traitements.
2.1.12 La politique du système de management d’amélioration continue pour la protection de la vie privée
Il est important de rappeler le point d de l’article 32 du RGPD : le responsable du traitement ainsi que le sous-traitant mettent en œuvre « une procédure visant à tester et à analyser régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». L’amélioration continue de la sécurité et de la conformité au RGPD ou à la PSSI ne nécessite pas obligatoirement la définition et la mise en œuvre d’une politique spécifique et d’un système de management d’amélioration continue. Le responsable du traitement, en fonction des contextes, peut s’engager à réaliser régulièrement des audits de conformité juridique de ces traitements et des audits de sécurité (audits de conformité, tests intrusifs, audits d’architecture, audits de code, audit de configuration…). Il devra concevoir a minima des conventions d’audit précisant le périmètre et les modalités de l’audit (jalons, livrables attendus en entrée, livrables prévus en sortie, objectifs, champs et critères de l’audit, etc.).
Les experts SSI depuis longtemps familiarisés avec les Systèmes de Management de Sécurité de l’Information normalisés dans la norme ISO 27001 implémentent un SMSI pour prouver une maturité SSI et démontrer une sécurité effective. Nous suggérons d’aller plus loin et d’utiliser la logique d’amélioration continue non uniquement pour la sécurité, mais aussi pour la conformité aux exigences légales. Dans ce cas, une politique spécifique de management de la conformité devrait être formalisée. Elle devra définir des objectifs mesurables de conformité (nombre de traitements, nombre d’audits, temps d’indisponibilité des traitements impliquant les personnes concernées, nombre d’incidents entraînant des violations de données à caractère personnel...).
Conclusion
Nous alertons le lecteur de ne pas tomber dans le piège de « faire pour dire que l’on a fait ». Il faut formaliser pour être efficace. Le lecteur peut avoir l’impression d’une certaine lourdeur dans la formalisation des politiques alors que c’est l’absence de règles et d’engagement de responsabilités qui entraînera systématiquement des non-conformités et des dommages particulièrement lourds.
La formalisation de ces politiques appropriées ne peut affranchir le responsable du traitement de les expliquer en toute transparence, afin d’exiger les engagements de chaque acteur impliqué dans les traitements.
