Le registre des traitements comme outil de sécurité

Éditorial

Le registre des activités de traitement exigé par le RGPD est presque toujours tenu comme une pièce administrative. C'est pourtant, dans beaucoup d'organisations, la seule cartographie des données qui existe, et la sécurité aurait tout intérêt à s'en emparer.

Mis à jour le 25 septembre 2026~27 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Un tableur que personne n’ouvre

Il existe, dans la plupart des organisations qui ont pris le RGPD au sérieux pendant au moins une semaine, un document dont tout le monde connaît l’existence et que personne n’a lu. Ce n’est pas la charte informatique, qui a au moins été signée. C’est le registre des traitements.

Sa biographie est d’une régularité touchante. Il a été rédigé dans l’urgence, à l’approche d’une échéance, par une personne à qui l’on avait confié « la conformité » comme on confie la plante verte du service à celui qui a eu le malheur d’être assis à côté. Il a pris la forme d’un tableur, ou d’une fiche dans un outil acheté pour l’occasion et dont la licence a été renouvelée depuis par inertie. Il a été rempli à partir d’entretiens avec des métiers pressés, relu une fois, rangé. Il ressort à peu près tous les deux ans, quand un client pose une question ou qu’un auditeur passe, et retourne dormir aussitôt, avec la sérénité des documents qui savent qu’ils ne seront pas vérifiés. Personne, côté technique, ne l’a jamais ouvert. Côté technique, on ignore souvent qu’il existe, ce qui a le mérite de la cohérence.

Ce n’est pas de la négligence, c’est de la logique. Le registre est présenté comme une obligation documentaire : une pièce qu’on doit pouvoir produire si l’autorité la demande. Tout ce qui est conçu pour être produit sur demande finit optimisé pour cette seule demande. C’est le destin de toute pièce justificative : elle justifie, elle ne sert pas.

La thèse de cet éditorial dérangera un peu les deux camps, ce qui me paraît de bon augure. Le registre des traitements est, dans une grande partie des organisations, la seule cartographie des données qui existe réellement. Pas la meilleure, pas la plus exacte : la seule. L’équipe sécurité, qui réclame une cartographie depuis qu’elle existe, en possède déjà une ébauche, rédigée par quelqu’un d’autre, dans un format qu’elle ne lit pas, à deux bureaux du sien. Et la personne qui tient le registre ignore que son document pourrait être le point de départ de l’analyse de risque, de la politique de conservation, de la gestion des sous-traitants et de la réponse à incident. Deux gaspillages symétriques, qui se croisent en comité tous les trimestres sans se reconnaître.

Ce que le registre contient, et ce qu’il tait

Regardons l’objet tel que le texte le décrit, avant de lui prêter des vertus.

Le RGPD, dans son article 30, demande au responsable de traitement de tenir un registre de ses activités de traitement, et au sous-traitant d’en tenir un pour ce qu’il traite pour le compte d’autrui. Pour chaque activité, le registre du responsable indique en substance la finalité, les catégories de personnes concernées et les catégories de données, les destinataires, les transferts hors de l’Union le cas échéant, les délais prévus pour l’effacement lorsque c’est possible, et une description générale des mesures de sécurité lorsque c’est possible. Le texte ménage une exception pour les petites structures, assortie de conditions qui la rendent plus étroite qu’on ne l’espère en la lisant vite ; son périmètre exact est une affaire de juristes, et je m’en voudrais de leur voler ce plaisir.

Relisez maintenant cette liste avec des yeux de responsable de la sécurité. Elle dit quoi, sur qui, pourquoi, à qui cela part, combien de temps cela reste et comment c’est protégé. C’est, à quelques mots près, le questionnaire du premier atelier d’une analyse de risque, et celui de la première heure d’un incident. Le législateur a écrit un formulaire de sécurité en croyant écrire un formulaire administratif ; ce n’est pas la première fois qu’un texte est plus intelligent que l’usage qu’on en fait.

Ce que le registre tait est tout aussi instructif. Il ne dit pas où sont les données : ni serveur, ni base, ni application, ni compte de stockage. Il ne dit pas par où elles passent : ni flux, ni interface, ni export. Il ne dit pas qui y accède au sens technique : ni groupe, ni rôle, ni compte de service. Le texte ne l’interdit pas, il ne le demande pas, parce que son objet est le traitement comme activité, pas le système comme tuyauterie.

