Article 32 RGPD : les mesures techniques et organisationnelles qui résistent à un contrôle

L'article 32 du RGPD est le seul article du règlement qui exige des résultats plutôt que des documents, et le seul que presque toutes les organisations traitent comme une liste de courses. Le texte ne contient aucun catalogue de produits. Il contient quatre exemples, un test de risque et l'obligation de vérifier régulièrement que tout cela fonctionne encore. C'est exactement là que la documentation habituelle échoue : douze lignes copiées depuis 2018, sans nom de système, sans date, sans résultat mesuré. Or la CNIL ne vérifie pas que vous affirmez une mesure, elle vérifie que vous pouvez la démontrer — et la Cour de justice de l'Union européenne a jugé en décembre 2023 que cette charge de la preuve pèse sur vous. Ce guide décrit la procédure de décision que l'article 32 impose réellement, les preuves qu'un contrôle réclame et que vous ne pouvez probablement pas produire aujourd'hui, les points du chiffrement sur lesquels les auditeurs tirent en premier, l'arithmétique de la conservation des journaux face au délai de 72 heures, et la pratique de sanction de la CNIL telle qu'elle ressort de l'année 2025.

Ce que dit réellement l'article 32, avant que quiconque ne le paraphrase

Le paragraphe 1 impose au responsable du traitement et au sous-traitant de mettre en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Quatre facteurs entrent dans cette appréciation : l'état des connaissances, les coûts de mise en œuvre, la nature, la portée, le contexte et les finalités du traitement, ainsi que les risques dont le degré de probabilité et de gravité varie pour les droits et libertés des personnes physiques. Le texte énumère ensuite, « entre autres, selon les besoins », quatre mesures :

• a) la pseudonymisation et le chiffrement des données à caractère personnel ;
• b) des moyens permettant de garantir la confidentialité, l'intégrité, la disponibilité et la résilience constantes des systèmes et des services de traitement ;
• c) des moyens permettant de rétablir la disponibilité des données et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique ;
• d) une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures techniques et organisationnelles.

Quatre mots portent toute l'obligation. Entre autres signifie que la liste n'est pas limitative : « nous avons coché les quatre points » n'est pas une défense. Appropriées signifie que chaque mesure se mesure à l'analyse de risque, pas au catalogue. Constantes, dans le point b), exclut le projet avec une date de fin. Et régulièrement, dans le point d), exclut le test d'intrusion commandé une fois en 2023 pour répondre à un questionnaire client.

Le texte précise aussi les menaces que l'appréciation doit couvrir : la destruction, la perte, l'altération, la divulgation non autorisée de données, ou l'accès non autorisé à celles-ci, de manière accidentelle ou illicite. Ce qui n'y figure pas est instructif : pas un mot sur les attaquants. Un script de sauvegarde mal configuré qui écrase une table tombe sous le même article qu'un rançongiciel. Dimensionner ses mesures uniquement contre des attaquants revient à ignorer la moitié du texte.

Deux précisions complètent l'article. D'une part, l'application d'un code de conduite approuvé au titre de l'article 40 ou d'un mécanisme de certification approuvé au titre de l'article 42 peut servir d'élément pour démontrer le respect des exigences — un élément, pas un substitut. Une certification ISO 27001 atteste que vous exploitez un système de management ; elle n'atteste pas qu'une mesure donnée est appropriée à un traitement donné, et elle ne dit rien de son effectivité le jour du contrôle. D'autre part, toute personne agissant sous l'autorité du responsable du traitement ou du sous-traitant ne doit traiter les données que sur instruction : c'est le point où les accès internes échouent. Un administrateur qui consulte un dossier client par curiosité relève de l'article 32, pas de la gestion des ressources humaines.

L'articulation en deux temps consacrée par la Cour de justice

