Capitaliser sur ses processus pour se conformer au RGPD

Le RGPD sert à protéger, à l’échelle européenne, la vie privée de l’individu contre une utilisation abusive de ses données personnelles, alors que les injonctions paradoxales ne manquent pas :

• pour l’entreprise, la donnée est devenue un actif stratégique avec des besoins de corrélation et d’analyse des données massives,
• ladite entreprise s’appuie sur des organisations et des systèmes d’information largement ouverts aux clients et partenaires, avec des services désormais proposés dans le Cloud.

Ce contexte a amené le régulateur, l’Union Européenne, à exiger des entreprises une capacité à s’autoréguler et à prouver la conformité de leurs traitements, en remplacement des exigences de déclarations préalables antérieures.

La définition d’un traitement est large : «toute opération ou tout ensemble d’opérations effectuées ou non à l’aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel, telles que la collecte, l’enregistrement, l’organisation, la structuration, la conservation, l’adaptation ou la modification, l’extraction, la consultation, l’utilisation, la communication par transmission, la diffusion ou toute autre forme de mise à disposition, le rapprochement ou l’interconnexion, la limitation, l’effacement ou la destruction».

La notion de données est donc une composante essentielle de la RGPD, mais sous un angle synthétique particulier, seules les données personnelles et sensibles nécessitant une protection encadrée par la loi. Les durées de conservation sont également une préoccupation renforcée, pour ne pas dire nouvelle.

L’enjeu de l’exigence de la capacité à s’autoréguler est d’importance, car les sanctions encourues se veulent représentatives des dommages causés aux individus : là où l’entreprise pouvait jusqu’à présent limiter son évaluation du risque à un impact interne (par exemple pour un vol de données : une perte d’actif et le cas échéant un risque de réputation) elle devra désormais considérer la probabilité d’une forte sanction financière.

[C1] Le référentiel processus constitue un excellent support pour identifier la maille pertinente des traitements à analyser, par processus ou regroupement de processus, et donc construire l’inventaire des traitements.

[C2] Une approche « moderne » de la modélisation des processus, permettant un dialogue étroit entre métier et SI, vous aura amené à formaliser les jalons clés d’un processus : ces étapes, qui ont vocation à être

• pilotables par le métier,
• et donc matérialisées dans le SI.

En créant un lien entre processus et données à piloter, ces jalons constituent une source précieuse pour nourrir l’inventaire des données métier associées à chaque traitement.

Difficulté supplémentaire qui n’est pas propre au RGPD mais caractérise tout chantier SI ciblé données, il s’agira d’assurer au sein du référentiel la cohérence entre 2 visions de la donnée :

• la vision métier, qui reprendra le vocable familier des parties prenantes
• et la vision SI, qui permettra de faire le lien avec les référentiels de données.

Cette dernière, plus rigoureuse mais aussi plus complexe et fragmentée, peut difficilement servir de base à des échanges avec le métier : il est en effet fréquent qu’une « donnée métier » se traduise au plan informatique par une demi-douzaine de « données SI ». Ainsi, derrière la notion de « client entreprise », se cachent le tiers personne morale, le tiers personne physique, le rôle client, la localisation géographique,…

Seul un sous-ensemble de ce périmètre étant susceptible de porter des données pouvant être qualifiées de personnelles.

[C3] La description des traitements sensibles peut ensuite faire l’objet d’une modélisation spécifique RGPD. La norme BPMN permet de décrire des enchaînements d’opérations manuelles ou automatisées, en qualifiant chacune des opérations, et permet d’indiquer les données utilisées. Le traitement RGPD peut donc être considéré comme un « sous-processus » réutilisable si besoin, dans différents contextes.

[C4] Les mesures de protection appliquées aux traitements sensibles à identifier à cette étape ne concernent à mon sens que les mesures très spécifiques et directes au traitement concerné. De nombreux dispositifs essentiels de maîtrise des risques sur les systèmes d’information ont une portée générale (sur l’accès au système d’information ou les moyens d’extraction de données par exemple) et leur place est dans une approche globale de management du risque (voir ci-dessous les points [M2] et suivants).

[LIV1] Pour produire le registre des traitements il faut établir les liens entre les traitements (et leurs finalités), les acteurs (et leurs habilitations), les données (et leur qualification éventuelle Données Personnelles ou DP sensibles), les applications et les dispositifs de maîtrise de risques (DMR) en vigueur. Par rapport à la norme BPMN, seuls les derniers éléments devront être complétés : les applications et les risques, eux-mêmes reliés aux dispositifs de maîtrise de risques. Si quelques compléments s’imposent, comme l’identification de rôles précis tels que le DPO, le responsable de traitement ou les sous-traitants RGPD, la plupart des informations requises sont probablement déjà disponibles, sous une forme ou sous une autre, dans votre référentiel processus.

[LIV2] Enfin, le référentiel devra porter les processus requis par le RGPD :

• concevoir une application ou un traitement. Il s’agira de prendre en compte la protection des données personnelles dès la conception : minimisation de la collecte de données au regard de la finalité, cookies, durées de conservation, mentions d’information, recueil du consentement, sécurité et confidentialité des données, rôle et responsabilité des acteurs impliqués ;
• traiter les réclamations et les demandes des personnes concernées quant à l’exercice de leurs droits : droits d’accès, de rectification, d’opposition, droit à la portabilité, retrait du consentement ;
• mais aussi l’ensemble des activités visant à documenter la conformité au RGPD.