Tout le problème est là. Le registre est une carte par finalité ; la sécurité raisonne par actif. Ce sont deux projections du même territoire, et aucune ne suffit seule. Une carte par actif sans finalités sait qu’une base existe et ignore pourquoi, donc ignore si elle devrait encore exister. Une carte par finalité sans actifs sait pourquoi l’on traite et ignore où, donc ignore où frapper le jour où il faut agir. L’une a la boussole, l’autre a le terrain, et elles refusent de voyager ensemble.

La seule carte qui existe

Affirmer que le registre est souvent la seule cartographie peut sembler provocant. Il suffit pourtant de passer en revue les autres pour constater qu’elles ont toutes des angles morts plus larges que lui, ce qui n’est pas un compliment pour le registre, mais c’en est encore moins un pour elles.

L’inventaire technique (outil de gestion de parc, base de configuration, liste des applications) connaît les serveurs et les logiciels, rarement ce qu’ils contiennent. Il sait qu’une base tourne sur tel hôte ; il ne sait pas qu’elle héberge les dossiers disciplinaires de tout le personnel. Pour lui, un fichier de paie et un fichier de test ont exactement le même poids, qui est celui de leur taille sur disque.

La cartographie applicative, quand elle existe, décrit les applications et leurs échanges. Elle est plus proche de ce qu’il faudrait, mais elle ignore superbement tout ce qui n’est pas une application : le tableur partagé qui sert de base clients à l’équipe commerciale depuis que le logiciel de gestion est « trop lourd », l’export mensuel envoyé par courriel au cabinet comptable, le dossier réseau où s’accumulent pieusement les pièces justificatives de la décennie. C’est dans ces interstices que vit une bonne partie des données personnelles, avec la discrétion des choses qu’aucun schéma d’architecture n’a jamais daigné dessiner.

Les outils de découverte automatique trouvent des données, pas des traitements. Ils répondent avec zèle à « où y a-t-il des numéros de sécurité sociale ? » et restent muets devant « pourquoi sont-ils là ? ». Ils produisent une liste d’occurrences sans intention, comme un détecteur de métaux produit une liste de capsules de bière.

Le registre, lui, a été construit par la seule méthode qui capture l’intention, et qui est aussi la plus archaïque : demander aux gens ce qu’ils font. C’est sa faiblesse (il ne sait que ce qu’on lui a dit, il y a quelques années) et sa force irremplaçable : il est le seul document qui relie une donnée à une raison d’exister, donc le seul qui permette de juger si elle est à sa place.

Supposons une PME de quarante personnes, sans équipe sécurité, dont une collaboratrice a hérité de la conformité en même temps que du classeur des tickets restaurant. Son inventaire technique se résume à la facture du prestataire. Si elle a un registre, même bancal, c’est le seul endroit où il est écrit qu’elle conserve les pièces d’identité de ses clients, qu’elle confie sa paie à un prestataire et que sa facturation est hébergée chez un éditeur. Tout ce qu’elle sait de son exposition tient dans ce document. Qu’il soit rangé dans « juridique » plutôt que dans « sécurité » est un accident d’arborescence, pas une propriété de l’objet.

Du registre à l’analyse de risque

Toute analyse de risque commence par la même question, quelle que soit la méthode et quel que soit le prix du consultant : qu’est-ce qui a de la valeur, et pour qui ? Les méthodes par scénarios, comme EBIOS RM, parlent de valeurs métier et de biens supports ; d’autres, d’actifs primaires et secondaires. Le vocabulaire change à chaque génération de méthode, ce qui entretient la profession ; la structure ne change pas : on part de ce que l’organisation fait, puis on descend vers ce sur quoi elle s’appuie pour le faire.

Les finalités du registre sont des valeurs métier déjà formulées. « Gestion de la paie », « suivi des candidatures », « relation client », « vidéoprotection des locaux » : chacune de ces lignes est une activité dont l’organisation a besoin, avec des personnes et des données identifiées. L’atelier qui consiste à les faire émerger, le plus pénible d’une analyse de risque parce qu’il faut réunir des métiers qui ont tous mieux à faire, a déjà eu lieu une fois. Il est incomplet et daté, mais corriger une liste existante est incomparablement plus rapide que contempler une page blanche en attendant que le directeur financier finisse sa réunion précédente.

