ISO 27001 : le « green tick » ne passe pas l'audit

Le contrôle A.8.13 (Information backup) d'ISO/IEC 27001:2022 tient en une phrase : maintenir des copies de sauvegarde des informations, des logiciels et des systèmes, et les tester régulièrement conformément à une politique de sauvegarde alignée sur les besoins métier.

La première moitié, tout le monde la fait. C'est la seconde qui fait échouer les audits.

Ce que l'auditeur demande concrètement

Les guides d'audit du contrôle A.8.13 sont explicites sur les preuves attendues :

• une politique de sauvegarde documentée et approuvée : fréquences, rétention, responsabilités, périmètre croisé avec le registre des actifs ;
• des RPO et RTO définis par actif sur la base d'une analyse d'impact métier — un objectif unique pour tout le SI est une erreur classique ;
• des logs d'exécution montrant que les jobs tournent et que les échecs déclenchent des alertes (un job qui échoue silencieusement = non-conformité) ;
• et surtout : des rapports de tests de restauration horodatés, généralement datant de moins de 6 à 12 mois, comparant le temps de restauration réel au RTO cible.

Sur ce dernier point, les guides sont sans ambiguïté : une capture d'écran « Job Successful » dans la console de backup est insuffisante. Restaurer un fichier isolé n'est pas un test de reprise. Et si le temps de restauration mesuré dépasse significativement le RTO défini dans le PCA, c'est une non-conformité — même si la restauration a fonctionné.

Pourquoi ce contrôle est si souvent en écart

Parce qu'un vrai test de restauration coûte cher en temps humain : provisionner un environnement isolé, récupérer l'archive, restaurer, valider l'intégrité des données, mesurer la durée, documenter, nettoyer. Fait à la main, c'est une demi-journée d'ingénieur par système critique. Résultat prévisible : le test se fait une fois avant l'audit, dans l'urgence, et la preuve produite est fragile.

L'autre obstacle est la confidentialité : tester une restauration de base de production implique de manipuler des données réelles. Les externaliser vers un outil cloud tiers crée un problème RGPD là où on cherchait à résoudre un problème ISO.

L'approche RestoreProof : la preuve en continu, les données chez vous

RestoreProof transforme le test de restauration en tâche planifiée qui produit nativement la preuve d'audit :

1. Restauration réelle, automatisée : le runner, déployé sur votre infrastructure, télécharge la sauvegarde (S3 ou compatible, HTTP, local), la décompresse, démarre une base éphémère en conteneur (PostgreSQL, MySQL) et y restaure le dump.
2. Validation fonctionnelle : des sondes vérifient l'intégrité de l'archive, la présence de fichiers canaris, exécutent des requêtes SQL avec des seuils attendus (« la table users doit contenir au moins N lignes »), testent des endpoints HTTP.
3. Rapport signé : chaque exécution produit un rapport JSON horodaté — artefact testé, hash SHA-256, résultats par sonde, durées mesurées — signé en Ed25519 par une clé privée qui ne quitte jamais votre runner. La preuve est vérifiable et infalsifiable.
4. Historique d'audit : verdicts PASS/WARN/FAIL conservés selon votre plan de rétention, consultables et exportables au moment de l'audit.

Et le point qui change tout pour un RSSI : les données de sauvegarde et les credentials ne transitent jamais par le SaaS. Les secrets sont résolus localement (variables d'environnement, fichiers, Vault, SOPS). Le plan de contrôle ne voit que des métadonnées et des verdicts signés.

FAQ

À quelle fréquence ISO 27001 impose-t-elle de tester les restaurations ? La norme exige des tests « réguliers », sans fréquence chiffrée — c'est à l'organisation de la définir et de la justifier. En pratique, les auditeurs attendent des preuves récentes (souvent moins de 6 à 12 mois) et une fréquence cohérente avec la criticité des actifs. Un test automatisé quotidien ou hebdomadaire dépasse largement cette attente.

Quelle est la différence entre un log de backup et une preuve de restauration ? Le log de backup prouve qu'une copie a été écrite. La preuve de restauration démontre que cette copie permet de reconstruire un système exploitable, dans un délai mesuré. A.8.13 exige les deux.

Un rapport signé cryptographiquement a-t-il une valeur en audit ? Une signature Ed25519 garantit que le rapport n'a pas été modifié depuis sa génération et qu'il provient bien du runner détenteur de la clé. C'est une garantie d'intégrité supérieure à un PDF ou une capture d'écran, qui renforce la fiabilité de la piste d'audit.

Sources à lier : ISO/IEC 27001:2022, Annex A 8.13 ; guides d'implémentation et checklists d'audit A.8.13.