
Un audit interne donne à l'organisation l'occasion de découvrir où son système de management de la sécurité de l'information (SMSI) s'écarte de ses intentions. Le résultat utile est une évaluation étayée et une voie d'amélioration claire pour chaque constat significatif, et non simplement un dossier de captures d'écran préparé pour la certification.
Pour un responsable technique, la question centrale est de savoir si le système fonctionne à travers les services, les personnes et les passages de relais réels. Une politique peut être approuvée alors que sa mise en œuvre échoue. Un audit doit révéler cet écart sans transformer chaque imperfection opérationnelle en un constat de non-conformité non étayé.
Le chapitre 9.2 de l'ISO/IEC 27001 exige la réalisation d'audits internes à intervalles planifiés afin d'évaluer la conformité aux exigences propres de l'organisation concernant son SMSI et aux exigences de la norme, ainsi que la mise en œuvre et la tenue à jour efficaces du SMSI. Le programme d'audit doit tenir compte de l'importance des processus et des résultats des audits précédents, et les auditeurs doivent être choisis de manière à garantir l'objectivité et l'impartialité.
Un audit interne peut être réalisé par des salariés ou par un spécialiste externe mandaté à cet effet. Il ne délivre pas de certificat : la certification est une évaluation distincte menée par un organisme de certification indépendant. Les audits internes font toujours partie du fonctionnement du SMSI après la certification ; ils ne servent pas uniquement à préparer l'évaluation initiale.
L'ISO 27001 ne prescrit pas de fréquence annuelle universelle pour l'audit interne. Recommandation pratique : utilisez un calendrier documenté qui reflète les risques, les changements et les constats antérieurs, en accordant une attention plus fréquente aux processus instables ou critiques.
Un audit donné n'a pas besoin de tout examiner en même temps. Le programme doit assurer la couverture du SMSI dans son périmètre au fil de son cycle planifié, plutôt que d'inspecter de manière répétée les seules mesures familières.
Documentez ces décisions avant de demander des preuves :
| Décision | Ce qu'il faut consigner |
|---|---|
| Critères | Exigences pertinentes de l'ISO 27001, procédures internes et obligations applicables |
| Périmètre | Services, équipes, sites, systèmes et période d'exploitation examinés |
| Couverture | Exigences relatives au système de management des chapitres 4 à 10 et mesures retenues dans le cadre du traitement des risques et de la déclaration d'applicabilité |
| Responsabilités | Auditeur, responsables de processus, contacts spécialisés et destinataires du rapport |
| Méthodes | Entretiens, examen des enregistrements, observation et approche d'échantillonnage |
L'annexe A n'impose pas de mettre en œuvre chaque mesure de manière identique. Vérifiez si les décisions d'applicabilité et les exclusions sont justifiées, puis testez les engagements que l'organisation a réellement pris.
Choisissez des auditeurs compétents qui comprennent à la fois les exigences du système de management et les mesures examinées. Évitez que des personnes auditent leur propre travail. Dans une petite équipe d'ingénierie, un auditeur externe ou un relecteur d'une autre fonction peut résoudre les conflits, à condition de disposer d'une compétence suffisante et d'un accès aux preuves.
Commencez par le périmètre, l'appréciation des risques, le plan de traitement, la déclaration d'applicabilité, les politiques, les constats antérieurs et les enregistrements opérationnels pertinents. Ils expliquent ce qui devrait se passer et où les défaillances compteraient le plus.
Formulez ensuite des questions vérifiables. Pour les accès à privilèges, demandez-vous si les approbations précèdent l'attribution des accès, si les revues couvrent la population de comptes concernée et si les autorisations révoquées disparaissent réellement. Une politique d'accès signée établit l'intention ; les exports de comptes, les traces d'approbation et les journaux de suppression établissent le fonctionnement.
Établissez un plan d'échantillonnage qui inclut les changements récents, les services critiques, les faiblesses antérieures et les exceptions. Consignez la population, la méthode de sélection, la période et la justification. Un échantillonnage pratique n'a pas besoin d'une taille d'échantillon fixe unique, mais il doit pouvoir être expliqué. Une poignée de captures d'écran choisies par commodité représente rarement toute une période d'exploitation.
Recoupez les enregistrements avec les entretiens et l'observation. Si les responsables décrivent un passage de relais manuel, examinez des passages de relais effectués. Si les preuves contredisent un entretien, enquêtez au lieu de retenir la version la plus rassurante. Consignez les limites lorsqu'un système ne peut pas fournir de preuves historiques ; ne déduisez pas silencieusement les performances passées de sa configuration actuelle.
Hypothèses illustratives : une entreprise SaaS audite les départs de salariés sur trois mois. Sa procédure exige la suppression des accès au plus tard à l'heure du départ du salarié. Les dossiers RH recensent 12 départs ; l'auditeur examine les trois utilisateurs à privilèges et quatre départs supplémentaires dans différentes équipes.
L'auditeur compare les horodatages de départ des RH avec les événements du fournisseur d'identité, l'état des comptes applicatifs et les tickets de départ. Le compte d'un ancien ingénieur chez le fournisseur d'identité a été désactivé à temps, mais un compte de dépôt de code géré séparément est resté actif pendant deux jours.
Avant de qualifier le constat, établissez si le compte pouvait s'authentifier, quelles autorisations subsistaient et si une exception approuvée existait. Interrogez les RH et le responsable de l'application pour comprendre le passage de relais. Étendez les tests à d'autres départs impliquant des applications gérées séparément si l'omission semble systémique.
Un constat défendable identifie la procédure enfreinte, la situation observée, les enregistrements à l'appui, le périmètre concerné et la conséquence potentielle. Il ne doit pas affirmer qu'un accès non autorisé a eu lieu, sauf si les preuves étayent cette conclusion.
Une non-conformité exige la preuve qu'une exigence n'a pas été satisfaite. Une opportunité d'amélioration identifie une évolution utile sans démontrer de manquement. Une question non résolue reste ouverte jusqu'à ce que des preuves suffisantes étayent une conclusion.
Utilisez des classifications cohérentes et hiérarchisez les constats selon l'exposition, la récurrence et l'étendue. Ne laissez pas un niveau de gravité remplacer le raisonnement. Donnez aux responsables de processus la possibilité de corriger les erreurs factuelles, tout en laissant à l'auditeur la responsabilité de la conclusion.
Le rapport doit indiquer le périmètre, les critères, les méthodes, les limites, les constats et l'évaluation d'ensemble étayée par les travaux réalisés.
Un plan d'action doit identifier un responsable, une échéance, la correction immédiate, la cause première et le changement destiné à éviter que le problème ne se reproduise. Supprimer le compte de dépôt de code corrige ce cas précis. Corriger l'inventaire incomplet des applications et le passage de relais entre les RH et l'informatique traite le processus.
N'acceptez pas l'« erreur humaine » comme cause première complète lorsque le processus repose sur la mémoire ou manque de responsable. Définissez des critères d'efficacité avant de clore l'action : par exemple, les départs suivants doivent inclure des contrôles rapprochés de l'inventaire des applications concernées.
Un ticket clos prouve l'exécution, pas nécessairement l'efficacité. Après la mise en œuvre, examinez un autre échantillon et conservez le résultat de la vérification. Rouvrez l'action si la même défaillance se reproduit.
Rendez compte à la direction concernée des faiblesses récurrentes, des actions en retard, des besoins en ressources et des décisions importantes relatives aux risques. Les résultats de l'audit interne sont un élément d'entrée de la revue de direction au sens de l'ISO 27001 ; cette revue est une activité distincte comportant d'autres éléments d'entrée obligatoires, et non une simple réunion destinée à approuver le rapport d'audit.
Secani relie exigences, preuves, responsables, tâches et décisions de revue afin que l'évaluation et le suivi restent dans leur contexte. Gardez les enregistrements à l'appui rattachés aux mesures concernées et préservez l'approbation humaine des conclusions tirées des preuves. Utilisez notre guide de préparation à l'audit pour organiser ces enregistrements avant les travaux sur le terrain.
L'étape suivante concrète consiste à choisir un processus critique, à désigner un auditeur impartial et à rédiger ses critères et son plan d'échantillonnage. Planifiez la vérification de l'efficacité au moment d'attribuer les actions correctives, et non après que tout le monde les a considérées comme terminées.
Secani réunit Scopes, preuves, tâches et agents d’IA dans un espace de travail partagé.
Comprenez le périmètre de C5, les types de rapports, les responsabilités des clients et les preuves que les fournisseurs cloud doivent maintenir reliées.
Posez des questions concrètes sur la qualification, l’expérience sectorielle, les attentes en matière de preuves, le calendrier, l’indépendance et le coût total de l’évaluation.
Lisez les certificats ISO et les rapports SOC 2 dans leur contexte : périmètre, période, exceptions, responsabilités du client et preuves de remédiation.