Le Privacy By Design permet de minimiser les efforts fournis pour se conformer à la Loi en évitant la mise en conformité a posteriori qui demande souvent le déploiement de projets d’adaptation de l’existant difficiles organisationnellement, technologiquement complexes et financièrement coûteux. Nos retours d’expérience montrent que plusieurs facteurs clés de succès sont à prendre en compte : s’armer de pragmatisme dans la définition de Privacy Impact Assessment, ne pas concevoir un processus décorrélé de l’existant, concentrer l’énergie mise en œuvre sur les projets les plus sensibles et outiller les chefs de projets.

Dans le premier volet, nous sommes revenus sur les deux premiers facteurs clés de succès à prendre en compte qui sont :

• Concevoir une méthodologie de Privacy Impact Assessment pragmatique
• S’intégrer dans la méthodologie Projet existante

Nous reviendrons ici sur les deux derniers facteurs essentiels à prendre en compte.

Identifier les projets sensibles pour prioriser les efforts d’accompagnement

Dans la majorité des organisations, le volume de projets est trop important pour que les équipes en charge de la conformité aient la capacité d’accompagner chacun d’eux et en particulier de réaliser une analyse de risques même simplifiée. Il est donc nécessaire d’adapter l’approche systématique de PIA en identifiant le plus en amont possible les projets qui présentent une sensibilité accrue afin de prioriser les efforts d’accompagnement.

Les chefs de projets, souvent peu familiers de la Loi Informatique et Libertés, peuvent se retrouver en difficultés lorsqu’il s’agit d’exprimer la sensibilité de leur projet au sens de la Loi. Il est donc nécessaire de les accompagner dans cette étape en leur fournissant une liste de questions simples et compréhensibles par les non-initiés.

Dans la pratique, plusieurs facteurs peuvent rendre un projet sensible. Par exemple, la manipulation de données sensibles au sens de la loi la mise en œuvre de transferts hors UE. D’autres facteurs, moins directement liés à la loi peuvent également être identifié : utilisation de nouvelles technologies (Big data par exemple) ou existence de données sensibles dans le contexte de l’organisation (ex : identité des collaborateurs intervenant à proximité de produits cancérigènes).

Il conviendra donc d’identifier la liste des critères rendant un projet sensible en fonction du contexte spécifique de l’organisation et des risques qui pèsent sur elle.

Rendre autonome le chef de projet dans la conduite de cette étape permet de s’assurer que tous les projets feront l’objet d’une appréciation de leur sensibilité vis-à-vis de la Loi Informatique et Libertés. Enfin, en associant les équipes conformités aux comités chargés du suivi des projets en phase d’étude préalable, l’analyse des chefs de projets peut être challengée avant validation.

Il conviendra alors d’adapter l’investissement de l’équipe conformité à la sensibilité des projets. D’un suivi distant pour les projets les moins sensibles (alimentation en guides de mise en conformité, réponses à des demandes d’expertise) à un suivi rapproché pour les projets les plus sensibles (groupes de travail spécifiques sur le sujet du Privacy, analyse de risques détaillée, vérification des livrables exprimant les exigences de conformité, pilotage de la recette conformité, etc.). Dans tous les cas, l’équipe devra maintenir une liste des projets, des évaluations de criticité et s’assurer d’être présente dans les bonnes instances pour avoir accès à l’actualité des projets (création, arrêt…), voire disposer d’un accès direct au portfolio projet qui existe dans les organisations les plus avancées.

Outiller les chefs de projet

Tous les projets ne pouvant être accompagnés de façon rapprochée par l’équipe conformité, les chefs de projets devant traiter la mise en conformité en autonomie devront disposer d’outils pour les aider, généralement un guide de mise en conformité à la loi Informatique et Libertés. Ce guide ne doit pas ressembler à un document juridique mais bien plus à une traduction concrète, explicite et intelligible de la loi pour un non initié et doit permettre d’accompagner le chef de projet dans le choix des meilleures mesures pour s’y conformer, qu’elles soient organisationnelles ou techniques.

L’un des sujets qui nécessite une attention particulière est par exemple le transfert de données à des tiers ou hors de l’UE. Le transfert de données – qui peut désigner aussi bien le simple transit d’un flux par un équipement réseau, l’hébergement dans le Cloud de la messagerie ou la consultation de données sur un site web – sera explicité afin que chef de projet puisse identifier par lui-même les transferts de données réalisés dans le cadre de son projet. Il pourra alors par exemple s’appuyer sur les modèles de clauses proposées dans le guide pour les intégrer dans ses contrats avec des tiers ou utiliser une liste des filiales ayant signées les Binding Corporate Rules pour s’assurer que son transfert à l’international est autorisé.

