Pourquoi Vanta ne suffit pas pour passer un vrai audit ISO 27001 (et pourquoi votre auditeur va le voir)

#Le dashboard est vert. L'audit, lui, n'a pas encore commencé.

Scène classique de fin de cycle. Le RSSI ouvre Vanta lundi matin : 98 % de contrôles "passing", quelques alertes mineures sur des MFA non activés depuis 48 heures, un message rassurant signé Trust Center. Le stage 2 ISO 27001 est dans trois semaines. La direction est sereine. Le commercial a déjà mis le badge "ISO 27001 ready" sur la home page.

Cinq jours après le début de l'audit de certification, le rapport préliminaire tombe : sept non-conformités mineures, deux majeures, un avis défavorable sur le SoA. La certification est repoussée de six mois. Le Lead Auditor, poliment, recommande "de ne pas confondre outillage de conformité continue et système de management de la sécurité de l'information".

Cette situation, on la voit de plus en plus chez les éditeurs SaaS B2B qui ont structuré leur démarche ISO 27001 autour d'un GRC automatisé. Vanta, Drata, Secureframe, Sprinto, Tugboat Logic : tous excellents pour collecter de la preuve technique en continu, tous insuffisants pour passer une certification accréditée par un auditeur tiers sérieux. Cet article explique précisément pourquoi.

#1. Ce qu'un Lead Auditor regarde réellement (et que Vanta ne montre pas)

L'auditeur ISO 27001 envoyé par LSTI, Bureau Veritas, AFNOR Certification, BSI, DEKRA ou DNV n'est pas un robot qui coche des cases. Il a typiquement 10 à 25 ans d'expérience SI, il a déjà vu plusieurs centaines d'organisations, et il sait reconnaître en deux jours un SMSI vivant d'un SMSI cosmétique. Voici ce qu'il regarde, dans l'ordre de probabilité de découverte d'écart.

#Sampling de preuves, pas screenshots automatiques

