Adaptez votre cartographie applicative au DPO

Le RGPD et le rôle du DPO

Pourquoi fournir une cartographie applicative au DPO ?

Depuis plus de deux ans, les sociétés doivent définir un Data Privacy Officer, une personne responsable des traitements des données personnelles qu’elles utilisent. Ainsi, dans le cadre du Règlement Général sur la Protection des Données, cette personne doit être en mesure de gérer, lister, identifier et maîtriser tout type de traitement de ces données.

Pour cela, elle peut faire appel au responsable informatique de l’organisation pour obtenir la liste de ces applications pour ainsi identifier les traitements plus facilement.

Or, nous avons pu remarquer que le responsable informatique de l’organisation a parfois du mal ou n’est pas en mesure de fournir une liste complète et bonne des applications qui utilisent ces données personnelles.

La difficulté pour les responsables IT de donner une visibilité claire des applications déployées sur le parc et de l’emplacement des données

En effet, il arrive que les responsables IT aient des difficultés à donner une vision claire des applications. Pour répondre à cette problématique, il est possible de créer une cartographie applicative. Mais alors, comment le responsable IT peut fournir une cartographie applicative utile au DPO ?

La cartographie applicative pour aider le DPO

Une cartographie applicative liste l’ensemble des applications du parc informatique. Elle vise à établir un catalogue recensant le patrimoine applicatif de l’entreprise en soulignant les interactions entre applications ou composants d’applications, leur description ainsi que les données échangées.

La cartographie applicative permet donc de savoir quelles sont les applications de votre parc, où se trouvent-elles (serveur, PC), et ainsi permet d’identifier la localisation (l’utilisateur associée à la machine et le lieu où se trouve la machine). En fonction des pays, les droits et devoirs concernant l’utilisation des données peuvent être différents.

Il existe deux façons de constituer une cartographie applicative :

• Dans les grandes organisations, vous partez de très haut niveau et vous appliquez un plan d’occupation des salles grâce à un urbaniste du système d’information. Son rôle est de comprendre l’architecture métier, les besoins métiers et ainsi comprendre l’infrastructure. Par ailleurs, en partant du haut et descendant, vous pouvez avoir un fort décalage avec ce qui est déployé en réalité. (TOP DOWN)
• En partant du bas, vous pourrez réfléchir à quelles sont mes infrastructures, ce qu’il y a dessus, quelles sont les serveurs présents, les applications présentes. Cette démarche s’applique davantage à ceux qui n’ont pas les moyens d’avoir un urbaniste et qui n’ont pas forcément le temps (BUTTOM UP). En partant de l’existant, on regarde ce que l’on a au niveau des réseaux, puis quels sont les matériels présents, quelles sont mes applications et ainsi pouvoir les relier derrière aux besoins fonctionnels.

Chez Straton IT, nous utilisons pour notre produit Corrium, une démarche se rapprochant de la méthode OBASHI (Owner Business Applications System Hardware Infrastructure). En plus des domaines fonctionnels, des traitements, des applications, des systèmes, des matériels et réseaux, nous ajoutons la notion de sites et de bâtiments qui est très importante – la zone géographique étant très importante pour l’identification des données personnelles et la conformité RGPD. Puis, nous analysons quels sont les espaces de stockages, quelles sont les bases de données et où sont les applications pour analyser les traitements relatifs au RPGD. Enfin, nous analysons aussi les flux réseaux et identifions les flux applicatifs.

Pour illustrer à quoi ressemble et vous sert une cartographie applicative, voici ce schéma :

1. Liste des machines
2. Descriptif des applications présentes sur chaque machine (quelles applications, quelle version, …)
3. Catégorisation de chaque application (multimédia, sécurité, bureautique, …)

Ainsi vous pourrez identifier chaque application, valider ou non sa présence, avoir accès à l’emplacement de l’application (sur les machines précisément). Au niveau RGPD, la catégorie d’applications que vous allez considérer davantage est celle des bases de données.

Utiliser la cartographie applicative pour favoriser le travail du DPO

Voici une méthodologie pour identifier les applications concernées par le RGPD et ainsi localiser plus facilement la donnée.

Identifier le poids RGPD de chaque application

1. Pour cela, vous pouvez établir un scoring :

• 0 = N, l’application n’est pas concernée par le RGPD
• 1 = P, l’application est partiellement concernée par le RGPD
• 2 = L, l’application est largement concernée par le RGPD
• 3 = F, l’application est complètement concernée par le RGPD

2. Ensuite, vous déterminez la présence de chaque application (le taux de couverture).
3. Puis, vous pouvez mesurer l’éparpillement des versions des applications

• Homogénéité : vous disposez des mêmes versions d’applications (la cible étant 100%)
• Dilution : vous disposez d’un éparpillement des versions d’une application (la cible est 0%)

4. Ainsi vous saurez si vous êtes concernés ou pas

Identifier le poids des applications sur votre parc informatique

D’autres indicateurs globaux vous donneront de précieuses informations sur l’état de votre parc :

• Le taux d’uniformisation: permet de savoir si vous utilisez les mêmes applications, la même version. Il doit être le plus proche de 100%
• Le poids applicatif (RGPD) des machines: correspond à la somme des applications classées RGPD*leur coefficient RGPD (leur importance)
• Le contrôle des versions: via le taux de couverture, correspond au % de PC utilisant cette version de l’application

Constituer un classement des applications

A partir de différents critères, vous pourrez les classer selon des similitudes, les voici :

Les types d’applications à identifier

Cette liste est non-exhaustive mais vous permet d’identifier un certain nombre d’applications concernées :

• Bases de données (serveurs),
• Bases de données sur des postes (Access, Excel, …),
• Partages de fichiers,
• Drives,
• Outils de requêtage,
• Outil de reporting,
• Drivers ODBC,
• Outils d’administration de BDD,
• Transfert de données,
• …