Le registre apporte ensuite ce que les méthodes de risque traitent parfois avec une certaine gêne : la gravité vue depuis les personnes. Une fuite de données de mineurs, de coordonnées bancaires ou de données qui permettent de localiser quelqu’un n’a pas la gravité d’une fuite d’annuaire professionnel, et cette gravité ne se mesure pas qu’en chiffre d’affaires. La catégorisation exigée par le registre est une échelle de gravité toute prête, qui s’ajoute utilement au triptyque disponibilité, intégrité, confidentialité, lequel a le défaut de ne jamais demander qui souffre.

Dans l’autre sens, l’analyse de risque devrait nourrir le registre. La rubrique des mesures de sécurité est presque toujours remplie de formules d’une vacuité admirable (« accès restreint », « sauvegardes régulières », « chiffrement ») qui ne disent rien et ne peuvent être démenties par rien, ce qui est précisément leur fonction. Une analyse qui a identifié, pour une finalité, les scénarios redoutés et les mesures retenues produit ce qu’il faudrait écrire à cet endroit : des mesures rattachées à des risques, donc des mesures dont on peut dire si elles existent, si elles fonctionnent et si elles suffisent. C’est moins confortable, évidemment.

Il existe enfin un point de jonction officiel : l’analyse d’impact relative à la protection des données, que le RGPD exige pour les traitements susceptibles d’engendrer un risque élevé pour les personnes. Les organisations qui la conduisent à part de leur analyse « sécurité » font deux fois le même travail dans deux vocabulaires, et découvrent parfois des conclusions contradictoires sur le même système, ce qui a au moins le mérite d’occuper une réunion. Le registre est le bon endroit pour faire le lien : chaque ligne peut porter la référence des analyses qui la concernent.

Les durées de conservation, ou la surface d’attaque datée

De toutes les rubriques du registre, la plus négligée est celle des délais d’effacement. On la remplit d’une formule prudente (« durée de la relation commerciale plus trois ans », « conformément aux obligations légales »), puis on l’oublie avec le soulagement du devoir accompli. Personne ne vérifie qu’un mécanisme applique la durée écrite. Écrire une durée de conservation est à la conservation ce qu’une bonne résolution de janvier est au régime : un acte de langage.

C’est dommage, parce que cette rubrique est la seule mesure de sécurité du registre qui réduise le risque à la source. Toutes les autres protègent des données qui existent ; celle-ci diminue la quantité de données qui existent. Une donnée effacée à l’échéance ne fuit pas, ne se fait pas chiffrer par un rançongiciel, ne se corrèle avec rien, ne se notifie à personne. Elle a atteint la seule forme de sécurité parfaite, qui est l’inexistence. L’éditorial consacré à ce qu’on garde le montrait à propos des journaux de sessions : l’utilité décroît vite, le risque ne décroît pas. Ce qui vaut pour un corpus de transcripts vaut pour une base clients, qui a simplement meilleure réputation.

Le registre permet de poser la question en termes exploitables. Pour chaque finalité, une durée écrite. Pour chaque durée écrite : quel mécanisme l’applique, et où en est la preuve ? Les réponses tombent dans quatre catégories, que je donne par ordre de fréquence décroissante chez ceux qui ne se sont jamais posé la question.

Aucun mécanisme. La durée est écrite, rien ne l’applique. La base contient des enregistrements plus anciens que la mémoire collective de l’organisation. Le registre décrit une intention, pas un état ; c’est un horoscope.
Un mécanisme dans l’application principale, et nulle part ailleurs. Le logiciel purge ses enregistrements avec une rigueur exemplaire, pendant que les exports, les copies de travail, les environnements de recette alimentés avec des données réelles et les sauvegardes conservent tout. L’effacement est réel dans un lieu et décoratif dans tous les autres.
Un mécanisme partout sauf dans les sauvegardes. Cas honnêtement difficile : les sauvegardes ont leurs propres durées, fixées pour d’autres raisons, et l’on n’efface pas un enregistrement isolé dans une sauvegarde. La réponse acceptable est souvent une rétention des sauvegardes compatible avec la durée de conservation, documentée comme telle, et un processus qui empêche une restauration de ressusciter des données déjà effacées. Les morts qui reviennent sont un genre littéraire, pas une politique de sauvegarde.
Un mécanisme cohérent et vérifiable. Rare, et presque toujours l’œuvre de quelqu’un qui a eu l’idée saugrenue de relier la ligne du registre au système concerné.

