Ce qu'un DPO peut vérifier sur le site d'un client sans service informatique

Si vous travaillez comme délégué à la protection des données (DPO) ou comme consultant RGPD, vous connaissez ce moment. Le registre des traitements est en ordre, les mentions d'information sont rédigées, les contrats de sous-traitance sont signés. Puis vous arrivez au site web, et les notes de revue disent « à vérifier par l'informatique ». Le client n'a pas de service informatique, et l'agence qui a construit le site ne répond pas.

Or le site est souvent le seul système de votre client qui accepte des données personnelles de n'importe qui sur Internet : un formulaire de contact, une inscription à une lettre d'information, une prise de rendez-vous. Vous pouvez en évaluer une bonne partie vous-même, sans accès administrateur et sans connaissances techniques. Voici comment, et comment le consigner.

Ce que l'article 32 demande à un site web

L'article 32 du RGPD 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 ». Parmi ses exemples : le chiffrement, la confidentialité, l'intégrité, la disponibilité et la résilience constantes des systèmes, le rétablissement des données dans des délais appropriés après un incident, et « une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ».

Pour un site public, cela se traduit par quelques questions concrètes. Les données d'un formulaire sont-elles chiffrées jusqu'au serveur ? Les logiciels sont-ils à jour ? Un inconnu pourrait-il télécharger des fichiers contenant des données personnelles ? Le site transmet-il les données des visiteurs à des tiers sans base juridique ? Et quelqu'un vérifie-t-il tout cela régulièrement et en garde-t-il une trace ?

La dernière question rejoint la responsabilité. Selon l'article 5, paragraphe 2, le responsable du traitement répond des principes de l'article 5, paragraphe 1, dont l'intégrité et la confidentialité, et doit être « en mesure de démontrer » qu'il les respecte. L'article 39, paragraphe 1, point b), range parmi les missions du DPO le contrôle du respect du RGPD, audits compris. Un contrôle de site daté s'y inscrit sans difficulté. Pour le côté du responsable du traitement, notification de violation sous 72 heures comprise, voir le RGPD et votre site.

Ce que vous pouvez vérifier vous-même en 20 minutes

Tout ce qui suit, n'importe quel visiteur peut le faire : aucun accès n'est nécessaire. Si vous voulez lancer des outils d'analyse automatique sur le site, demandez d'abord l'accord du client. Faites une capture d'écran à chaque étape, avec l'adresse du site et la date visibles.

1. Le cadenas et le certificat. Cliquez sur l'icône à côté de l'adresse du site et ouvrez les détails du certificat. Notez qui l'a émis et quand il expire. Tapez ensuite l'adresse à la main avec http:// au lieu de https://. Le site doit passer tout seul à la version https. S'il reste en http, les données des formulaires peuvent circuler sans chiffrement. Le vérificateur de certificat SSL gratuit (en anglais) couvre le reste, y compris les versions de protocole obsolètes.

2. La politique de confidentialité. Y a-t-il un lien dans le pied de page de chaque page et à côté de chaque formulaire ? Fonctionne-t-il, ou mène-t-il à une erreur 404 ? La politique nomme-t-elle le responsable du traitement qui exploite réellement le site, et mentionne-t-elle les outils que vous voyez dessus ? Une politique rédigée il y a des années s'éloigne facilement d'un site qui a depuis gagné un widget de discussion ou un pixel publicitaire.

3. Les formulaires. Ouvrez chaque page qui contient un formulaire et vérifiez la présence du cadenas. Un formulaire intégré depuis un autre service, comme un système de réservation ou un outil de lettre d'information, est un destinataire de plus des données et exige un contrat de sous-traitance avec le client. Vérifiez qu'une courte mention d'information figure à côté, et que le formulaire ne demande pas plus que sa finalité ne l'exige. Un champ pour un numéro d'identité nationale sur un formulaire de contact mérite une discussion. Votre formulaire de contact est une porte d'entrée détaille ce qui peut encore mal tourner avec les formulaires.

