Piloter les risques et traiter un incident de données

Un risque se décrit par ses effets sur les personnes

Le risque ne se limite pas à la panne ou à l’attaque informatique. Une donnée inexacte peut provoquer une décision défavorable ; un accès trop large peut révéler une situation familiale ; une conservation excessive peut maintenir des informations sans nécessité. La description doit préciser l’événement, les personnes concernées, les conséquences possibles et les mesures qui réduisent sa probabilité ou sa gravité. Un classement élevé sans explication n’aide pas à choisir les protections.

Les principes de l’article 5 du RGPD fournissent une première grille : finalité, minimisation, exactitude, durée, sécurité et capacité de démontrer la conformité. Ils permettent de repérer un risque avant même de choisir une mesure technique. Si une pièce ne sert pas à la finalité, la meilleure réponse peut être de ne pas la collecter. Chiffrer cette pièce réduit certains risques sans résoudre l’absence de nécessité. ^[1]

L’article 32 demande des mesures appropriées au risque, en prenant en compte notamment l’état des connaissances, les coûts, la nature et le contexte du traitement. Il vise également la capacité à rétablir la disponibilité et l’accès et une procédure permettant de tester et d’évaluer régulièrement l’efficacité des mesures. Le suivi doit donc vérifier que la protection fonctionne, et pas seulement constater qu’une fonctionnalité de sécurité existe dans le contrat. ^[3]

Le service doit définir les événements qui imposent une révision : nouvelle catégorie de données, nouveau destinataire, changement d’architecture, extension des utilisateurs ou incident. Une revue périodique peut compléter ce circuit, mais elle ne doit pas retarder le traitement d’un changement significatif. Le registre et les documents de conception doivent être mis à jour de manière cohérente avec les opérations réellement réalisées.

Décider si une analyse d’impact est nécessaire

L’article 35 prévoit une analyse d’impact lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés, compte tenu notamment de sa nature, de sa portée, de son contexte et de ses finalités. Le recours à une nouvelle technologie peut participer à cette appréciation, mais le raisonnement ne consiste pas à imposer automatiquement une analyse complète à tout outil nouveau. Il faut qualifier les opérations et les conséquences prévisibles. ^[3]

L’analyse doit décrire le traitement, examiner sa nécessité et sa proportionnalité, apprécier les risques et présenter les mesures envisagées. Le DPO apporte un conseil dans les conditions prévues par le règlement. Le responsable demeure chargé de la décision et des mesures. Un document établi par le fournisseur peut fournir des éléments, sans suffire à décrire le contexte propre d’un organisme, ses personnes concernées et ses usages.

Une analyse d’impact n’est pas une autorisation générale de poursuivre. Si un risque élevé demeure dans les conditions prévues par l’article 36, une consultation préalable de l’autorité doit être examinée. Cette étape ne peut être remplacée par une acceptation interne purement formelle. L’équipe distingue donc le risque initial, les effets des mesures et le risque résiduel, en conservant les raisons de son appréciation. ^[3]

Le suivi de l’analyse est également prévu par l’article 35 : lorsque le risque présenté par les opérations évolue, un examen peut être nécessaire. Le document doit être réutilisable. Une description abstraite des risques informatiques ne permet pas de comprendre ce qui change lorsqu’un portail initialement destiné à des démarches simples commence à recevoir des pièces de santé ou des décisions relatives à des aides.

Un accès indu à des dossiers d’aide

Le cas est fictif. Un portail municipal permet de déposer des demandes d’aide. Après une mise à jour, un agent constate qu’un lien de téléchargement affiche une pièce appartenant à un autre dossier. L’équipe technique isole dix-huit documents potentiellement accessibles. Certains comprennent des coordonnées et des éléments financiers ; les journaux disponibles ne permettent pas immédiatement de déterminer toutes les consultations. Les nombres servent à travailler la méthode, sans décrire un incident réel.

La première action est de contenir l’exposition : désactiver le mécanisme défectueux ou limiter l’accès, préserver les traces utiles et maintenir un canal permettant le dépôt des demandes. L’arrêt technique ne suffit pas à qualifier les conséquences. Une équipe identifiée rassemble les faits : moment de découverte, période concernée, catégories de données, personnes, accès possibles, téléchargements observés et mesures prises. Elle conserve séparément ce qui est établi et ce qui reste incertain.