Il y a là une alliance naturelle laissée en friche. La personne chargée de la protection des données a la légitimité pour exiger l’effacement ; l’équipe technique a les moyens de l’appliquer et un intérêt direct à réduire la surface exposée. Chacune tient l’autre pour un obstacle, et elles ont toutes deux raison, ce qui est la configuration idéale pour ne rien faire.

Les sous-traitants : la frontière réelle du système d’information

La rubrique des destinataires est la plus précieuse du registre pour la sécurité, et celle dont on tire le moins, ce qui est dans l’ordre des choses.

Le système d’information d’une organisation contemporaine ne s’arrête pas à ses murs, ni même à ses comptes chez un fournisseur d’informatique en nuage. Il s’étend à tous les tiers à qui elle confie des données : l’éditeur de paie, le service d’envoi de courriels, l’outil de support client, la plateforme de signature électronique, le cabinet comptable, l’hébergeur du site, la plateforme de recrutement. Chacun est, du point de vue d’un attaquant, une porte d’entrée vers les données de l’organisation qui ne passe par aucun de ses contrôles. On blinde la porte d’entrée et l’on distribue des doubles des clés à tous les livreurs du quartier.

La liste des sous-traitants est une approximation très honnête de la liste des tiers qui détiennent quelque chose de sensible. Elle n’est pas exhaustive (un tiers peut détenir des secrets industriels sans la moindre donnée personnelle), mais elle est souvent plus complète que ce dont dispose l’équipe sécurité, pour une raison prosaïque : l’article 28 du RGPD impose un contrat avec chaque sous-traitant, et un contrat laisse une trace qu’un abonnement pris un vendredi soir avec la carte bancaire du service ne laisse pas.

Exploiter cette liste, c’est lui poser trois questions qu’elle ne se pose pas toute seule.

Quel accès ce tiers a-t-il, et par quel chemin ? Un prestataire qui reçoit un export mensuel et un prestataire qui dispose d’un compte administrateur permanent ne présentent pas le même risque, même s’ils traitent les mêmes catégories de données. Le registre dit que les données partent ; il faut savoir comment, et si le chemin est ouvert dans l’autre sens.

Que se passe-t-il si ce tiers est compromis ? Pas « est-il sûr ? », question à laquelle personne ne peut répondre honnêtement et à laquelle tout le monde répond quand même, questionnaire à l’appui. Plutôt : quelles données seraient exposées, quels accès faudrait-il couper, quels secrets faudrait-il changer, et qui préviendrait qui ? Les compromissions de prestataires comptent parmi les scénarios les plus documentés publiquement, et elles ont en commun de surprendre, non parce que le risque était inconnu, mais parce que personne n’avait écrit à l’avance ce qui dépendait du tiers.

Qui sont les sous-traitants du sous-traitant ? Le RGPD encadre la sous-traitance ultérieure, mais le registre du responsable ne la décrit généralement pas. L’éditeur héberge chez un fournisseur d’infrastructure, confie ses notifications à un tiers, son support à un autre. On croit avoir un fournisseur ; on a une généalogie.

La liste des sous-traitants est enfin celle des contrats où l’on peut exiger des engagements de sécurité : délai de notification des incidents, droit d’audit, sort des données en fin de contrat. Après la signature, on ne négocie plus, on espère.

Le jour de l’incident

C’est le jour où l’on mesure ce que vaut une cartographie, et celui où le registre tenu comme pièce administrative révèle sa vraie nature, qui est décorative.

Supposons un scénario d’une banalité réconfortante. Un compte de service, utilisé par un outil d’intégration, a été compromis. L’équipe qui répond sait quelles machines l’attaquant a touchées, quels partages il a parcourus, quelles bases il a interrogées ; elle le sait parce que les journaux le disent, à supposer qu’ils existent et aient été conservés, ce qui est un autre dossier. Ce qu’elle ne sait pas, c’est ce que contenaient ces lieux, et ce que cela implique.

Or c’est exactement la question qui presse. L’article 33 du RGPD impose au responsable de notifier une violation de données personnelles à l’autorité de contrôle dans les meilleurs délais et, si possible, dans les soixante-douze heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes. D’autres textes, selon le secteur et la nature de l’organisation, ajoutent leurs propres notifications, avec leurs propres délais et leurs propres destinataires ; NIS 2 en est un exemple, dont les modalités de transposition doivent être vérifiées auprès des sources nationales. Soixante-douze heures, c’est long pour une réunion et très court pour découvrir ce que l’on possède.

