Rapport d'audit de sécurité WordPress : les preuves à conserver

Lorsqu'un client, un auditeur ou un assureur vous demande de prouver que votre site WordPress est sécurisé, « nous faisons toutes les mises à jour » ne constitue pas une réponse. Il attend des justificatifs. Un rapport d'audit de sécurité WordPress rassemble ces éléments dans un seul document, qu'un tiers peut lire et vérifier. Cet article détaille ce qu'il faut conserver, à quoi ressemble une entrée utile et comment tenir le tout à jour sans que cela devienne un second métier.

Pourquoi un rapport d'audit de sécurité WordPress : démontrer, pas affirmer

Selon le RGPD, le responsable du traitement doit être en mesure de démontrer sa conformité. Appliquer les principes ne suffit pas (art. 5, § 2). L'article 32, paragraphe 1, point d), exige en outre une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures de sécurité. Si cette procédure existe réellement, elle laisse des traces écrites.

Cela concerne aussi les personnes qui interviennent sur le site. Les hébergeurs et les agences disposant d'un accès administrateur sont généralement des sous-traitants au sens de l'art. 28. Leurs clients leur réclameront donc le même type de preuves. Pour le contenu des mesures elles-mêmes, consultez notre guide sur l'article 32 du RGPD pour WordPress.

La documentation a ses limites. Elle peut attester que des mesures ont été mises en place, mais ne prouve pas à elle seule qu'elles restent efficaces. Elle ne rend pas un site sûr, et des documents seuls ne suffisent pas à remplir vos obligations au titre du RGPD. Une documentation périmée peut même être pire que rien. Une politique de sauvegarde qui décrit une extension supprimée l'an dernier indique à l'auditeur que vos registres ne sont pas tenus à jour.

Les six registres que consultent réellement auditeurs et clients

1. Inventaire. Il recense la version du cœur, chaque extension et chaque thème avec sa version, l'hébergeur, la version de PHP et les services tiers utilisés. Il indique aussi quelles données personnelles chaque élément touche. Une entrée utile ressemble à ceci : « Extension de formulaire de contact, enregistre les messages en base de données (nom, e-mail, message), suppression des entrées après 90 jours conformément à notre politique. » Mettez l'inventaire à jour à chaque changement et confrontez-le à la réalité chaque trimestre.

2. Journal des mises à jour. Chaque ligne indique la date, le composant, l'ancienne et la nouvelle version, l'auteur de la mise à jour et si elle s'est faite automatiquement. Ajoutez une entrée par modification. Les mises à jour automatiques comptent, mais quelqu'un doit vérifier ensuite que le site fonctionne toujours.

3. Rapports d'analyse. Conservez les rapports datés et leurs suites selon une politique de conservation documentée, plutôt que d'écraser simplement le rapport précédent. Consignez chaque constat et son traitement : corrigé, accepté avec justification, ou faux positif. Un rapport de dix constats sans suite montre que vous avez lancé une analyse. Il ne montre pas que vous avez agi sur ses résultats.

4. Sauvegardes et tests de restauration. Notez la fréquence, le lieu de stockage, la durée de conservation, ainsi que la date et le résultat du dernier test de restauration. Une tâche de sauvegarde réussie ne prouve pas que la restauration fonctionne. Comme point de départ pratique, testez la restauration chaque trimestre et après les changements importants ; adaptez ensuite la fréquence à vos risques et à vos besoins de reprise. Protégez les données personnelles restaurées en utilisant un environnement de test isolé.

5. Liste des accès. Indiquez qui détient quel rôle, si l'authentification à deux facteurs est activée pour chaque compte, la date de la dernière revue des accès, et la date de suppression des anciens collaborateurs ou prestataires. Mettez-la à jour à chaque changement et révisez-la chaque mois.

6. Journal des incidents. Consignez chaque incident de sécurité, y compris les violations de données personnelles que vous avez décidé de ne pas notifier. L'art. 33, § 5, vous impose de documenter toute violation : les faits, ses effets et les mesures prises pour y remédier. La notification elle-même est traitée dans notre guide des 72 heures.

À quoi ressemble une bonne preuve (et ce qui ne compte pas)

Les bons registres ont quatre points communs :

• Chaque entrée est datée.
• Chaque entrée porte le nom de la personne qui l'a rédigée.
• Toutes les entrées sont conservées au même endroit, de façon cohérente.
• Elles sont rédigées au fil de la routine, et non reconstituées la semaine précédant l'audit.