Ce guide de mise en conformité pourra être associé à un cahier de recette type, permettant de contrôler le bon respect des principes juridiques fondamentaux. Une liste de questions restreintes (autour d’une dizaine généralement) aidera le chef de projet à contrôler les points majeurs et ainsi valider la conformité globale du projet à la Loi Informatique et Libertés : les mentions d’information sont-elles bien ajoutées ? Les cases de champs libres disposent-elles d’un disclaimer sur leur bonne utilisation ? Les contrats contiennent-ils des clauses LIL ? La durée de conservation des données a-t-elle été définie et leurs modalités de suppression étudiées ?

À moyen terme, l’outillage pourra aller un cran au-delà en proposant aux chefs de projet des solutions techniques pour faciliter la mise en conformité. Des plateformes mutualisées de chiffrement ou d’anonymisation de données ou encore des processus de collecte de données conformes pourront être construits. Les investissements déjà réalisés dans la filière sécurité de l’information pourront être largement exploités.

Un processus à concevoir et des équipes pour le déployer

Le Privacy By Design, future obligation réglementaire, constitue dès à présent un moyen de s’assurer de la conformité des nouveaux projets.

Le CIL et ses équipes devront s’armer d’une bonne dose de pragmatisme pour adapter les processus existants en les alimentant de leurs exigences essentielles tout en identifiant les projets les plus sensibles afin d’y apporter une vigilance accrue.

Mais au-delà du processus en lui-même, le CIL ou futur DPO devra se poser au plus tôt la question de ses besoins en ressources pour suivre ces projets : combien de personnes sont à mobiliser pour accompagner sereinement les chefs de projets ? Quelles sont les compétences attendues de ces équipes (expertise juridique, connaissances métiers, capacité à interagir avec les équipes IT et SSI, compétences de chef de projets,  …) ? Quelle mutualisation possible avec les filières existantes (RSSI, Conformité, RPCA, etc.) ?

Autant de questions auxquelles il conviendra de répondre afin d’assurer au Privacy By Design un déploiement réussi, élément clé pour que cette contrainte devienne une opportunité !

Cet article Privacy by design : anticiper pour mieux protéger (2/2) est apparu en premier sur RiskInsight.

Adopter une démarche de Privacy By Design c’est intégrer le respect de la vie privée dès la conception des projets, c’est-à-dire s’assurer de la pertinence des données collectées, comprendre les risques pour les personnes concernées, anticiper l’information et le droit d’accès, etc.

La Loi Informatique et Liberté, via l’article 34, demandait déjà au responsable de traitement de « prendre toutes les précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données » mais n’imposait pas explicitement la mise en oeuvre d’une démarche de Privacy By Design. De ce fait, peu d’organisations ont déjà mis en place une telle démarche.

Le Privacy By Design permet pourtant de minimiser les efforts fournis pour se conformer à la Loi en évitant la mise en conformité a posteriori qui demande souvent le déploiement de projets d’adaptation de l’existant difficiles organisationnellement, technologiquement complexes et financièrement coûteux.

Privacy By Design

Au regard des échéances réglementaires, et afin de mieux traiter les contraintes de conformité, les premières initiatives de Privacy By Design débutent et se multiplient. Nos retours d’expérience montrent que plusieurs facteurs clés de succès sont à prendre en compte : s’armer de pragmatisme dans la définition de Privacy Impact Assessment, ne pas concevoir un processus décorrélé de l’existant, concentrer l’énergie mise en œuvre sur les projets les plus sensibles et outiller les chefs de projets.

Concevoir une méthodologie de Privacy Impact Assessment pragmatique

Plutôt que de repartir de zéro, il convient comme souvent de s’inspirer des travaux de réflexion menés par ses pairs. En particulier, la CNIL a décidé d’accompagner les responsables de traitements désireux de s’engager dans le Privacy By Design en publiant en juillet 2015 une version révisée de son guide de gestion des risques sur la vie privée. Elle l’adapte ainsi au positionnement du règlement européen et aux retours d’expérience en proposant une méthodologie pour mener des Privacy Impact Assessment (PIA).

Le guide décrit la façon d’employer la méthode EBIOS, déjà très connue et reconnue pour la sécurité de l’information, sur le sujet Informatique et Libertés. Les deux premières étapes visent respectivement à identifier le contexte particulier aux traitements mis en œuvre par le projet et à identifier les mesures nécessaires au respect des principes juridiques fondamentaux : respect de la finalité, pertinence des données collectées, information des personnes, exercice des droits, sécurité des données, accomplissement des formalités. Puis vient l’étape dite d’analyse des risques durant laquelle les menaces pertinentes sont identifiées et associées aux évènements redoutés suivant trois grands types : accès illégitime, modification ou disparition des données personnelles. Les risques liés à la conformité Informatique et Libertés sont alors évalués en termes de gravité et de vraisemblance et font l’objet d’une décision quant à leur acceptation.