Un auditeur ne se contente pas du rapport "MFA enforced on 247 accounts" exporté par Vanta. Il pioche cinq utilisateurs au hasard dans l'AD ou le SSO, demande à voir leur configuration MFA réelle, et croise avec les logs d'authentification des trente derniers jours. Si trois sur cinq ont contourné la MFA via des sessions persistantes ou des comptes de service mal classés, le contrôle A.5.17 (informations d'authentification) est en non-conformité, peu importe ce que dit le dashboard.

Vanta capture l'état au moment du scan. L'auditeur cherche les écarts entre l'état affiché et la réalité opérationnelle.

#Cohérence dans le temps

L'ISO 27001 est une norme de système, pas de point dans le temps. L'auditeur va demander : "Montrez-moi la revue trimestrielle des accès du Q3 2025, puis celle du Q4, puis celle du Q1 2026". Si les trois rapports sortent du même template Vanta avec les mêmes commentaires copiés-collés et la même date d'export, c'est une non-conformité sur A.5.18 (droits d'accès) et probablement sur la clause 9.1 (surveillance, mesure, analyse).

Une politique signée le 12 janvier, un risk register modifié le 12 janvier, un SoA exporté le 12 janvier, un PV de revue de direction daté du 12 janvier : ce n'est pas un SMSI, c'est une mise en scène. L'auditeur le voit immédiatement.

#Traçabilité humaine

Qui a pris la décision de classer ce risque comme "accepté" ? Sur quelle base ? Qui a validé le retrait du contrôle A.8.23 (filtrage web) du SoA ? Quel est le compte rendu de la discussion ?

Vanta horodate des actions techniques. Il ne capture pas les délibérations, les arbitrages, les remontées du terrain. Or la clause 7.5.3 (maîtrise des informations documentées) exige qu'on puisse retracer la décision jusqu'à son auteur et son contexte. Un Slack archivé, un email de validation, un PV de comité sécurité : c'est ce que l'auditeur veut voir, pas un statut "approved" dans un workflow.

#Tests de contrôle, pas déclarations

Le contrôle A.8.16 (activités de surveillance) dit que vous monitorez vos systèmes. Très bien. L'auditeur va demander : "Simulez devant moi une tentative de connexion depuis un pays inhabituel sur un compte admin. Montrez-moi l'alerte qui remonte, qui la traite, en combien de temps, et le ticket de clôture associé."

Si la réponse est "on a un SIEM, voici la copie d'écran de la règle", c'est insuffisant. Si la règle existe mais n'a jamais été testée en conditions réelles, c'est une non-conformité majeure. Vanta valide l'existence de l'outil, pas l'efficacité du processus.

#Cas particuliers, exceptions, dérives

Un SMSI sain produit des exceptions. Le dirigeant qui voyage en Asie avec un laptop non chiffré pendant 48 heures parce qu'il fallait dépanner un client. Le stagiaire qui a eu un accès admin temporaire pour migrer une base. Le sous-traitant qui n'a pas signé la dernière version du DPA parce qu'il négocie depuis trois mois.

L'auditeur cherche ces exceptions. Pas pour les sanctionner, mais pour vérifier qu'elles sont identifiées, documentées, validées au bon niveau, avec une date de retour à la normale. Une organisation qui n'a aucune exception sur 12 mois ment ou n'opère pas. Vanta ne sait pas faire émerger ces zones grises.

#2. Les angles morts structurels des GRC SaaS

Au-delà du sampling, il y a des sujets que l'architecture même d'un outil comme Vanta ne peut pas couvrir correctement.

#Politiques génériques pas vraiment lues

Vanta fournit une bibliothèque de politiques templatisées. Vous cliquez, vous personnalisez le nom de l'entreprise, vous obtenez 28 documents conformes au référentiel. Sauf qu'un auditeur va prendre votre politique de classification de l'information et demander à un dev choisi au hasard : "Quelles sont les quatre catégories de données chez vous, et où trouve-t-on la procédure pour qualifier un nouveau dataset ?". Si le dev répond "aucune idée", la politique existe sur le papier mais pas dans l'organisation.

Pire : ces templates contiennent souvent des engagements que l'entreprise ne tient pas (revue annuelle des fournisseurs critiques, test annuel du PCA, formation initiale obligatoire dans les 30 jours). L'auditeur lit la politique, demande la preuve, et constate l'écart. Non-conformité sur la clause 7.5 et souvent sur la clause 9.2 (audit interne).

#Risk assessment automatisé n'est pas analyse maturée

Le module risk de Vanta ou Drata propose une matrice 5x5, des catégories pré-remplies, et permet de générer un risk register en deux heures. Le résultat est syntaxiquement correct et sémantiquement vide.

Une vraie analyse de risque ISO 27005 (ou méthode équivalente comme EBIOS RM) demande un travail itératif : identification des actifs primaires et de support, scénarios de menace contextualisés au métier, évaluation de la vraisemblance basée sur des données historiques, plan de traitement argumenté. Ce travail prend 5 à 15 jours-homme la première fois et 2 à 5 jours-homme par révision annuelle. Il ne se clique pas.

Quand l'auditeur demande "pourquoi avez-vous coté ce risque à 12 et pas à 16 ?", la réponse "c'est ce que l'outil a calculé" est une non-conformité majeure sur la clause 6.1.2.

#SoA cliqué n'est pas SoA argumenté

La déclaration d'applicabilité (Statement of Applicability) est le document le plus regardé en stage 2. L'Annexe A de la norme 27001:2022 contient 93 contrôles. Pour chacun, vous devez dire : applicable ou pas, et pourquoi.

Vanta génère un SoA en cochant des cases. Un Lead Auditor va prendre dix contrôles au hasard et vous demander :

• Pour A.8.28 (codage sécurisé) : montrez-moi votre standard de coding sécurisé, le linter qui l'applique, un exemple de PR rejetée pour cause de non-conformité au standard, et la formation associée des développeurs.
• Pour A.5.7 (renseignements sur les menaces) : quelle est votre source de threat intelligence, qui consomme les bulletins, comment ils sont intégrés à votre processus de gestion des vulnérabilités.
• Pour A.7.4 (surveillance de la sécurité physique) : vos locaux, vos datacenters, ou vous vous appuyez intégralement sur AWS ? Si AWS : quelle preuve avez-vous de leur surveillance physique (rapport SOC 2 type II d'AWS, clause de votre contrat) ?

Un SoA cliqué donne "Applicable. Justification : applicable to our operations." Un SoA argumenté donne trois paragraphes par contrôle avec des références internes vérifiables. La différence se voit en 30 secondes.

#Audit interne par questionnaire n'est pas audit interne réel

La clause 9.2 exige un audit interne avant la certification. Vanta propose des modules d'audit interne où le RSSI répond lui-même à 200 questions sur ses propres contrôles. C'est un auto-questionnaire, pas un audit interne au sens de la norme ISO 19011.

Un audit interne ISO 27001 sérieux est conduit par une personne indépendante du périmètre audité, suit un programme d'audit pluriannuel, produit des constats argumentés, et alimente la revue de direction. Le faire en interne est légitime à condition d'avoir une équipe sécurité de plus de 3-4 ETP. En dessous, il faut sous-traiter à un cabinet externe. Vanta ne remplace ni l'un ni l'autre.

#Non-conformités historiques cachées

Quand vous adoptez Vanta en cours de cycle, l'outil démarre la collecte à partir de la date d'installation. Tout ce qui s'est passé avant est invisible. Or l'auditeur va demander : "Qu'est-ce qui s'est passé sur les 12 derniers mois ? Avez-vous eu des incidents ? Comment les avez-vous traités ?".

Si vous avez eu un incident GitHub Actions exposant des secrets en mars, un dépôt public exposant un fichier .env en juin, une fuite de données client en septembre, et que rien n'est documenté dans Vanta parce qu'il a été déployé en novembre : non-conformité sur A.5.24 à A.5.28 (gestion des incidents) et clause 10 (amélioration). L'auditeur trouve ces incidents en cherchant dans GitHub, dans la presse spécialisée, ou en posant des questions ouvertes aux équipes.

#BCP testé sur le papier

Le contrôle A.5.30 (préparation TIC pour la continuité d'activité) demande des tests réguliers du plan de continuité. Vanta sait stocker un document PCA et tracer une attestation "tested on YYYY-MM-DD". Il ne sait pas vérifier que le test a effectivement eu lieu.

Un Lead Auditor demande : qui a participé ? Quel scénario ? Quelle durée ? Quels indicateurs RTO/RPO mesurés ? Quelles actions correctives ouvertes suite au test ? Quelle date de retest ? Un PCA testé "au RUN sans interruption de service" un mardi à 14 h sans plan de bascule documenté n'est pas un test, c'est une fiction.

#3. Cinq cas concrets où le stage 1 passe et le stage 2 plante

Ces situations sortent d'audits blancs réalisés ces 18 derniers mois sur des entreprises de 30 à 250 personnes, toutes équipées d'un GRC SaaS, toutes "100 % ready" selon leur dashboard.

#Cas 1 : SoA non argumentée

Stage 1 : l'auditeur valide la présence du document.

Stage 2 : il prend 12 contrôles au hasard, demande les preuves d'application. Pour A.8.9 (gestion de la configuration), la justification dit "Géré via Terraform et infrastructure as code". L'auditeur demande à voir le repo, le processus de revue, la baseline de configuration, le drift detection. Réponse : Terraform existe pour AWS mais pas pour Azure, pas de revue formalisée, drift jamais mesuré. NC majeure.

#Cas 2 : revue d'accès cosmétique

Stage 1 : Vanta exporte les revues trimestrielles, signées électroniquement, datées correctement.

Stage 2 : l'auditeur prend la revue Q4 2025, identifie un compte "service-bot-legacy" listé comme "à supprimer". Il vérifie en Q1 2026 : le compte existe toujours, avec les mêmes droits, et a été utilisé 14 fois entre janvier et mars. La revue a été cliquée mais pas exécutée. NC majeure sur A.5.18 et clause 9.1.

#Cas 3 : analyse de risque obsolète

Stage 1 : un risk register de 47 risques, validé en mars 2024.

Stage 2 : entre mars 2024 et avril 2026, l'entreprise a migré son backend de monolithe Ruby vers une architecture microservices Node.js sur Kubernetes, ouvert deux nouveaux marchés (Allemagne, Italie) avec hébergement en zone EU dédiée, et signé trois contrats avec des sous-traitants offshore. Aucun de ces changements n'apparaît dans le risk register. NC majeure sur 6.1.2 et 8.2.

#Cas 4 : sous-traitants non évalués

Stage 1 : Vanta liste 34 fournisseurs avec un statut "compliant" basé sur la collecte automatique de leur SOC 2 ou ISO 27001.

Stage 2 : l'auditeur demande l'évaluation des risques associés aux 8 sous-traitants critiques (ceux qui traitent de la donnée client en clair). Il découvre qu'un prestataire d'envoi d'emails transactionnels n'a aucune certification, n'a pas signé de DPA conforme RGPD, et n'a jamais été auditrié. NC majeure sur A.5.19 à A.5.22.

#Cas 5 : sensibilisation tracée mais pas faite

Stage 1 : Vanta affiche 100 % de complétion de la formation sécurité annuelle.

Stage 2 : l'auditeur fait un quiz oral à 5 collaborateurs pris au hasard. Trois sur cinq sont incapables de citer le canal de signalement d'un incident, deux sur cinq ne savent pas ce qu'est un phishing en interne, un seul connaît l'existence de la politique de mot de passe. La formation a été cliquée en 90 secondes sur un mobile pendant une pause café. NC majeure sur A.6.3 et clause 7.3.

#4. Vanta accélère 30 à 40 % du périmètre. Pas plus.

Cet article n'est pas une charge contre Vanta. L'outil est sérieux, fait gagner du temps réel sur la collecte de preuves techniques, et structure une partie du travail. Concrètement, sur un cycle de certification ISO 27001 complet :

• ce que Vanta fait bien : monitoring continu des contrôles techniques (MFA, chiffrement, patch management, sauvegarde, durcissement cloud), centralisation documentaire, cartographie des employés et des accès, génération de Trust Center pour le commercial, alerting sur les dérives techniques de premier niveau.
• ce que Vanta ne fait pas : analyse de risque mature, SoA argumenté, audit interne indépendant, conduite du changement, formation réelle, tests de contrôle en conditions réelles, gestion des exceptions, traçabilité décisionnelle, BCP testé, gestion de la chaîne fournisseurs au-delà du statut SOC 2.

En ratio empirique : Vanta couvre correctement 30 à 40 % de la charge de travail d'une certification 27001. Les 60 à 70 % restants sont du travail humain : pilotage SMSI, animation des comités, rédaction argumentée, audit interne, formation opérationnelle, et surtout le dialogue avec un Lead Auditor qui sait reconnaître un système vivant.

L'erreur stratégique courante est de prendre les 30-40 % automatisés pour les 100 % nécessaires. Le réveil arrive en stage 2.

Pour aller plus loin sur la démarche complète, voir notre offre accompagnement ISO 27001 et notre méthode d'audit gap ISO 27001.

---

Vous avez Vanta mais doutez du résultat à l'audit ? On fait des audits blancs en 5-10 jours qui simulent stage 1 + stage 2. Verdict honnête, pas de complaisance. Programmer un audit blanc →

Équipe M-KIS