Un auditeur repère en général un journal écrit en un seul après-midi.

Comparez deux formulations du même fait. Faible : « Nous mettons régulièrement les extensions à jour. » Plus solide, sur ce modèle : « [date], [extension], [ancienne version] vers [nouvelle version], mise à jour automatique, [test effectué], vérifié par [nom]. » Remplacez chaque champ par les informations réelles. La seconde version est vérifiable, et elle témoigne d'une habitude.

Les exports valent mieux que les captures d'écran. Un fichier CSV des versions d'extensions ou un rapport d'analyse en PDF conserve ses données et sa date. Une capture recadrée du tableau de bord prouve peu et ne se prête à aucune recherche. Réservez les captures aux réglages qui n'offrent aucun export, et mettez la date dans le nom du fichier.

Stockez les registres hors du serveur WordPress. Si le site est compromis, l'attaquant ne doit pas pouvoir modifier vos preuves, et vous en aurez besoin pendant la remise en état. Un espace partagé à accès contrôlé est une solution praticable : limitez les droits de modification, activez l'historique des versions et protégez-le par des identifiants distincts de ceux du site WordPress.

Restez proportionné. Pour une petite entreprise, un tableur avec un onglet par registre et un dossier daté de fichiers PDF constituent un très bon dossier de preuves. Personne n'attend une plateforme de gouvernance pour un site de dix pages.

Répondre aux questionnaires fournisseurs des clients soumis à NIS 2

Agences, indépendants et éditeurs d'extensions reçoivent des questionnaires de sécurité, même lorsque NIS 2 ne les concerne pas directement. La raison tient à l'art. 21, § 2, point d), de la directive NIS 2. La directive impose des mesures de sécurité de la chaîne d'approvisionnement, ce qui peut conduire les clients à demander des preuves à leurs fournisseurs. Les obligations applicables résultent du droit national de transposition : vérifiez la législation de votre pays. Savoir si votre client ou vous-même relevez du champ d'application est une autre question, traitée dans NIS 2 et votre site WordPress.

Les questions varient selon le client et le contrat : lisez donc le questionnaire réel. Les thèmes suivent généralement les mesures de l'art. 21, § 2, et chacun correspond à un registre que vous tenez déjà :

Ne répondez que sur ce que vous pouvez prouver. Si le formulaire n'offre qu'un choix oui/non, ajoutez une courte précision ou proposez le document, par exemple : « Oui, chaque mois. Les trois derniers rapports d'analyse sont disponibles sur demande. » Si une mesure n'est que partiellement en place, dites-le. Une réponse exagérée dans un contrat fournisseur est déjà un risque en soi.

Questionnaires des assureurs cyber : mêmes preuves, lisez le formulaire exact

Les assureurs posent leurs propres questions, et la formulation diffère de l'un à l'autre. Vos réponses peuvent compter plus tard, en cas de déclaration de sinistre. Répondez avec exactitude, conservez une copie datée de ce que vous avez transmis, et revoyez vos réponses lorsque votre configuration change. Un nouvel hébergeur ou l'abandon d'une exigence de double authentification en sont des exemples.

Les thèmes courants, comme les sauvegardes, l'authentification multifacteur et les correctifs, renvoient aux mêmes six registres. Ce qu'exige une police précise, et l'effet de vos réponses sur la garantie, dépend du libellé du contrat et relève de votre courtier.

Tenir la documentation à jour sans travail supplémentaire

Le calendrier ci-dessous est un point de départ pratique, pas un minimum légal. Adaptez-le à vos risques, à votre rythme de changement et à vos exigences contractuelles :

La revue annuelle doit être validée par une personne disposant de l'autorité nécessaire. Pour les entités relevant du droit national issu de NIS 2, l'article 20 impose aux organes de direction d'approuver les mesures de cybersécurité, d'en superviser la mise en œuvre et de suivre des formations. Une signature annuelle ne démontre pas à elle seule un suivi continu ; conservez la trace des décisions, des revues et des actions de suivi.

Automatisez les exports. Avec WP-CLI, une tâche cron mensuelle sur le serveur, ou un script lancé depuis votre poste, peut produire des fichiers datés :