4. Les cookies avant consentement. Ouvrez le site dans une fenêtre de navigation privée et ne touchez pas au bandeau de cookies. Appuyez sur F12, allez dans l'onglet Application dans Chrome ou Edge, ou Stockage dans Firefox, et ouvrez la liste des cookies. Si des cookies d'analyse ou de publicité sont déjà là avant tout clic, par exemple _ga de Google Analytics ou _fbp du pixel Meta, le suivi démarre sans consentement. Cliquez ensuite sur « Refuser », rechargez la page et regardez s'ils disparaissent. La règle du consentement préalable vient de l'article 5, paragraphe 3, de la directive vie privée et communications électroniques (2002/58/CE), telle que transposée dans le droit de chaque pays, et non du RGPD lui-même. Les données personnelles que collectent ces outils relèvent en revanche du RGPD. Pour un premier passage rapide sans F12, la vérification des cookies avant consentement (en anglais) liste les cookies posés par le serveur et les traceurs présents dans le code de la page. Les cookies que des scripts écrivent plus tard n'apparaissent que dans le navigateur.

5. Le courrier électronique du domaine. Saisissez le domaine du client dans la vérification SPF, DKIM et DMARC (en anglais). Sans DMARC, n'importe qui peut envoyer un e-mail qui semble venir de votre client, y compris à ses propres clients, pour leur demander des informations personnelles ou un paiement. C'est un risque de violation qui naît en dehors du site mais utilise le même domaine.

6. Les versions de logiciels visibles. Appuyez sur Ctrl+U pour afficher le code source de la page et cherchez (Ctrl+F) generator. Vous trouverez souvent quelque chose comme WordPress 6.x. Comparez le numéro avec la version actuelle sur wordpress.org. Un numéro de version visible n'est pas une vulnérabilité en soi, mais une version ancienne laisse penser que personne ne met non plus à jour les extensions. Si la balise est absente, cela ne prouve rien, car elle peut être masquée.

Ce qu'on ne voit pas de l'extérieur

Un contrôle dans le navigateur a ses limites, et vos notes doivent les consigner comme elles consignent les constats :

• les sauvegardes : existent-elles, où sont-elles conservées et quelqu'un a-t-il déjà restauré le site à partir d'une sauvegarde,
• les comptes d'administration : qui a un accès administrateur et si ces personnes utilisent une connexion à deux facteurs,
• les versions d'extensions qui n'apparaissent pas dans le code de la page, et qui les tient à jour,
• ce qu'il advient d'un message après son envoi : s'il reste dans la base, combien de temps, et dans quelle boîte il arrive,
• la configuration du serveur, les journaux et la protection de la base de données,
• l'emplacement de l'hébergement et si les données quittent l'EEE.

Transformez ces points en questions pour le client ou son développeur web, et notez qui a répondu et quand. L'absence de réponse est aussi un résultat, et elle va dans les notes.

Comment consigner le contrôle

Une note de contrôle doit tenir si quelqu'un demande un an plus tard comment vous le saviez. Gardez un seul format :

1. La date et l'heure, l'adresse du site, qui a vérifié et avec quel navigateur.
2. La liste des points vérifiés, chacun marqué conforme, à corriger ou impossible à vérifier.
3. Des captures d'écran pour chaque point à corriger.
4. Qui a reçu les constats, quand et sous quelle forme.
5. Le délai de correction convenu avec le responsable du traitement et la date du contrôle de suivi.

Un tel document sert les deux parties. Le client dispose de la preuve des tests réguliers que demande l'article 32, paragraphe 1, point d). Vous disposez de la preuve que vous avez contrôlé et transmis vos recommandations. La correction elle-même relève du responsable du traitement et de celui qui construit son site.

Répétez le contrôle au moins une fois par an et après tout changement important, comme une nouvelle agence web ou une nouvelle boutique en ligne. Deux rapports datés montrent si vos recommandations ont été suivies.

Quand vous avez beaucoup de clients

Avec une douzaine de clients ou plus, un contrôle manuel de chaque site finit par prendre des journées entières. La partie vue de l'extérieur peut être automatisée avec ShieldWave. Il vérifie chaque site tel que n'importe qui le voit sur Internet, y compris les fichiers exposés, les en-têtes de sécurité et les vulnérabilités connues liées aux versions de logiciels, et vous remet un rapport PDF daté avec une correspondance avec le RGPD. La partie technique part telle quelle chez le développeur du client, sans traduction. L'offre Pro coûte 12 $ par mois pour 25 sites au plus. Elle ne certifie pas la conformité au RGPD et ne regarde pas l'intérieur de l'espace d'administration : les questions de la section ci-dessus restent donc à poser par vous.