Pour notifier, il faut pouvoir dire, même approximativement, quelles catégories de personnes sont concernées, quelles catégories de données, combien d’enregistrements, quelles conséquences probables, quelles mesures prises. Ce sont, presque mot pour mot, les rubriques du registre. Une équipe capable de passer de « l’attaquant a lu cette base et ce partage » à « ce qui correspond aux traitements X et Y, qui concernent des salariés et des candidats, avec identités et coordonnées bancaires, conservées depuis telle date » gagne des heures, parfois des jours, sur une échéance qui n’en laisse guère.

Encore faut-il que le registre porte, pour chaque traitement, la liste des lieux où résident ses données. Sans ce lien, l’équipe reconstitue la correspondance au moment précis où elle a le moins de temps pour le faire, pendant que l’incident, lui, ne s’interrompt pas pour la laisser réfléchir.

Le registre sert aussi à délimiter. Une notification qui déclare tout concerné faute de savoir ce qui ne l’est pas a un coût réel, pour les personnes inquiétées à tort comme pour la crédibilité de l’organisation. Pouvoir dire « ce traitement n’a pas pu être touché, parce que ses données résident uniquement dans tel système, inaccessible depuis le compte compromis » vaut autant que de pouvoir dire ce qui l’a été. La modestie, en réponse à incident, est une compétence technique.

Faire vivre la carte

Admettons que le registre puisse devenir un outil de sécurité. Reste à savoir quoi y ajouter, et comment le maintenir sans en faire un second projet de cartographie promis au même avenir radieux que le premier.

Ajouter peu, mais les bonnes colonnes

La tentation est d’y verser tout ce que la sécurité voudrait savoir. C’est le moyen le plus sûr de le rendre intenable, puis intenu. Quelques champs suffisent, qui font le pont entre la vue par finalité et la vue par actif. À titre d’illustration, quel que soit l’outil qui la porte :

traitement: "Gestion de la paie"
finalite: "Calcul et versement des salaires, déclarations sociales"
personnes: ["salariés", "anciens salariés"]
donnees: ["identification", "coordonnées bancaires", "numéro de sécurité sociale"]
duree_conservation: "selon obligations légales, à préciser avec le conseil"
# Partie « sécurité » de la ligne
lieux:
  - "application de paie (éditeur, hébergée)"
  - "partage RH, dossier des exports mensuels"
  - "sauvegardes du partage RH"
destinataires_techniques:
  - nom: "éditeur de paie"
    acces: "hébergement complet, support avec accès aux données"
  - nom: "cabinet comptable"
    acces: "export mensuel par transfert de fichiers"
mecanisme_effacement: "aucun sur le partage ; purge éditeur non vérifiée"
analyse_risque: "référence de l'analyse, date de dernière revue"
proprietaire_technique: "une personne nommée, pas une équipe"

Trois de ces champs font l’essentiel du travail. Les lieux, qui permettent de passer d’un traitement à des systèmes et, surtout, d’un système compromis aux traitements concernés. Le mécanisme d’effacement, qui transforme une durée déclarée en question vérifiable. Le propriétaire technique, parce qu’une ligne dont le propriétaire est « l’équipe infrastructure » appartient en pratique à personne, cette entité n’ayant jamais été vue en train de mettre un document à jour.

Attacher la mise à jour à des événements

Un registre revu « annuellement » est revu jamais, ou revu mal, par quelqu’un qui ne dispose d’aucune information nouvelle et qui change donc la date en haut de la page. Les moments où le registre se périme sont pourtant connus : arrivée d’une application, signature d’un contrat avec un prestataire, migration d’un système, création d’un flux d’export, fin d’une activité. Chacun passe déjà par un processus : un achat, un projet, une demande de changement, une ouverture de flux. C’est dans ces processus qu’il faut glisser la question du registre, pas dans un rappel de calendrier que tout le monde repousse d’une semaine, cinquante-deux fois.

Rendre la carte lisible par les outils

