En une phrase. L’article 32 du RGPD impose au responsable du traitement et au sous-traitant des mesures techniques et organisationnelles appropriées à leurs risques. Il cite, « selon les besoins », la pseudonymisation et le chiffrement, la confidentialité, l’intégrité, la disponibilité et la résilience, la restauration après incident et l’évaluation régulière des mesures. Il ne fixe ni algorithme universel ni périodicité unique de test.
La question pratique est : que pourrait subir une personne si ses données étaient perdues, divulguées, modifiées ou rendues indisponibles, et quelles preuves montrent que les mesures choisies fonctionnent ? Une violation peut se produire malgré une organisation diligente ; inversement, l’absence d’incident connu ne démontre pas que la sécurité était adaptée. La version française du RGPD publiée par la CNIL et le guide de sécurité CNIL 2024 servent de points d’appui.
Points clés
- L’article 32 §1 demande de considérer l’état des connaissances, les coûts, la nature et le contexte du traitement, ainsi que les risques pour les droits et libertés.
- Les exemples du texte ne constituent pas une liste de produits ou de paramètres obligatoires pour chaque traitement.
- Le §2 invite notamment à examiner destruction, perte, altération, divulgation ou accès non autorisé, accidentels ou illicites.
- Les responsabilités de sécurité doivent être réparties entre responsable et sous-traitant ; un contrat seul ne sécurise aucun accès.
- La décision sur les mesures doit rester révisable et étayée par des traces de leur efficacité.
1. Lire l’article 32 comme une obligation adaptée au risque
Le §1 donne quatre familles de mesures possibles : pseudonymisation et chiffrement ; capacité de garantir confidentialité, intégrité, disponibilité et résilience continues ; capacité de rétablir disponibilité et accès dans des délais appropriés après un incident physique ou technique ; procédure de tests, analyses et évaluations régulières. « Selon les besoins » signifie que leur déclinaison dépend du traitement. Un chiffrement de fichier ne remplace pas les habilitations, et une sauvegarde ne prévient pas une divulgation par un compte trop large.
L’analyse part de la personne concernée. Une fuite d’adresses professionnelles, la modification de dossiers médicaux ou l’indisponibilité d’un service de prestations n’ont pas les mêmes conséquences. Décrire les données, les utilisateurs, les flux, les dépendances et l’impact possible avant de choisir une mesure. Pour un traitement à risque élevé, l’AIPD aide à examiner les risques pour les droits et libertés ; l’article 32 s’applique aussi lorsque l’AIPD n’est pas requise.
Les coûts et l’état des connaissances font partie des critères, mais le coût ne permet pas d’écarter sans analyse une précaution élémentaire face à un risque grave. Une petite structure peut choisir une solution gérée et vérifier ses paramètres ; une grande organisation doit éviter de supposer qu’une certification globale couvre chaque application. La fiche CNIL sur l’analyse de risques articule socle de précautions et risques propres au traitement.
2. Construire un diagnostic par traitement
Pour une activité donnée, consigner les catégories de données et de personnes, les destinataires, l’hébergement, les sous-traitants et les flux. Recenser ensuite les événements plausibles : vol d’un ordinateur, envoi au mauvais destinataire, privilège excessif, rançongiciel, indisponibilité du fournisseur ou destruction accidentelle. Apprécier la gravité pour les personnes et la vraisemblance avec les protections réellement en place. Une matrice peut prioriser, mais sa note ne dispense pas d’expliciter le raisonnement.
Dans un exemple hypothétique de boutique en ligne qui conserve des coordonnées de clients, le risque principal peut être l’accès abusif à l’interface d’administration. La mesure pertinente n’est pas seulement « HTTPS » : il faut limiter les comptes, protéger l’authentification, retirer les accès d’anciens prestataires, surveiller les événements et prévoir la réponse à une fuite. Si le même outil héberge des données de santé, les conséquences et la sélection des contrôles changent. Le nombre de personnes n’est qu’un paramètre parmi d’autres.
Pour chaque risque prioritaire, écrire quatre éléments : mesure décidée, responsable de son exécution, preuve attendue et date de réexamen. Relier cette fiche au registre des traitements ou à la documentation de sécurité existante. Le registre demande une description générale des mesures ; il n’est pas nécessaire d’y publier l’architecture sensible ou des secrets d’exploitation.
3. Un socle de sécurité à adapter et à prouver
Le guide CNIL 2024 distingue précautions élémentaires et mesures complémentaires. Il traite notamment authentification, habilitations, postes, serveurs, cloud, API, journalisation et pilotage. Ce guide constitue une référence de doctrine pratique utilisée par la CNIL, pas un tableau de seuils légaux identiques pour tous les traitements.
| Question à résoudre | Exemple de mesure | Preuve utile |
|---|---|---|
| Qui accède aux données ? | Rôles limités, suppression des comptes inutiles, authentification renforcée si le risque le justifie | Export des habilitations, revue signée, essai de révocation |
| Comment éviter la divulgation en transit ? | Canal chiffré et configuration actualisée | Paramétrage, contrôle de configuration, résultat de vérification |
| Comment contenir une compromission ? | Segmentation, correctifs, limitation des privilèges | Inventaire, calendrier de correctifs, écarts traités |
| Comment reprendre le service ? | Sauvegardes protégées, procédure de restauration | Compte rendu d’un essai sur un périmètre réel |
| Comment détecter et comprendre ? | Journaux utiles, alertes, enquête documentée | Exemple d’alerte examinée et délai de traitement |
Les seuils tels que « un an de logs », « trente jours de sauvegarde », « test mensuel » ou « pentest annuel » ne figurent pas dans l’article 32 comme obligations générales. Définir des durées et fréquences en fonction de l’exposition, des besoins d’enquête, de la capacité de restauration et des autres règles applicables. Les justifier et les réviser lorsque les usages changent.
4. Chiffrement, hachage et pseudonymisation : trois fonctions distinctes
Le chiffrement protège la lisibilité de données lorsque la clé reste hors de portée de l’attaquant. Préciser ce qui est chiffré : disque d’un poste mobile, sauvegarde, flux entre services ou champ particulièrement sensible. Vérifier où résident les clés, qui peut y accéder, comment elles sont renouvelées et ce qui arrive aux données en mémoire ou après authentification. Affirmer « données chiffrées » sans décrire cette frontière peut masquer un risque intact.
Un mot de passe ne devrait pas être stocké sous forme réversible pour authentifier un utilisateur ; des mécanismes de hachage adaptés et salés répondent à un objectif différent du chiffrement de documents. La pseudonymisation remplace les identifiants directs ou indirects tout en conservant séparément l’information nécessaire à la réattribution. Elle réduit certaines conséquences d’une fuite, mais les données restent personnelles si la réidentification demeure possible. Le guide de chiffrement détaille le choix et la gestion des protections cryptographiques. Pour l’attribution des actions, examiner aussi la journalisation des accès.
Dans un exemple hypothétique d’analyse statistique RH, séparer la table d’identité des résultats et restreindre la clé de rapprochement peut réduire l’exposition des analystes. Il faut encore tester la possibilité de réidentifier par une combinaison de poste, âge et petite équipe. Choisir une protection dépend du scénario : chiffrer une base sans revoir les droits de l’application n’empêche pas un utilisateur habilité abusivement d’en exporter le contenu.
5. Disponibilité, résilience et restauration
Une sauvegarde n’est une réponse crédible que si elle couvre les données nécessaires, reste accessible après l’incident envisagé et peut être restaurée dans un délai utile. Définir quels traitements doivent revenir en premier, quelle perte de données temporelle est acceptable et qui déclenche la reprise. Tester la restauration d’un ensemble cohérent, y compris dépendances, identités et configuration, plutôt que vérifier seulement qu’un fichier de sauvegarde existe.
Les risques physiques comptent aussi : panne d’alimentation, destruction de matériel, sinistre sur un site. Les systèmes de secours et fournisseurs doivent être évalués pour les dépendances communes. Deux copies hébergées sous le même compte administrateur peuvent tomber ensemble. La stratégie de sauvegarde 3-2-1 expose un cadre pratique ; son application exacte dépend du système et du risque.
Après un essai, conserver date, périmètre, durée réelle, données restaurées, écarts et correctifs décidés. Une procédure non exécutée depuis longtemps a une valeur probante faible. Si un traitement est externalisé, demander au sous-traitant ce qu’il restaure lui-même et ce qui reste à la charge du client ; tester cette frontière contractuelle et technique.
6. Tester l’efficacité et gérer les incidents
L’article 32 §1(d) exige une procédure pour tester, analyser et évaluer régulièrement l’efficacité des mesures. Le calendrier doit tenir compte de la criticité et des changements : nouvelle API, migration cloud, incident, changement de prestataire, correction majeure. Des revues d’accès, essais de restauration, audits de configuration, analyses de vulnérabilités ou exercices de crise peuvent se compléter. Un test d’intrusion ponctuel n’évalue pas, à lui seul, la permanence des contrôles.
La preuve de test doit montrer les écarts détectés, leur classement, le responsable de correction et une vérification après correction. Un rapport « zéro faille critique » sans périmètre ni date a une portée limitée. De même, le résultat d’une certification ISO peut soutenir la gouvernance de sécurité mais ne garantit pas que le traitement examiné répond à l’article 32. La comparaison ISO 27001 et RGPD aide à distinguer système de management et obligation juridique propre à chaque traitement.
Préparer aussi la qualification d’une violation. Une atteinte à la sécurité et une violation de données personnelles ne se confondent pas toujours. En cas de violation, les règles des articles 33 et 34 déterminent la notification à l’autorité et, selon le risque, aux personnes. Le délai de 72 heures concerne la notification à l’autorité à partir de la connaissance de la violation lorsqu’elle est requise ; il n’est pas un délai universel pour achever l’enquête. Documenter également les incidents non notifiés et leur justification.
7. Personnel, sous-traitants et chaîne d’instructions
Le §4 demande au responsable et au sous-traitant de prendre des mesures pour que les personnes agissant sous leur autorité et ayant accès aux données ne les traitent que sur instruction, sauf obligation légale contraire. Des habilitations adaptées, consignes compréhensibles, formation et contrôle des départs rendent cette règle concrète. Une charte seule ne suffit pas si les comptes restent actifs après un changement de fonction.
Pour un service externalisé, l’article 28 impose un contrat et des garanties appropriées ; l’article 32 continue de concerner chacun selon son rôle. Le responsable doit comprendre les protections du service et vérifier les limites de la prestation : chiffrement géré par qui, création des comptes par qui, journalisation accessible à qui, sauvegarde incluse ou non. Le guide d’audit des sous-traitants aide à préparer des questions proportionnées. Une attestation commerciale ne démontre pas automatiquement les contrôles sur la configuration du client.
8. Décider et conserver un dossier défendable
Un dossier concis peut contenir la description du traitement, les scénarios retenus, l’appréciation de leurs conséquences, les mesures existantes et prévues, leurs propriétaires, les preuves de test et les risques résiduels acceptés. Le relier aux changements d’application et aux incidents. Le responsable doit pouvoir expliquer pourquoi une mesure a été choisie ou écartée au moment de la décision et ce qui a changé depuis.
Exemple hypothétique : une association partage un fichier de bénéficiaires avec deux antennes. L’analyse révèle des exports par courrier électronique non protégés et des comptes communs. Elle choisit un espace d’échange à accès individuel, supprime les exports locaux et teste la révocation d’un compte d’antenne. Le dossier conserve le schéma de flux, la date de migration, l’essai de révocation et la règle de conservation. Une simple mention « chiffrement : oui » aurait manqué le problème d’attribution des accès.
Le manquement à l’article 32 peut relever du plafond de l’article 83 §4 du RGPD, mais une sanction concrète dépend des faits et des autres dispositions éventuellement violées. Il est plus utile de démontrer la proportionnalité et l’efficacité des mesures que de déduire une conformité d’une liste de technologies.
FAQ
Le chiffrement est-il toujours obligatoire ?
L’article 32 le cite comme mesure possible selon les besoins. Son absence face à une exposition forte demande une justification sérieuse, mais le texte n’impose pas un algorithme ou un chiffrement au repos pour chaque donnée sans distinction.
L’article 32 fixe-t-il un minimum de tests par an ?
Non. Il demande une évaluation régulière de l’efficacité. La fréquence dépend du risque, des changements et d’autres obligations éventuelles ; il faut garder le calendrier et les résultats.
Une certification ISO 27001 suffit-elle ?
Non. Elle peut fournir des éléments utiles, mais l’organisation doit vérifier le périmètre certifié, les contrôles appliqués au traitement concerné et leur efficacité réelle.
Que demander à un fournisseur ?
La répartition précise des responsabilités, les contrôles applicables au service acheté, leurs preuves récentes, les délais de détection et d’information, et les résultats des essais de restauration ou de reprise pertinents.