De nombreuses entreprises se demandent actuellement si leurs mesures de sécurité informatique et leur éventuel ISMS répondent déjà aux exigences de la protection des données. Selon l'environnement, les entreprises doivent se conformer à la LPD suisse, au RGPD ainsi qu'à d'autres directives spécifiques à la branche. Dans notre série d'articles sur la protection des données, nous répondons aux questions suivantes :
En matière de protection de la vie privée, l'objectif est, comme le formule la LPD suisse, de"protéger la personnalité et les droits fondamentaux des personnes au sujet desquelles des données sont traitées". La sécurité de l'information a pour but de protéger les informations. Les deux thèmes ne sont pas identiques, mais s'accordent à merveille : Grâce au travail conceptuel effectué dans le cadre de la protection de la vie privée, la sécurité de l'information apprend à mieux comprendre les besoins de protection qu'elle doit satisfaire.
Dans la protection de la vie privée se pose également la question de savoir quelles données sont collectées et dans quel but. La protection de la vie privée a donc une influence sur la définition du processus d'entreprise et du service à fournir (ce qui est collecté, pourquoi et dans quel but). En fin de compte, les domaines spécialisés travaillent main dans la main : le processus doit satisfaire aux exigences de la protection de la vie privée ; la sécurité de l'information doit protéger aussi bien le processus que les données. L'un ne va pas sans l'autre.
Le cadre de la protection de la vie privée ISO
Dans la norme 29100:2011, l'ISO définit un"cadre de protection de la vie privée". Il s'agit d'un cadre de base et d'une terminologie pour le traitement des IIP. Ce dernier - Personally Identifiable Information - se réfère à toutes les formes de données qui permettent d'une part d'identifier une personne et d'autre part de tirer des conclusions sur son comportement ou sa situation personnelle. La formulation est volontairement laissée ouverte à ce stade. La norme elle-même contient de longues explications sur la manière dont les planificateurs peuvent identifier les données pertinentes dans leur projet.
Un exemple : les IIP peuvent être par exemple un numéro de carte de crédit, de téléphone ou de client ainsi que les données de transaction correspondantes qui peuvent être attribuées à une personne. Il importe peu que cette personne soit son propre client. Les données dont on dispose sur les collaborateurs de ses clients ou sur les clients de ses clients peuvent également être pertinentes. Pour un prestataire de services informatiques, son système de billetterie peut donc être pertinent dès que de telles données sont recopiées dans un ticket sans qu'il le demande.
La norme divise le traitement des données en quatre entités, comme le montre le graphique ci-dessous. Le principal PII est la personne physique qui devient identifiable. Le contrôleur PII décide pourquoi les données doivent être collectées et traitées et également comment. D'un point de vue juridique, il est responsable du respect des règles.
Un PII Controller peut également désigner un PII Processor en tant que suppléant, qui effectuera le traitement des données à sa place ou le soutiendra conformément à ses instructions. Les trois postes mentionnés sont entièrement interconnectés, ce qui signifie que les PII peuvent circuler librement dans les deux sens.
Il importe peu que le chef des DPI ait une relation contractuelle avec le contrôleur des DPI ou le processeur des DPI, car en fin de compte, les deux sont responsables de tous les DPI qu'ils ont, indépendamment du canal entrant, et tous deux doivent s'assurer qu'ils agissent conformément aux directives convenues. Il faut donc aussi clarifier ce qui se passe si des données sont envoyées par des tiers sans qu'on le leur demande.
Toutes lesparties tierces(3rd Parties) sont également concernées, car elles reçoivent des DPI et peuvent les traiter, mais n'agissent pas selon les instructions du contrôleur de DPI. Ils mettent en place leur propre cadre de protection de la vie privée et deviennent ainsi eux-mêmes des contrôleurs de DPI - mais sans que le premier contrôleur de DPI d'origine ne puisse les voir.
Cela signifie que les IIP peuvent parcourir une chaîne de cadres de protection de la vie privée jusqu'à ce qu'elles atterrissent quelque part et que ni le contrôleur initial ni le principal des IIP ne sachent plus exactement comment elles sont traitées. Celui qui promet à ses clients une forte protection de la sphère privée devrait donc réfléchir dès le début aux services tiers qui doivent être impliqués et surtout pourquoi.
Le contrôleur des IIP est compétent pour décider pourquoi et comment les IIP sont traitées. Dans le cadre de la décision relative au déroulement du traitement, il lui incombe également d'appliquer les"principes de protection de la vie privée " de la norme ISO 29100:2011 :
Le contrôleur PII doit faire en sorte que les professionnels et les responsables commerciaux concernés se familiarisent avec ces principes. Il est également responsable de la documentation des directives et des décisions et de leur mise en œuvre par les PII Processors mandatés.
Ces onze principes de la protection de la vie privée n'ont pas d'équivalent direct dans les SI. Les décisions concernant la confidentialité, l'intégrité et la disponibilité ne signifient pas encore en soi une décision concernant la protection souhaitée des PII Principals.
Les principes de protection de la vie privée sont plutôt quelque chose qui doit être appliqué parallèlement à la sécurité de l'information. Ils doivent être déterminés et évalués séparément. Dans le cadre d'un projet, les deux exigences, celles de la sécurité et celles de la protection de la vie privée, doivent être prises en compte et coordonnées.
Le prochain article de notre série de blogs montrera comment, grâce à unPrivacy Impact Assessment (PIA), ces exigences peuvent être identifiées et évaluées de manière structurée.