Le registre n’a pas besoin de devenir un outil de sécurité ; il a besoin d’être lisible par les outils de sécurité. Si l’inventaire technique connaît les systèmes et que le registre connaît les traitements, une table de correspondance suffit pour que la plateforme de supervision, un SIEM par exemple, enrichisse une alerte sur un serveur avec les traitements qu’il porte. « Accès inhabituel au serveur de fichiers » et « accès inhabituel au partage qui contient la paie de tous les salariés » ne reçoivent pas la même attention à trois heures du matin, et ne le devraient pas.

La même correspondance oriente les choix de protection. Le chiffrement des données au repos, le cloisonnement, la journalisation renforcée, le contrôle d’accès plus strict coûtent quelque chose ; le registre dit où ce coût se justifie, parce qu’il dit où dorment les catégories de données les plus sensibles.

Le meilleur argument contre

Il serait malhonnête de conclure sans exposer la meilleure objection à ce qui précède, et elle est sérieuse.

Mélanger conformité et sécurité abîme les deux. Le registre est un document que l’organisation peut être amenée à produire devant l’autorité de contrôle. Y inscrire des informations de sécurité détaillées (lieux exacts, faiblesses connues, absence de mécanisme d’effacement) revient à rédiger, dans un document destiné à être montré, la liste circonstanciée de ses propres manquements. Aucun juriste raisonnable ne le conseillera à la légère, et aucun juriste déraisonnable ne restera longtemps en poste. Par ailleurs, un registre enrichi devient lui-même une cible : la carte de toutes les données sensibles, avec leurs emplacements et leurs points faibles, est exactement ce qu’un attaquant voudrait trouver en premier. On lui aurait épargné la reconnaissance.

Seconde objection, plus culturelle. La conformité cherche à démontrer ; la sécurité cherche à découvrir. Un document conçu pour démontrer tend à lisser ce qui dérange ; un document conçu pour découvrir doit au contraire l’exhiber. Les faire partager le même support, c’est parier que la logique de découverte l’emportera, et l’histoire des organisations suggère de ne pas miser gros.

Ces objections me paraissent justes, et elles ne réfutent pas la thèse ; elles en précisent la forme. Ce qu’il faut partager, ce n’est pas le document, c’est le découpage. Le registre présenté à l’autorité peut rester ce qu’il est : les rubriques du texte, remplies honnêtement. La partie technique (lieux, accès, mécanismes, faiblesses) vit ailleurs, avec la classification et les droits d’accès qui conviennent à une information aussi sensible, et elle est indexée sur les mêmes identifiants de traitement. Deux vues, un seul référentiel. C’est assez pour passer de l’une à l’autre le jour de l’incident, et cela évite de consigner ses faiblesses dans une pièce faite pour circuler.

Quant à la tension entre démontrer et découvrir, elle se gère en confiant la vue technique à ceux qui devront s’en servir quand tout ira mal. L’intérêt personnel reste le meilleur garant de l’exactitude documentaire ; c’est triste, mais c’est fiable.

Ce que je ne sais pas

Je ne sais pas quelle part des registres existants est exploitable. Tout cet éditorial suppose un registre imparfait mais réel. Il est possible qu’une part importante de ceux des petites structures soit si générique (modèles remplis à la hâte, finalités recopiées d’un exemple trouvé en ligne) qu’il n’y ait rien à en tirer, et qu’il faille repartir des entretiens. Je n’ai aucune mesure de cette proportion, et je me méfie de quiconque prétend en avoir une solide, surtout s’il vend l’outil qui règle le problème.

Je ne sais pas si la bonne granularité existe. Un traitement trop large ne délimite rien ; un traitement trop fin multiplie les lignes jusqu’à l’illisible. Celle qui sert l’autorité et celle qui sert la réponse à incident ne coïncident probablement pas, et je n’ai pas de règle.

Je ne sais pas comment ce raisonnement survivra à la découverte automatique. Les outils qui détectent et classifient les données personnelles progressent. Ils finiront peut-être par produire, à partir de l’infrastructure, une carte plus exacte que tous les entretiens du monde, et le registre deviendrait alors une vue dérivée plutôt qu’une source. Je crois qu’il leur manquera toujours la finalité, la raison pour laquelle une donnée est là ; mais c’est une croyance de papy, pas un résultat.

Je ne sais pas comment évoluera l’articulation des textes. RGPD, NIS 2, réglementations sectorielles, textes européens plus récents sur la résilience et l’intelligence artificielle : ils se recouvrent partiellement, chacun avec ses exigences d’inventaire et de notification. Une convergence rendrait un jour cet éditorial évident ; une divergence le rendrait plus pénible. Sur ce terrain, la seule attitude raisonnable est de vérifier régulièrement auprès des sources officielles, en commençant par l’autorité de contrôle.