La méthodologie d’analyse de risques EBIOS vise l’exhaustivité dans l’analyse des risques encourus. Cette exhaustivité impose généralement aux organisations qui l’utilisent pour leurs analyses de risques SSI de s’appuyer sur des équipes d’intégration de la sécurité dans les projets à même de consacrer suffisamment de temps à l’accompagnement des chefs de projets et en mesure de maîtriser la méthodologie, souvent perçue comme complexe au premier abord.

Les équipes en charge de la conformité ne sont généralement ni organisées ni dimensionnées pour réaliser un accompagnement de tous les projets d’une organisation sur la base d’une méthodologie aussi chronophage.

La conduite systématique d’analyses de risques EBIOS pour encadrer les risques Informatiques et Libertés apparaît alors souvent comme trop ambitieuse au regard des ressources à engager et risque ainsi d’alourdir de façon démesurée la charge du chef de projet et donc d’entraver le bon déroulement de la méthodologie projet.

Il reviendra donc au Correspondant Informatique ou Liberté (CIL) ou futur Data Privacy Officer (DPO) d’adapter et de simplifier la méthodologie d’analyse de risques qu’il souhaite déployer aux capacités d’accompagnement de ses équipes. Plusieurs pistes sont envisageables : réalisation d’un questionnaire simple de pré-qualification du risque pour prioriser les efforts entre les projets, limitation du nombre de scénarios de risques étudiés, réduction des listes de menaces applicables dans le contexte, préidentification des risques types, etc.

S’intégrer dans la méthodologie Projet existante

Un écueil souvent rencontré pour de nouvelles méthodologies : vouloir s’appuyer sur un nouveau processus, propre au sujet traité (ici la mise en conformité LIL3), qu’il faudra alors déployer dans l’organisation. Évangélisation chronophage, non connaissance des méthodes de travail des chefs de projets, redondance dans les demandes : autant de raisons justifiant l’échec probable de cette orientation.

Le CIL devrait plutôt chercher à s’intégrer dans le processus de gestion de projet existant : étapes clés, comités, livrables, etc. Des équipes (responsable méthode ou qualité par exemple) ont en général la responsabilité des méthodologies projet et peuvent accompagner le CIL dans sa compréhension et challenger ses propositions d’amendements.

Depuis plusieurs années de nombreuses organisations ont d’ailleurs déjà amendé leur processus de gestion de projet pour y intégrer les exigences de sécurité SI. Un exercice dont la réussite dépend souvent d’une bonne répartition des travaux au sein des grandes phases d’un projet. Il se décompose en plusieurs phases :

• Étude préalable : appréciation de la criticité du projet afin d’identifier les projets les plus sensibles et prioriser les efforts d’accompagnement. Une analyse de risques SSI détaillée sera seulement conduite pour les projets les plus sensibles.
• Conception : identification des exigences de sécurité à prendre en compte par chacun des acteurs.
• Mise en œuvre : suivi de la bonne mise en œuvre des mesures choisies pour répondre aux exigences.
• Recette : conduite d’une recette sécurité qui valide la prise en compte des exigences sécurité et l’efficacité des mesures mises en place. Elle est souvent accompagnée d’un audit de sécurité ou de tests d’intrusion.

Les enjeux étant similaires, la même méthodologie est tout à fait adaptable dans un contexte de Privacy By Design. Les erreurs à éviter seront alors les mêmes : sous dimensionnement des équipes en charge d’accompagner les chefs de projets, complexité de la méthode, absence ou réalisation trop tardive de la recette visant à valider la conformité en fin de processus, non implication des acteurs en charge de la conformité dans les comités clés.

Idéalement, le Privacy By Design cherchera à faire évoluer la méthodologie existante d’intégration de la sécurité dans les projets, celle-ci étant déjà rodée et bien connue des acteurs du projet.

La 2^ème partie publiée le mois prochain reviendra sur les deux autres facteurs clés de succès à prendre en compte : concentrer l’énergie mise en œuvre sur les projets les plus sensibles et outiller les chefs de projets.

Cet article Privacy by design : anticiper pour mieux protéger (partie 1) est apparu en premier sur RiskInsight.

Une nouvelle publication qui gagne en lisibilité

La première évolution de cette nouvelle version est une réorganisation globale des thématiques. Elles manquaient effectivement de clarté par le passé.

Cela se matérialise par l’adoption d’une structure globale PDCA bien plus affirmée qu’auparavant. Elle reprend la structure dite « haut-niveau » par ISO/IEC qui définit une organisation, une terminologie et des définitions communes afin de garantir une unité entre les différentes normes de système de management. Ceci facilitera la construction de systèmes de management intégrés.