wp core version > core-$(date +%F).txt
wp plugin list --format=csv > plugins-$(date +%F).csv
wp theme list --format=csv > themes-$(date +%F).csv
wp user list --role=administrator --format=csv > admins-$(date +%F).csv

Exécutez les commandes depuis un répertoire situé hors de la racine web, en indiquant le site à WP-CLI avec --path=/chemin/vers/wordpress, afin que les exports ne soient jamais accessibles publiquement. Copiez-les ensuite dans votre espace de preuves. L'export des administrateurs contient des adresses e-mail : traitez-le comme une donnée personnelle.

Les rapports d'analyse vont dans le même dossier. L'extension Security Audit & Compliance de secaudit.eu exporte un rapport et un fichier CSV dont les constats sont rattachés à l'art. 32 du RGPD, à l'art. 21 de NIS 2 et à l'OWASP Top 10:2025, que vous pouvez classer directement dans le dossier de preuves. Un tel rapport montre qu'un contrôle a eu lieu et ce qu'il a relevé, rien de plus. Pour les mesures qui sous-tendent chaque registre, appuyez-vous sur notre checklist de sécurité WordPress.

Modèle : plan d'un rapport d'audit de sécurité WordPress

Reprenez cette structure et remplissez-la à partir de vos six registres :

1. Périmètre et date : quel(s) site(s), quelle période, qui a rédigé le rapport.
2. Site et personnes responsables : propriétaire, contact technique, sous-traitants (hébergeur, agence) et état de leurs accords de sous-traitance (art. 28).
3. Synthèse de l'inventaire : cœur, PHP, nombre d'extensions et de thèmes, services tiers, données personnelles traitées.
4. Mesures en place, rattachées à l'art. 32, § 1, points a) à d) : chiffrement ; confidentialité, intégrité et disponibilité ; capacité de restauration ; tests réguliers.
5. État des mises à jour et des vulnérabilités : composants obsolètes, vulnérabilités connues, corrections prévues.
6. Résultats des analyses et remédiation : date de chaque analyse, constats, traitement.
7. Sauvegardes et tests de restauration : fréquence, stockage, durée de conservation, date et résultat du dernier test.
8. Revue des accès : comptes par rôle, couverture de la 2FA, comptes supprimés, date de la revue.
9. Incidents et violations consignés (art. 33, § 5), y compris ceux qui n'ont pas été notifiés.
10. Risques ouverts et actions prévues, chacune avec un responsable et une échéance.
11. Validation : nom, fonction, date.

Commencez ce mois-ci par deux actions : un export de l'inventaire et un test de restauration vers un site de préproduction. À elles deux, elles couvrent plusieurs des domaines du questionnaire du tableau ci-dessus. Pour alimenter le dossier en rapports d'analyse datés, l'extension d'audit de secaudit.eu lance les contrôles sur votre site et exporte les résultats → secaudit.eu.

Cet article est une information générale et ne constitue pas un avis juridique.

FAQ

Combien de temps conserver les registres de sécurité ?

Le RGPD ne fixe pas de durée de conservation unique pour ces registres. Conservez-les aussi longtemps que nécessaire pour démontrer votre conformité, et vérifiez si votre secteur ou vos contrats imposent des durées précises. Définissez les durées par type de registre et par finalité ; ne conservez pas indéfiniment des données personnelles au seul motif que la configuration est toujours utilisée. Les données personnelles contenues dans les registres, comme les adresses e-mail des administrateurs, ne doivent pas être gardées plus longtemps que nécessaire.

Un rapport d'audit sans anomalie signifie-t-il que nous respectons le RGPD ?

Non. Un rapport montre que certains contrôles techniques ont été réussis à une date donnée. Le RGPD couvre aussi les bases légales, le consentement, les contrats avec les sous-traitants, les droits des personnes concernées et bien d'autres sujets. Même sur le seul volet de la sécurité, une analyse sans anomalie ne dit rien de la manière dont votre équipe gère les mots de passe ou l'hameçonnage.

Notre agence peut-elle tenir la documentation à notre place ?

Oui, et les agences disposent souvent des meilleures données. Le responsable du traitement reste toutefois redevable. Inscrivez les obligations de documentation dans l'accord de l'art. 28 en précisant ce qui est consigné, à quelle fréquence et comment vous y accédez. Gardez votre propre copie afin que les preuves ne quittent pas l'entreprise avec l'agence.