Ce qui reste

L’éditorial tient en une phrase : la sécurité cherche une carte que la conformité a déjà commencé à dessiner, et aucune des deux ne le sait.

Trois choses me semblent acquises. Que le registre est une cartographie par finalité, et que cette vue manque cruellement à une sécurité qui ne sait raisonner que par actif : les deux ne valent qu’ensemble. Que les durées de conservation sont la seule mesure du registre qui réduise le risque à la source, et qu’elles ne valent que si un mécanisme les applique partout où les données se trouvent, sauvegardes comprises. Et que le jour de l’incident, les rubriques du registre sont les questions de la notification, ce qui en fait, pour peu qu’il soit relié aux systèmes, le premier outil de la réponse plutôt qu’un document qu’on cherche fébrilement dans un partage dont personne ne se rappelle le nom.

Ce qui manque n’est ni un outil ni une méthode ; le marché en regorge, et il vous le fera savoir. C’est une conversation entre deux fonctions qui se croisent en comité et ne se parlent jamais de leurs documents. Le registre y gagnerait une exactitude qu’aucun contrôle ne lui donnera, la sécurité une carte qu’aucun projet de cartographie ne lui a jamais livrée. Et les données qu’ils décrivent tous deux, qui survivent aux systèmes comme aux organigrammes, auraient enfin le privilège rare d’être connues de ceux qui sont censés les protéger.

🐝 Ce qui arrive si on s’en passe

Tenu comme une simple pièce justificative, le registre laisse l’organisation déclarer ce qu’elle croit avoir perdu plutôt que ce qu’elle a réellement perdu. Un traitement absent de la liste, dont les données dormaient sur le partage compromis, n’entre dans aucune notification : les personnes concernées ne sont pas prévenues et ne peuvent ni surveiller leurs comptes ni faire opposition, et sa découverte ultérieure impose une seconde notification, tardive, qui dit surtout que la première était fausse. Pendant ce temps, le délai de soixante-douze heures s’écoule à reconstituer à la main une carte qui aurait dû exister.

🦫 Explication de la marmotte 🍫

Le règlement européen sur la protection des données oblige les organisations à tenir un registre de leurs traitements de données personnelles. Pour chaque activité, comme la paie ou le recrutement, ce registre indique le but poursuivi, les personnes concernées, les types de données, qui les reçoit, si elles quittent l’Union européenne, combien de temps elles sont gardées et comment elles sont protégées. Ces rubriques correspondent presque exactement aux questions d’une analyse de risque et à celles qu’il faut résoudre après une attaque. Le registre a pourtant un manque : il décrit pourquoi on traite les données, mais pas où elles se trouvent techniquement, sur quels serveurs, dans quels fichiers, ni qui y accède. L’éditorial propose d’y relier quelques informations techniques : les lieux de stockage, l’accès réel de chaque prestataire, le mécanisme qui efface les données à l’échéance, et une personne responsable. Ces informations peuvent vivre dans un document séparé, mieux protégé, relié au registre par les mêmes identifiants. Grâce à ce lien, on vérifie que les durées de conservation sont vraiment appliquées, y compris dans les sauvegardes, puisqu’une donnée effacée ne peut plus fuir. On mesure aussi ce que chaque prestataire détient. Et après une attaque, on passe rapidement des systèmes touchés aux données concernées, ce qui permet de prévenir l’autorité de contrôle dans le délai de soixante-douze heures avec des informations exactes. Pour rester juste, le registre se met à jour à chaque changement : nouveau projet, nouveau contrat, migration.

Pages voisines

La citent

Le registre des traitements comme outil de sécurité

Elle cite

Le registre des traitements comme outil de sécurité

Un tableur que personne n’ouvre

Ce que le registre contient, et ce qu’il tait

La seule carte qui existe

Du registre à l’analyse de risque

Les durées de conservation, ou la surface d’attaque datée

Les sous-traitants : la frontière réelle du système d’information

Le jour de l’incident

Faire vivre la carte

Ajouter peu, mais les bonnes colonnes

Attacher la mise à jour à des événements

Rendre la carte lisible par les outils

Le meilleur argument contre

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines