L'article 32 du RGPD impose des mesures de sécurité adaptées au risque, et une procédure pour en éprouver régulièrement l'efficacité. C'est la seule obligation du règlement qui ne se démontre pas par un document, mais par des vérifications datées. Nous auditons l'état réel de vos mesures, nous chiffrons la mise à niveau, et nous contrôlons qu'elle a produit son effet.
Le RGPD repose sur le principe de responsabilité : il ne suffit pas d'être conforme, il faut pouvoir le démontrer. La plupart de ses obligations se démontrent par des documents. Une seule se démontre par des contrôles techniques, et c'est celle sur laquelle nous intervenons.
Registre des traitements, bases légales, information et droits des personnes, analyses d'impact, transferts hors UE : tout cela s'écrit et se tient à jour : c'est le travail de votre délégué à la protection des données ou de votre conseil juridique. Nous n'intervenons pas sur ce terrain, et nous le disons plutôt que de le laisser croire.
Des mesures techniques et organisationnelles adaptées au risque, et une procédure pour tester et évaluer régulièrement leur efficacité. C'est la seule obligation du règlement qui se vérifie sur vos systèmes plutôt que dans un classeur : c'est notre sujet.
Notifier la CNIL sous 72 h en cas de risque, informer les personnes si le risque est élevé, documenter chaque incident. Une violation est, par définition, une défaillance de l'article 32 : les deux sujets ne se séparent pas.
Le reste du règlement s'écrit. L'article 32, lui, se vérifie : il impose des mesures techniques et organisationnelles adaptées au risque, et surtout une procédure pour en éprouver régulièrement l'efficacité. C'est l'obligation sur laquelle une PME est le plus souvent prise en défaut, parce qu'elle suppose des preuves plutôt que des documents.
Pseudonymisation et chiffrement lorsque c'est pertinent, et une garantie continue de confidentialité, d'intégrité, de disponibilité et de résilience de vos systèmes. Le texte ne liste pas de recette : il demande que le niveau soit justifié au regard du risque pour les personnes.
Vous devez pouvoir restaurer la disponibilité des données dans des délais appropriés. Une sauvegarde jamais restaurée ne répond pas à cette exigence : c'est le test de restauration, et son compte rendu, qui en font une mesure au sens du règlement.
Le règlement impose une procédure pour tester, analyser et évaluer l'efficacité des mesures. C'est ce que démontrent un audit d'infrastructure daté et un test d'intrusion : non pas que vous avez acheté des outils, mais qu'ils tiennent.
Personne agissant sous votre autorité ne doit traiter de données personnelles en dehors de vos instructions. En pratique : des droits revus, des comptes à privilèges recensés, des départs traités, et une trace de qui a accédé à quoi.
En cas de contrôle, l'article 32 se démontre par des preuves techniques. La CNIL n'attend pas une politique de sécurité, mais la trace de ce qui a été vérifié, quand, et ce qui en a été corrigé. C'est aussi ce qu'attendent l'ISO 27001 et l'article 21 de NIS2 : une seule analyse de risques, documentée et éprouvée, sert les trois.
L'article 32 ne donne pas de liste : il demande que le niveau soit justifié au regard du risque pour les personnes, et de l'état de l'art. Dans une entreprise qui traite des données de clients et de salariés, cela désigne presque toujours les mêmes huit mesures — et l'absence de l'une d'elles est difficile à défendre.
Des habilitations attribuées par fonction, revues au moins une fois par an, et retirées au départ d'une personne. C'est la mesure la plus souvent défaillante : des dossiers RH ou clients accessibles à toute l'entreprise parce qu'un partage ouvert n'a jamais été refermé.
Un second facteur sur la messagerie, les accès distants, les comptes d'administration et les applications exposées. Sans lui, un seul mot de passe retrouvé dans une fuite publique donne accès à des données personnelles : c'est le scénario de violation le plus fréquent.
Le texte cite le chiffrement sans l'imposer partout : postes portables et supports amovibles, sauvegardes, transferts de fichiers vers l'extérieur. La question n'est pas « avons-nous chiffré ? » mais « pourquoi pas ici, et l'avons-nous écrit ? ».
Sauvegardes hors d'atteinte d'un rançongiciel, restauration testée et datée, délai de remise en service connu. Une indisponibilité prolongée est une violation de données au même titre qu'une fuite : le texte vise aussi la perte d'accès.
Journaux des accès aux données sensibles, des connexions distantes et des actions d'administration, conservés assez longtemps pour servir après coup. Sans eux, vous ne pourrez ni déterminer l'étendue d'une violation, ni la décrire à l'autorité.
Correctifs appliqués dans des délais écrits, systèmes en fin de support identifiés et traités. Exploiter une faille connue depuis deux ans est le reproche le plus simple à formuler, et le plus difficile à justifier.
Les prestataires qui traitent des données pour vous doivent présenter des garanties suffisantes, et vous devez pouvoir le démontrer autrement que par une clause type jamais vérifiée. Leur niveau de sécurité devient le vôtre.
Reconnaître un hameçonnage, savoir où ne pas déposer un fichier, signaler un incident sans crainte. L'article 32.4 vous rend responsable de ce que font les personnes agissant sous votre autorité : la sensibilisation en fait partie.
L'article 32 se distingue du reste du règlement sur un point : il ne se démontre pas par un document, mais par des vérifications datées. Une politique de sécurité prouve que vous avez écrit une intention ; elle ne prouve pas que les mesures tiennent.
C'est aussi le point 32.1.d, souvent ignoré : le règlement impose une procédure pour tester, analyser et évaluer régulièrement l'efficacité des mesures. Autrement dit, la preuve attendue est un contrôle technique répété, pas une rédaction.
Une analyse de risques datée, une revue des habilitations, un compte rendu de test de restauration, un audit d'infrastructure annuel et un test d'intrusion avec sa contre-vérification. Chacun porte une date : c'est ce qui en fait une preuve.
Ce qui sera examiné n'est pas votre documentation, mais l'écart entre les mesures annoncées et leur état réel au moment des faits. Un rapport d'audit récent qui signale un risque corrigé vaut mieux qu'un dossier parfait sans aucune vérification.
Nous ne rédigeons ni registre ni mentions d'information : cela revient à votre délégué à la protection des données. Ici, nous répondons à la seule question que l'article 32 pose : vos mesures existent-elles réellement, et tiennent-elles ?
État des lieux des huit mesures attendues, confronté au risque réel de vos traitements : accès, authentification, chiffrement, sauvegardes, traces, correctifs, sous-traitants, sensibilisation. Chaque constat est daté et justifié.
Les écarts classés par risque pour les personnes et par effort, chiffrés, avec ce qui se corrige le jour même et ce qui demande un budget. C'est ce document qui fait la preuve de la démarche, même avant qu'elle soit achevée.
C'est l'exigence du point 32.1.d : audit d'infrastructure annuel, test d'intrusion sur les systèmes qui portent des données personnelles, et contrôle que les correctifs ont bien fermé ce qui était ouvert.
Procédure de qualification écrite, registre des violations, aide à la notification dans les 72 heures et au traitement des causes. Une violation se prépare avant de survenir : après, le délai court déjà.
Des mesures techniques et organisationnelles adaptées au risque, sans liste imposée : c'est à vous de justifier le niveau retenu. Le texte cite la pseudonymisation et le chiffrement, la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes, la capacité à rétablir l'accès aux données après un incident, et une procédure pour tester et évaluer régulièrement l'efficacité de ces mesures. C'est ce dernier point qui manque presque toujours : un audit d'infrastructure annuel et un test d'intrusion documenté y répondent directement.
La désignation est obligatoire pour les autorités et organismes publics, ainsi que pour les organismes dont les activités de base consistent en un suivi régulier et systématique des personnes à grande échelle, ou en un traitement à grande échelle de données sensibles ou relatives aux condamnations pénales. Dans les autres cas, elle reste fortement recommandée.
Dès qu'un traitement est susceptible d'engendrer un risque élevé pour les personnes. La CNIL publie une liste de types de traitements pour lesquels une AIPD est requise ; plus généralement, un traitement qui réunit au moins deux des critères définis par les autorités européennes (données sensibles, grande échelle, personnes vulnérables, croisement de données, surveillance systématique…) doit en principe en faire l'objet.
Contenir l'incident, évaluer son impact pour les personnes et le documenter dans le registre des violations. Si la violation présente un risque, elle doit être notifiée à la CNIL dans les 72 heures ; si le risque est élevé, les personnes concernées doivent aussi être informées. Nous vous aidons à préparer cette procédure avant qu'un incident ne survienne.
Oui, dès lors que les données permettent d'identifier une personne physique : nom d'un interlocuteur, adresse e-mail nominative, numéro de téléphone direct… Vos fichiers clients et prospects B2B sont donc concernés.
En Suisse, c'est la nouvelle loi fédérale sur la protection des données (nLPD) qui s'applique, avec des règles proches mais pas identiques. Une entreprise suisse peut aussi être soumise au RGPD si elle s'adresse à des personnes dans l'Union européenne. Nous intervenons en Suisse : découvrir notre offre nLPD.
Non, l'article 32 le cite comme une mesure possible, pas comme une exigence générale : il demande des mesures appropriées au risque. En pratique, son absence est facile à reprocher là où le risque est évident — ordinateurs portables, supports amovibles, sauvegardes, envois de fichiers vers l'extérieur — et facile à justifier ailleurs. Ce qui compte est d'avoir tranché la question par écrit, avec le motif, plutôt que de ne pas se l'être posée.
Le risque s'apprécie du point de vue des personnes concernées, pas du vôtre : la nature des données, leur volume, et ce qu'une fuite leur ferait. Un cabinet de cinq personnes qui traite des données de santé est tenu à davantage qu'une entreprise industrielle de deux cents salariés qui ne détient que des contacts professionnels. C'est pourquoi la démarche commence toujours par une analyse de risques : sans elle, aucun niveau de sécurité ne peut être qualifié d'adapté, ni trop faible, ni trop élevé.
Non, et c'est une confusion fréquente. L'obligation de l'article 32 pèse sur le responsable du traitement, c'est-à-dire sur vous. Votre prestataire met en œuvre ; il ne porte ni la décision du niveau de sécurité, ni la preuve qu'il est atteint. Concrètement, il vous faut un contrat qui dit ce qu'il fait, et une vérification indépendante de ce qui est réellement en place — demander à celui qui a installé le système d'attester de sa sécurité n'est pas une évaluation.
L'écart entre le risque et les mesures effectivement en place au moment des faits. Les décisions publiées reviennent presque toujours aux mêmes constats : pas d'authentification forte sur un accès distant, des habilitations jamais revues, des correctifs en retard sur une faille connue, l'absence de journalisation qui empêche même de déterminer l'étendue de la fuite. La sanction porte rarement sur la survenue de l'incident : elle porte sur ce qui n'avait pas été fait avant.
Un audit de l'article 32 pour mesurer l'écart entre vos mesures annoncées et leur état réel.