L’article 33 prévoit la notification à l’autorité dans les meilleurs délais et, si possible, au plus tard soixante-douze heures après la prise de connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés. Ce délai ne signifie pas que toute anomalie technique doit automatiquement être notifiée ; il exige une qualification rapide et documentée. Si toutes les informations ne sont pas disponibles, le texte permet une transmission échelonnée dans les conditions prévues. ^[3]

Dans le scénario, la nature des documents et l’incertitude sur les accès conduisent l’équipe à examiner sérieusement le risque, au lieu de supposer que l’absence de plainte prouve l’absence de conséquence. Le fournisseur apporte les éléments techniques et remédie au défaut. Le responsable du traitement décide, avec les experts compétents, des suites à donner. Il ne peut considérer que la notification relève exclusivement du fournisseur au seul motif que celui-ci a développé la fonction.

L’article 34 prévoit l’information des personnes lorsque la violation est susceptible d’engendrer un risque élevé, avec les exceptions qu’il définit. Ce seuil doit être distingué de celui de la notification à l’autorité. Une information des personnes n’est donc pas la conséquence automatique de toute notification. Dans le cas travaillé, l’équipe examine les possibilités de préjudice, les mesures de protection déjà effectives et les actions que les personnes pourraient utilement accomplir. ^[3]

La communication éventuelle décrit la nature de l’incident, les conséquences possibles et les mesures pertinentes dans des termes clairs. Elle ne promet pas une absence de risque qui n’est pas démontrée. Elle évite également de diffuser publiquement les détails permettant de retrouver les dossiers concernés. Les interlocuteurs chargés de répondre disposent d’informations cohérentes ; ils distinguent les réponses générales des informations propres à chaque personne.

Corriger la cause et contrôler les accès

Le correctif technique est testé sur des dossiers fabriqués. Le scénario comprend un accès autorisé, un accès à un dossier voisin et un lien ancien. La vérification porte sur les droits au niveau du document, et pas seulement sur la connexion à l’application. Le service vérifie ensuite les autres fonctions reposant sur le même mécanisme. Un incident limité à un lien peut révéler une faiblesse plus générale dans la manière de contrôler les accès.

La revue des habilitations examine les profils, les comptes inactifs et les accès de maintenance. Elle doit correspondre aux missions réelles. Un agent chargé de recevoir une demande peut avoir besoin d’un statut de dossier sans avoir besoin de consulter toutes les pièces. L’article 25, relatif à la protection dès la conception et par défaut, soutient ce choix. Les droits minimaux doivent être portés par le fonctionnement de l’outil, pas seulement par une recommandation de discrétion. ^[3]

Les demandes des personnes continuent d’être traitées pendant l’incident. Une demande d’accès ou de rectification ne doit pas disparaître dans le circuit technique. Les articles 12 à 22 organisent les droits et les modalités pertinentes ; leurs limites et conditions doivent être examinées selon la demande. Le portail doit donc posséder un canal de secours pour recevoir et suivre ces échanges lorsque la fonction habituelle est indisponible. ^[2]

L’objection concerne le risque de sur-réaction. Une interruption générale peut empêcher les usagers d’accéder au service sans améliorer la protection. La décision de containment doit être proportionnée à ce qui est connu : isoler la fonction vulnérable, restreindre certains accès ou suspendre le traitement si les garanties ne peuvent être rétablies. Cette appréciation est actualisée à mesure que les faits deviennent disponibles ; elle ne justifie pas une attente sans mesure.

Le bilan transforme l’incident en décision de prévention

Le bilan ne se contente pas d’indiquer que le problème est résolu. Il précise la cause, les données et personnes concernées, les décisions de notification, les mesures prises et les contrôles restant à effectuer. Il distingue les faits de l’incident des hypothèses initiales. Le service examine aussi ce qui a permis ou retardé la découverte : qualité des journaux, circuit d’alerte, interlocuteurs du fournisseur et capacité à interrompre une fonction.

La réponse à la question initiale est d’organiser un suivi qui conduit à des décisions. Les risques guident les mesures ; l’analyse d’impact examine les traitements susceptibles de risque élevé ; l’incident déclenche une qualification et des actions documentées. Dans le cas fictif, le correctif du lien est nécessaire mais insuffisant : les habilitations, les traces et le circuit de réaction doivent également être contrôlés. La conformité devient ainsi une capacité à agir et à expliquer les choix dans le temps.