L'arrêt du 14 décembre 2023 dans l'affaire C-340/21 (attaque informatique contre l'administration fiscale bulgare) est le point d'ancrage européen de l'article 32, parce qu'il tranche quatre questions que presque aucune documentation ne traite. Premièrement, une attaque réussie ne démontre pas à elle seule que les mesures prises étaient inappropriées. Cela ressemble à une décharge, mais n'en est pas une : deuxièmement, le caractère approprié doit être apprécié concrètement, en deux temps. Il faut d'abord identifier les risques de violation que présente le traitement et leurs conséquences possibles pour les droits et libertés, avec leur probabilité et leur gravité. Il faut ensuite vérifier si la nature, le contenu et la mise en œuvre des mesures sont proportionnés à ces risques, au regard de l'état des connaissances, des coûts de mise en œuvre et du contexte du traitement.

Troisième point : dans une action en réparation fondée sur l'article 82, il appartient au responsable du traitement de prouver que ses mesures de sécurité étaient appropriées. Celui qui, après un incident, ne peut expliquer quel risque avait été identifié, quelle mesure y répondait et avec quel résultat, perd ce point non pas à cause de l'attaque mais à cause de l'absence de documentation. Quatrième point : une expertise judiciaire ne peut être considérée ni comme généralement nécessaire, ni comme généralement suffisante. Une expertise coûteuse ne remplace donc pas un enregistrement d'exploitation, et son absence ne décharge personne.

En pratique, vos documents doivent rendre cette articulation visible, traitement par traitement et non pour l'entreprise dans son ensemble. La CNIL lit un dossier comme un juge : elle ne cherche pas la liste des mesures, mais la justification de leur suffisance pour ce risque-là, et la preuve qu'elles étaient en service au moment du contrôle.

Le risque d'abord : construire l'échelle sur laquelle vous serez jugé

L'erreur de structure la plus fréquente est une analyse de risque au niveau de l'entreprise au lieu du traitement. « Notre risque est moyen » n'est pas une affirmation vérifiable, et elle conduit mécaniquement à des mesures trop faibles pour un traitement et inutilement coûteuses pour un autre. Ce qu'un contrôle attend, c'est une correspondance : ce traitement, cette catégorie de données, ce groupe de personnes concernées, cette probabilité, cette gravité, donc cette classe de risque — et à cette classe correspond un socle minimal de mesures que vous avez fixé à l'avance.

Une matrice à trois niveaux par axe suffit, à condition que les axes soient définis. La probabilité se fixe à partir de trois questions : le service est-il exposé à internet ? Traite-t-il des données qui se revendent (identifiants, données de carte, données de santé) ? A-t-il connu, dans les vingt-quatre derniers mois, un incident, une vulnérabilité critique ou une demande de l'autorité ? La gravité a plus de dimensions que l'argent : nombre de personnes concernées, durée de l'atteinte possible, irréversibilité (un mot de passe réinitialisé est réversible, un diagnostic publié ne l'est pas), potentiel de discrimination, et question de savoir si des données relèvent de l'article 9 ou de l'article 10.

L'intérêt de l'exercice n'est pas la matrice, c'est la correspondance qui en sort. Une gestion des candidatures avec coordonnées et curriculum vitae se situe généralement à moyen ; un logiciel de soins avec diagnostics à élevé ; une liste marketing d'adresses électroniques à faible. À « élevé » sont attachées des mesures minimales qui ne se discutent plus : chiffrement avec gestion de clés séparée, authentification multifacteur sur tous les accès, revue trimestrielle des habilitations, test de restauration documenté avec un objectif de délai, journalisation exportée hors du système. C'est exactement le but. Sans cette fixation préalable, on débat après l'incident du caractère « approprié » d'une mesure, et on perd le débat faute d'étalon.

« État de l'art » : une preuve, pas un sentiment

L'expression n'est pas définie par le règlement, et les autorités la remplissent par les référentiels. Pour un public français, trois points d'appui sont attendus : le guide de la sécurité des données personnelles de la CNIL, qui décline les mesures par thème et distingue les mesures à mettre en œuvre « à minima », les bonnes pratiques et les mesures renforcées ; les guides d'hygiène et les recommandations de l'ANSSI pour la partie technique ; et les normes internationales, au premier rang desquelles ISO/IEC 27001:2022 avec les mesures de son annexe A, notamment A 8.24 sur la cryptographie, A 8.15 sur la journalisation, A 8.13 sur la sauvegarde et A 5.24 à A 5.28 sur la gestion des incidents.

Concrètement, vous devez pouvoir nommer le référentiel appliqué et justifier une éventuelle déviation. « Nous suivons l'état de l'art » n'est pas une affirmation vérifiable. « Pour le traitement X, nous appliquons le guide de la sécurité de la CNIL pour le chiffrement, mis en œuvre par AES-256 avec clés conservées dans un KMS distinct, rotation annuelle, preuve du 12 septembre 2026 » en est une.

La CNIL précise d'ailleurs sa méthode d'appréciation dans sa doctrine de sanction : le caractère approprié des mesures s'apprécie en vérifiant que le mis en cause les a proportionnées, en l'état des informations dont il pouvait disposer par des diligences raisonnables, à la gravité et à la probabilité des risques prévisibles, au regard de la nature et du contexte du traitement ainsi que du coût et de la complexité des mesures possibles. Elle ajoute une formule qui vaut d'être retenue telle quelle : l'absence de violation de données ne suffit pas à démontrer l'absence de manquement à l'article 32, pas plus qu'une violation de données ne suffit à caractériser en soi un manquement.

Autrement dit, l'état de l'art n'est pas une course au maximum technique. C'est l'obligation de proportionner, puis de démontrer la proportionnalité. Une mesure moins coûteuse, documentée et testée, tient devant la formation restreinte mieux qu'une mesure maximale dont personne ne peut dire ce qu'elle protège.

Pseudonymisation et chiffrement : la question que le contrôle pose vraiment

Le point a) associe pseudonymisation et chiffrement, et presque toutes les documentations s'en acquittent par une phrase qui commence par « les données sont chiffrées en transit et au repos » et s'arrête là. La question sur laquelle se joue un contrôle est différente : où se trouve la clé par rapport au chiffré ? Si elle est dans le même compte, dans le même jeu de sauvegarde ou dans le même dépôt, une seule compromission livre les deux, et le chiffrement ne protège plus que contre la perte physique d'un support — c'est-à-dire le cas le moins probable.

Deux artefacts sont donc attendus. D'abord une politique de chiffrement : quelle catégorie de données est protégée par quel algorithme, sur quel canal (transport, stockage, champ), avec quelle longueur de clé, où sont les clés, qui y a accès, comment se fait la rotation et que se passe-t-il en cas de perte de clé. Ensuite un inventaire des clés : par système, le type de clé, le lieu de conservation, le responsable, la date de rotation et la date du dernier contrôle des droits d'accès au coffre. Sans ces deux listes, « chiffré » est une affirmation sur une configuration que personne ne peut reconstituer.

Trois détails décident. Le premier est la séparation entre le chiffré et la clé, au-delà des frontières de compte, avec des rôles distincts pour la gestion des clés et l'accès aux données : l'administrateur de la base ne doit pas pouvoir exporter la clé. Le deuxième est le chiffrement au niveau du champ pour les identifiants qui rendent un enregistrement personnel — numéro national d'identification, jeton de carte, marqueur de santé, numéro de compte. Une base entièrement chiffrée reste lisible en clair après une faille applicative, puisque l'application détient la clé ; un champ chiffré séparément reste illisible même si une requête renvoie des lignes qui ne vous appartiennent pas. Le troisième concerne la sauvegarde : une sauvegarde chiffrée dont la clé se trouve dans le même catalogue ou le même stockage objet n'est pas une sauvegarde chiffrée.

Un point de vérité, enfin : la pseudonymisation ne sort pas les données du champ d'application du règlement. Le lien avec la personne subsiste et reste reconstructible, ce qui explique que l'article 32 la cite comme mesure de protection et non comme anonymisation. Une analyse d'impact construite sur l'idée inverse ne résiste pas à un contrôle.

Confidentialité, intégrité, disponibilité, résilience : « constantes » exclut le projet

Le point b) exige la capacité à garantir ces quatre propriétés de façon constante. C'est l'endroit où les documentations deviennent une liste de projets alors que le texte décrit un état d'exploitation. La différence se voit dans les preuves : une preuve de projet est l'acte de mise en service d'un outil, une preuve d'exploitation est la dernière revue trimestrielle des habilitations, avec date, auteur, échantillon et comptes effectivement retirés.

Pour la confidentialité, quatre preuves sont attendues, et aucune n'est une politique : la revue des habilitations avec échantillon nommé et résultat ; la liste des comptes à privilèges avec leur justification ; la preuve de l'authentification multifacteur pour tous les accès administratifs et tous les accès exposés à l'extérieur, sous forme d'export et non de capture d'écran ; et un journal des entrées, mutations et sorties dont on peut déduire combien de temps un salarié parti a conservé un accès après son dernier jour. Pour l'intégrité : les enregistrements de gestion des changements, les empreintes ou signatures des artefacts déployés, la protection en écriture et la double validation sur les bases de production. Pour la disponibilité : une disponibilité mesurée et non contractuelle, la redondance des chemins critiques, et un processus de correctifs avec un chiffre — délai médian entre la publication d'une mise à jour critique et sa correction, mesuré chaque trimestre. « Nous corrigeons rapidement » n'est pas un chiffre.

La résilience est la partie que presque tous omettent, parce qu'elle ne se coche pas. Elle désigne la capacité à continuer de fonctionner sous charge et en cas de panne partielle : que se passe-t-il si un centre de données tombe, si un service boucle, si une attaque en déni de service vise la page de connexion ? Un test de charge documenté, un test de bascule daté et un plan de continuité que quelqu'un a réellement déroulé valent mieux que n'importe quelle politique supplémentaire.

Rétablissement : le test que presque personne ne produit

Le point c) exige de pouvoir rétablir la disponibilité des données et l'accès à celles-ci dans des délais appropriés. « Appropriés » ne devient une exigence que si vous avez fixé, par classe de système, deux nombres : le délai maximal de rétablissement et la perte de données acceptable. Ensuite on mesure, on n'estime pas.

L'artefact qui survit à un contrôle est un compte rendu de restauration daté, avec six informations : système, état des données restaurées, heure de début et de fin, durée réelle, résultat incluant le contrôle d'intégrité, et nom de la personne qui l'a exécuté. Une sauvegarde « au vert » n'est pas une preuve : elle établit que des données ont été copiées, pas qu'elles reviennent. Le constat classique est celui d'un dernier test de restauration réussi en 2022, ou d'une restauration jamais tentée parce que « la sauvegarde tourne ».

Trois règles doivent figurer au dossier, parce qu'elles font la différence entre un incident et une interruption de service. La règle 3-2-1-1-0 : trois copies, deux supports, une externalisée, une immuable ou hors ligne, zéro erreur à la vérification. La séparation des identifiants : les accès au système de sauvegarde ne doivent pas dépendre de le même annuaire que la production, faute de quoi le scénario rançongiciel est celui où les deux disparaissent ensemble. La fréquence : une fois par trimestre pour les systèmes à risque élevé, au moins une fois par an pour les autres, et après toute modification substantielle de l'infrastructure, parce qu'un test de trois mois a validé un environnement qui n'existe plus.

Tester, analyser, évaluer : cinq types de tests et ce que chacun démontre

Le point d) est le seul endroit du texte qui exige une activité plutôt qu'une propriété, et c'est celui que l'on confond le plus souvent avec un certificat. Cinq types de tests coexistent, et chacun répond à une question différente. Le test d'intrusion répond à : peut-on démontrer une exploitation, dans un périmètre et une fenêtre de temps définis ? C'est un instantané, qui vieillit au déploiement suivant. L'analyse de vulnérabilités répond à : quelle part de notre inventaire a été examinée, et quels constats restent ouverts par système ? Sa valeur est la couverture, pas le nombre de constats. Le contrôle de conformité, c'est-à-dire l'audit de configuration sur échantillon, répond à : les mesures existent-elles et sont-elles appliquées ? Un tirage de 25 comptes vérifiés sur l'authentification multifacteur vaut mieux qu'un document de politique. Le test de type red team ou hypothèse de compromission répond à : détectons-nous et réagissons-nous quand la prévention échoue ? Il évalue la détection et la réponse, pas le mur. Enfin l'exercice sur table répond à : l'organisation sait-elle qui décide en situation de crise, et combien de temps lui faut-il pour notifier ?

La fréquence de test relève de la classe de risque, pas du calendrier d'un prestataire : classe élevée au moins une fois par an avec un test externe et une reprise des constats critiques, classe moyenne tous les deux ans, classe faible un contrôle annuel. La preuve qui compte est la reprise : un constat retesté dans le même dispositif et confirmé corrigé, avec date. Un rapport sans reprise documente un problème, pas une mesure.

L'artefact de preuve : six champs qui transforment une affirmation en démonstration