Contrairement à la précédente publication, une progression linéaire apparait plus clairement et permet un découpage en 4 phases.

• La première correspondant au « PLAN » est nommée « Context », « Leadership », et « Planning » (chapitre 4 à 6). Elle décrit l’identification du contexte de l’organisation, la définition de la gouvernance du SMSI, l’identification des risques et la détermination des objectifs de sécurité ainsi que la planification de leur mise en œuvre. Il est à noter l’utilisation d’un vocabulaire plus précis que dans l’ISO 27001:2005 concernant l’énonciation des clauses.

• La seconde phase, « DO » (chapitres 7 « Support » et 8 « Operation »), explique l’identification et l’allocation des moyens supports du SMSI, l’élaboration de la documentation et le déploiement des mesures de traitement du risque.

• Une phase « CHECK » (chapitre 9 « Performance Evaluation ») se dessine et comprend la mise en œuvre des processus de contrôle, d’audit interne et de revue par la direction du SMSI.

• Enfin, une phase « ACT » (chapitre 10 « Improvement ») explique les processus de traitement des non-conformités et d’amélioration du SMSI. Ceux-ci sont simplifiés en réduisant en particulier le contrôle sur les enregistrements.

Des évolutions de forme plus que de fond

Plusieurs concepts sont abordés plus en détail dans la nouvelle version de l’ISO 27001.

L’apparition du terme  « top management »

Un chapitre entier (5.3. Organizational roles, responsabilities and authorities) dans la nouvelle ISO 27001 remplace une simple clause et souligne l’importance de l’assignation des responsabilités par le « top management ». Cette dénomination est également reprise dans les phases de construction du SMSI, de contrôles et de revue de direction.

Les interfaces enfin reconnues en tant que telles

La norme précise enfin le concept d’interface (4.3.c). Très utilisé actuellement, il permet de définir les rôles et responsabilités des différents « fournisseurs » du SMSI, qu’ils soient internes ou externes. Cette précision entérine un concept déjà bien en place. D’autre part, les parties prenantes deviennent un élément déterminant pour identifier les exigences de sécurité  (4.2.a).

Une définition des indicateurs simplifiée

Un chapitre (6.2. Information security objectives and plans to achieve them) énonce la nécessité de documenter des objectifs de sécurité de l’information à des niveaux pertinents. Mais surtout il met en avant le fait que les mesures de sécurité doivent être suivies par des indicateurs seulement si cela est « practicable ». Nous verrons ce que donnera la traduction en français mais il en est terminé de l’obligation de mettre des indicateurs sur l’ensemble des mesures de sécurité.

La déclaration d’applicabilité voit son « ouverture » renforcée

La  nouvelle ISO 27001 renforce la capacité à réaliser une déclaration d’applicabilité qui ne se restreint pas aux mesures de l’ISO 27002 : « l’organisation peut ajouter des objectifs de contrôles et créer les contrôles lorsque cela est nécessaire ou encore les identifier à partir de n’importe quelle source », cependant elle doit vérifier qu’aucune mesure majeure de sécurité de l’ISO 27002 n’a été omise. Ce point clé a fait l’objet de nombreux débats, mais il est essentiel pour conserver une « comparabilité » entre plusieurs certifications, au-delà du simple périmètre.

La communication autour du SMSI, à réfléchir en interne comme en externe

Un nouveau chapitre (7.4 Communication) énonce la nécessité pour chaque organisation, de déterminer dans son cas particulier, le besoin en termes de communication interne ou externe à réaliser concernant le SMSI (sujet, communiquant, cible, procédé).

Une nouvelle publication, mais quels changements pour la mise en place d’un SMSI ou le maintien d’une certification ISO 27001 ?

Par une meilleure cohérence dans l’enchaînement des chapitres et dans la lecture de la logique globale PDCA ainsi qu’une plus grande précision dans la définition de plusieurs concepts,  la nouvelle version de l’ISO 27001 clarifie la mise en œuvre de la norme.

Il ne s’agit donc pas d’une révolution, les concepts restent les mêmes. Cependant, la norme gagne en clarté et en efficacité. La migration des SMSI existants ne posera pas de problèmes fondamentaux et pourra même être l’occasion de simplifier certains processus comme ceux des indicateurs ou encore le suivi des non-conformités. De plus, la structure unifiée avec les autres normes de systèmes de management (ISO 9001…) facilitera la mise en œuvre de systèmes de management intégrés.

Les annexes de l’ISO 27001, basées sur la norme ISO 27002, ont également été revues en profondeur.

Une nouvelle mouture qui facilitera le quotidien de nombreux RSSI !

Cet article Mise à jour de l’ISO 27001 : quels impacts opérationnels ? est apparu en premier sur RiskInsight.