Le test pratique de votre documentation est simple. Chaque ligne doit se résoudre en l'une de quatre choses : un export de configuration, un journal, un rapport ou un ticket avec résultat. Si elle ne se résout pas, c'est une affirmation, et une affirmation perd en cas de doute. Un artefact utilisable porte six champs : système ou traitement, date, personne responsable, périmètre (quels comptes, quelles données, quels systèmes), résultat chiffré, et preuve de la correction.

Deux éléments manquent presque partout et décident après coup. Le premier est la durée de validité : tenez chaque version de votre documentation avec une date de début et une date de fin d'application. Après un incident, l'appréciation porte sur les mesures en vigueur au moment du traitement, pas sur la version que vous avez améliorée trois semaines plus tard. Qui ne conserve que la version courante ne peut plus démontrer ce qui était en service, et cela ressemble à un ajustement rétroactif même quand il n'y en a pas eu. Le second est la durée de conservation des preuves. En droit français, la prescription de droit commun est de cinq ans en matière civile, et les délais propres à la responsabilité contractuelle ou à la responsabilité du fait des produits s'y ajoutent parfois ; pour les preuves relatives aux mesures de sécurité, cinq ans constituent un plancher raisonnable, dix ans pour les systèmes traitant des données sensibles. Cette conservation ne contredit pas la limitation de la conservation : les journaux de sécurité relèvent d'une finalité distincte des données de gestion, avec leur propre base légale et leur propre durée d'effacement, toutes deux documentées.

Le compte à rebours de 72 heures et ce qu'il impose à vos journaux

L'article 33 fait courir le délai à compter de la prise de connaissance, pas de l'incident — et c'est précisément là que la conservation des journaux devient une question d'article 32. Une notification doit décrire la nature de la violation, les catégories et le nombre approximatif de personnes et d'enregistrements concernés, le point de contact, les conséquences probables et les mesures prises. Chacun de ces points est une requête adressée à vos journaux. Le « nombre approximatif d'enregistrements concernés » ne se répond pas d'estimation, mais avec un journal d'accès couvrant la période pendant laquelle l'accès a existé.

Il en découle un calcul rarement fait. La conservation doit dépasser votre délai de détection réaliste, et non le standard de la plateforme. L'étude IBM de 2025 situe la détection médiane d'une compromission autour de 172 jours et la maîtrise de l'incident autour de 241 jours. Les valeurs par défaut des grandes plateformes sont nettement inférieures : 90 jours pour l'historique d'événements CloudTrail, 90 jours pour le journal système d'Okta, 30 jours pour les journaux de connexion de Microsoft Entra ID dans les offres payantes et 7 jours dans l'offre gratuite, 180 jours pour le journal d'audit unifié de Microsoft 365 en licence standard. Qui s'en tient à ces défauts ne peut plus reconstituer une attaque commencée il y a huit mois, et ne peut donc pas démontrer que les mesures du point d) étaient efficaces.

La solution n'a rien de spectaculaire : exporter les événements de sécurité vers un stockage que vous contrôlez (connexions, changements de droits, exports de données, accès aux clés, modifications de configuration de sécurité), y appliquer une conservation alignée sur le délai de détection mesuré, et poser une fois par trimestre une requête d'interrogation sur toute la période. Ce test sert aussi de preuve au titre du point d) : il montre que la journalisation n'est pas seulement configurée, mais interrogeable.

Sous-traitance : l'article 28 prolonge l'article 32 chez les tiers

L'article 28, paragraphe 3, point c), impose au sous-traitant de prendre toutes les mesures requises au titre de l'article 32, et le contrat de sous-traitance doit énumérer ces mesures. Le défaut typique est une annexe qui reprend depuis 2018 les mêmes douze lignes — contrôle des accès, contrôle des transmissions, contrôle des saisies, contrôle de la disponibilité — sans un seul procédé, sans un délai, sans un chiffre. Une telle annexe décrit une intention, pas un état, et elle ne transfère pas le problème : le responsable du traitement reste comptable du choix et de la surveillance.

Le test utilisable est celui de la preuve. Demandez au prestataire trois choses : le dernier compte rendu de restauration avec date et durée, la dernière revue des habilitations avec échantillon et résultat, et la durée de conservation de ses journaux de sécurité, assortie du délai dans lequel il notifie un incident. Celui qui ne peut produire ces trois éléments en une semaine n'a pas un processus, il a une page de contrat. À inscrire également : la liste des sous-traitants ultérieurs avec préavis de modification, le droit d'audit ou la reconnaissance d'une certification appropriée au titre de l'article 42 comme modalité de preuve, l'obligation de notifier sans retard injustifié, et une clause de restitution et de suppression en fin de contrat, avec preuve.

Registre des activités de traitement et documentation des mesures : quoi mettre où

L'article 30, paragraphe 1, point 7, demande au registre une description générale, lorsque cela est possible, des mesures techniques et organisationnelles au titre de l'article 32, paragraphe 1. Le mot « générale » explique un malentendu répandu : beaucoup d'organisations traitent le registre comme leur documentation de sécurité et s'arrêtent là. Il faut au contraire deux niveaux — les mesures générales, qui valent pour tous les traitements, et les mesures complémentaires propres à chaque traitement, qui dépassent ce socle — et une articulation entre les deux.

La structure propre est en trois étages : une liste de mesures à l'échelle de l'organisation, avec des identifiants (M-01 à M-nn) ; par traitement, un renvoi aux identifiants applicables plus les mesures complémentaires ; et par mesure, un emplacement où se trouve l'artefact de preuve. Sans identifiants, chaque contrôle déclenche une séance de traduction, et c'est là que naissent les contradictions. Un rappel de périmètre : la CNIL a confirmé que les solutions purement techniques ne suffisent pas, et que les mesures organisationnelles sont susceptibles de faire l'objet de vérifications au même titre que les mesures techniques — la sensibilisation des utilisateurs, la restriction des accès au besoin d'en connaître et le contrôle de l'usage en font partie.

Analyse d'impact et article 32 doivent se répondre

L'analyse d'impact relative à la protection des données décrit les risques et les mesures envisagées pour les traiter, y compris les mesures prévues au titre de l'article 32. Si l'analyse conclut à un risque élevé pour un traitement et que la documentation des mesures, pour le même traitement, mentionne « pare-feu en place, sauvegarde quotidienne », vous n'avez pas deux documents : vous avez une contradiction, que l'autorité lira en premier. La cohérence est simple à obtenir si les mêmes identifiants de mesures figurent dans les deux documents et si l'appréciation du risque résiduel s'appuie sur les preuves d'efficacité au lieu de les postuler.

En pratique, on relie les documents par trois phrases : quel risque a été identifié, quelle mesure y répond, et quelle preuve montre que la mesure agit. Si un risque élevé subsiste après mesures, la consultation préalable de l'autorité est l'étape suivante — et c'est encore un sujet d'article 32, puisque l'autorité examinera précisément le caractère approprié des mesures. L'analyse d'impact est aussi l'endroit où la question de l'état de l'art se traite concrètement, parce qu'elle décrit le traitement : une liste de mesures sans ce rattachement reste une collection de noms de produits.

Sanctions : 10 millions ou 2 %, et la pratique française de 2025

L'article 32 ne relève pas du barème le plus élevé. L'article 83, paragraphe 4, point a), couvre les violations des obligations du responsable du traitement et du sous-traitant visées aux articles 8, 11, 25 à 39, 42 et 43 — donc l'article 32 — dans une limite de 10 millions d'euros ou de 2 % du chiffre d'affaires annuel mondial de l'exercice précédent, le montant le plus élevé étant retenu. Les 20 millions ou 4 % du paragraphe 5 concernent les principes, les droits des personnes et les transferts.

Dans les faits, on reste rarement au barème inférieur, pour deux raisons. Un incident de sécurité touche presque toujours l'article 5, paragraphe 1, point f), c'est-à-dire l'intégrité et la confidentialité en tant que principe, qui relève du barème supérieur. Et lorsqu'une même opération donne lieu à plusieurs manquements, la somme est plafonnée au montant retenu pour la violation la plus grave. À l'inverse, l'article 83, paragraphe 2, point d), joue en votre faveur : les mesures prises au titre des articles 25 et 32 sont une circonstance atténuante expressément prévue. Des mesures documentées et testées ne réduisent donc pas seulement le risque, elles pèsent aussi sur la sanction.

La pratique française est documentée et sévère. La CNIL a prononcé 83 sanctions en 2025, pour un montant total de 486 839 500 euros, dont 78 amendes et 27 injonctions assorties d'astreinte ; la sécurisation insuffisante des données personnelles figure parmi les trois premiers motifs de sanction en procédure simplifiée, avec 14 organismes sanctionnés pour ne pas avoir mis en œuvre toutes les mesures nécessaires, notamment des mots de passe insuffisamment robustes ou des comptes partagés entre utilisateurs. Sur le fond, la formation restreinte a sanctionné la société NEXPUBLICA FRANCE à 1 700 000 euros le 22 décembre 2025 pour insuffisance des mesures techniques et organisationnelles de son logiciel de gestion de la relation avec les usagers : des usagers du portail avaient accès à des documents concernant des tiers, et l'instruction a relevé une faiblesse généralisée du système d'information et la persistance de problèmes structurels de sécurité. Le 30 décembre 2025, une société du secteur tertiaire a été sanctionnée à 3 500 000 euros sur plusieurs motifs comprenant un défaut de sécurité des données et l'absence d'analyse d'impact.

Le risque financier principal n'est d'ailleurs pas l'amende. L'article 82 ouvre à chaque personne concernée un droit à réparation, et depuis l'arrêt C-340/21 la charge de prouver le caractère approprié des mesures pèse sur vous. Sur un incident portant sur 50 000 enregistrements, la somme de multiples demandes individuelles et des frais de procédure dépasse régulièrement l'amende — et la preuve est de votre côté.

Le plan de 90 jours : de la liste de courses à la preuve

L'ordre des travaux détermine si vous produisez des preuves ou un document de plus. La trajectoire éprouvée va du moins cher et du plus immédiat vers le plus coûteux et l'externe. Deux premières semaines : inventaire des activités de traitement avec catégorie de données, groupe de personnes concernées et système concerné, puis classe de risque par traitement, puis fixation préalable des mesures attachées à chaque classe. Semaines trois à cinq : production des six preuves que tout contrôle réclame d'abord — inventaire des clés, revue des habilitations sur échantillon, compte rendu de restauration avec mesure du délai, indicateur de délai de correction, règle de conservation des journaux de sécurité et rapport de test avec reprise des constats. Semaines six à huit : consolidation, avec identifiants de mesures, renvois depuis le registre et l'analyse d'impact, remplacement de l'annexe de sous-traitance chez les trois prestataires principaux par la liste de preuves attendues. Semaines neuf à douze : calendrier du cycle, avec qui contrôle quoi chaque trimestre, et un premier test externe au périmètre clair.

Si vous ne bouclez pas tout en 90 jours, une chose est à ne pas faire : retirer du dossier le point non traité. Un plan de remédiation daté, avec responsable, étape intermédiaire et preuve attendue, est lui-même une preuve de sérieux et relève de l'article 83, paragraphe 2, point d). Un état maquillé qui tombe au premier sondage détruit en revanche la crédibilité de l'ensemble du dossier — et c'est alors chaque autre affirmation qui sera vérifiée.

Quand un test externe se justifie, et comment l'acheter

Un test externe se justifie lorsque vous avez besoin d'une affirmation sur l'exploitabilité que vous ne pouvez pas porter vous-même de façon crédible — vis-à-vis d'un client, d'un assureur ou d'une autorité — et lorsque vous avez la capacité de traiter les constats. Il ne remplace pas les preuves des points b) à d) : un test d'intrusion ne montre ni une revue des habilitations, ni un compte rendu de restauration, ni une règle de conservation.

Cinq points comptent à l'achat. Un périmètre écrit avec systèmes, rôles et zones exclues. Une commande écrite et des règles d'engagement limitées aux systèmes dont vous êtes propriétaire ou pour lesquels vous disposez d'une autorisation écrite : le reste n'est pas un test, c'est un risque juridique. L'engagement d'une reprise des constats critiques incluse dans le prix. Un format de livraison intégrable à votre dossier : constats classés selon les quatre points de l'article 32, avec système, date, périmètre, résultat et recommandation de correction. Et la vérité sur les limites du rapport : une liste de scores CVSS sans lien avec le traitement ne dit rien du caractère approprié, et un rapport de 400 pages que personne ne lit n'est pas une preuve, c'est une étagère.

Si vous commandez un tel test, faites-le porter sur un traitement à risque élevé et non sur l'application la plus facile d'accès. L'utilité naît là où un constat permet une affirmation sur votre analyse de risque — et referme ainsi l'articulation en deux temps issue de l'arrêt C-340/21, que plus aucune autorité ne contourne.