Audit interne ISO 27001 : Planification, Conduite et Rapport

Les audits internes sont l’un des mécanismes les plus essentiels du référentiel ISO 27001. Ils fournissent une évaluation indépendante permettant de déterminer si votre Système de Management de la Sécurité de l’Information (ISMS) est conforme aux exigences de la norme et à vos propres politiques documentées, et si l’ISMS est effectivement mis en oeuvre et maintenu. Sans audits internes, votre ISMS fonctionne à l’aveugle — vous ne disposez d’aucune preuve objective que ce que vous avez conçu correspond à ce que vous faites réellement.

De nombreuses entreprises SaaS traitent les audits internes comme un exercice de cases à cocher — une opération précipitée annuelle à travers une liste de contrôle générique qui produit un rapport que personne ne lit. Cela passe complètement à côté de l’objectif. Un audit interne bien mené est l’outil le plus efficace pour identifier les faiblesses avant que votre auditeur de certification ne les découvre, pour piloter l’amélioration continue et pour fournir à la direction les informations nécessaires à des décisions éclairées sur les investissements en sécurité.

Ce guide couvre tout ce que les équipes SaaS doivent savoir sur les audits internes ISO 27001 : les exigences de la Clause 9.2, la différence entre audits internes et audits de certification, comment planifier un programme d’audit, comment conduire des audits individuels, comment classifier et rapporter les constatations, et comment gérer les actions correctives jusqu’à leur clôture.

Ce que la Clause 9.2 exige

La Clause 9.2 est l’exigence normative pour les audits internes. Elle n’est pas longue, mais chaque mot compte.

Clause 9.2.1 — Généralités

L’organisation doit réaliser des audits internes à des intervalles planifiés pour fournir des informations permettant de déterminer si l’ISMS :

a) Est conforme aux propres exigences de l’organisation pour son ISMS b) Est conforme aux exigences de l’ISO 27001 c) Est effectivement mis en oeuvre et maintenu

Cela établit deux dimensions d’évaluation d’audit. Premièrement, la conformité — l’ISMS correspond-il à ce que la norme exige et à ce que vous avez documenté ? Deuxièmement, l’efficacité — l’ISMS atteint-il réellement les résultats escomptés ? Une politique peut exister (conformité), mais si personne ne la suit (inefficacité), l’audit doit le constater.

Clause 9.2.2 — Programme d’audit interne

L’organisation doit :

a) Planifier, établir, mettre en oeuvre et maintenir un programme d’audit, incluant la fréquence, les méthodes, les responsabilités, les exigences de planification et le reporting b) Définir les critères et le périmètre de chaque audit c) Sélectionner des auditeurs et conduire les audits de manière à assurer l’objectivité et l’impartialité du processus d’audit d) S’assurer que les résultats des audits sont communiqués à la direction concernée e) Conserver des informations documentées comme preuve du programme d’audit et des résultats d’audit

Cette clause impose plusieurs exigences concrètes :

• Vous avez besoin d’un programme d’audit (pas seulement d’audits individuels) qui couvre l’ensemble de l’ISMS sur un cycle défini
• Chaque audit nécessite des critères définis (ce contre quoi vous auditez) et un périmètre (ce que vous auditez)
• Les auditeurs doivent être objectifs et impartiaux — ils ne peuvent pas auditer leur propre travail
• Les résultats doivent être communiqués à la direction
• Vous devez conserver les preuves du programme et des résultats

Audit interne vs. audit de certification

Comprendre la distinction entre audits internes et audits de certification aide les équipes SaaS à aborder chacun correctement.

Audit interne

• Réalisé par ou pour le compte de l’organisation elle-même
• Objectif : Évaluer la conformité et l’efficacité de l’ISMS, identifier des opportunités d’amélioration
• Fréquence : À des intervalles planifiés définis par l’organisation (généralement annuellement, couvrant tous les domaines de l’ISMS sur un cycle de 12 mois)
• Auditeurs : Personnel interne, consultants contractuels, ou une combinaison — doivent être indépendants du domaine audité
• Résultat : Rapport d’audit interne avec constatations et recommandations
• Conséquences : Les constatations alimentent les actions correctives et l’amélioration via la revue de direction

Audit de certification — Étape 1 (Revue documentaire)

• Réalisé par un organisme de certification accrédité
• Objectif : Évaluer si la documentation de l’ISMS est adéquate et si l’organisation est prête pour l’audit d’Étape 2
• Fréquence : Une fois lors de la certification initiale, puis dans le cadre des cycles de surveillance ou de recertification
• Auditeurs : Auditeurs principaux de l’organisme de certification
• Résultat : Rapport d’Étape 1 identifiant les lacunes documentaires et les points de préoccupation
• Conséquences : Les lacunes significatives doivent être comblées avant de passer à l’Étape 2

Audit de certification — Étape 2 (Audit de mise en oeuvre)

• Réalisé par le même organisme de certification
• Objectif : Évaluer si l’ISMS est mis en oeuvre et fonctionne efficacement
• Fréquence : Une fois lors de la certification initiale, annuellement lors de la surveillance, tous les trois ans pour la recertification
• Auditeurs : Auditeurs principaux de l’organisme de certification
• Résultat : Rapport d’audit avec non-conformités et décision de certification
• Conséquences : Les non-conformités majeures doivent être résolues avant l’octroi de la certification

Comment les audits internes soutiennent la certification

Votre audit interne est votre répétition générale avant l’audit de certification. Il teste les mêmes éléments que l’auditeur de certification testera, en utilisant des méthodes similaires. Les constatations de votre audit interne vous laissent le temps de corriger les problèmes avant que l’auditeur de certification ne les découvre.

Les auditeurs de certification examineront également votre programme d’audit interne et ses résultats dans le cadre de leur évaluation. Ils vérifient que :

• Vous disposez d’un programme d’audit interne actif
• Il couvre l’ensemble du périmètre de l’ISMS
• Les auditeurs étaient compétents et indépendants
• Les constatations ont été identifiées et traitées par des actions correctives
• Les résultats ont été communiqués à la direction

Si votre programme d’audit interne est faible, superficiel ou inexistant, les auditeurs de certification le signaleront comme une non-conformité significative car cela indique que la Clause 9.2 n’est pas respectée.

Planification du programme d’audit

Un programme d’audit est le plan global qui garantit que chaque partie de votre ISMS est auditée sur un cycle défini. Les audits individuels sont des événements planifiés au sein de ce programme.

Définir le cycle d’audit

La plupart des organisations utilisent un cycle d’audit de 12 mois aligné sur leur revue annuelle de l’ISMS. Au sein de ce cycle, chaque clause de l’ISO 27001 (Clauses 4 à 10) et chaque contrôle applicable de l’Annex A doit être audité au moins une fois.

Approche 1 : Audit exhaustif unique. Auditer l’ensemble de l’ISMS en un seul événement, généralement sur 3 à 5 jours. Cela fonctionne bien pour les entreprises SaaS plus petites (moins de 100 employés) avec un ISMS au périmètre restreint.

Avantages : Simple à planifier, fournit une image complète à un instant donné. Inconvénients : Gourmand en ressources, perturbateur, les constatations arrivent toutes en même temps, ce qui peut surcharger le processus d’actions correctives.

Approche 2 : Programme d’audit glissant. Diviser l’ISMS en domaines d’audit et planifier des audits séparés tout au long de l’année. Par exemple :

• T1 : Contrôle d’accès (A.5.15-A.5.18, A.8.2-A.8.5), Sécurité des ressources humaines (A.6.1-A.6.5)
• T2 : Gestion des incidents (A.5.24-A.5.28), Continuité d’activité (A.5.29-A.5.30)
• T3 : Sécurité des opérations (A.8.6-A.8.16), Cryptographie (A.8.24), Sécurité réseau (A.8.20-A.8.23)
• T4 : Gouvernance (Clauses 4-7), Gestion des risques (Clause 6, A.5.1-A.5.8), Gestion des fournisseurs (A.5.19-A.5.23)

Avantages : Répartit l’effort et les perturbations sur l’année, permet de traiter les actions correctives en continu, fournit des preuves plus actuelles. Inconvénients : Complexité de planification accrue, nécessite une disponibilité constante des auditeurs tout au long de l’année.

Approche 3 : Programme d’audit basé sur les risques. Prioriser les domaines d’audit en fonction du risque : les domaines à risque plus élevé, ayant subi des changements récents ou des non-conformités antérieures reçoivent davantage d’attention d’audit (fréquence plus élevée, périmètre plus approfondi). Les domaines à risque plus faible peuvent être audités moins fréquemment mais toujours au sein du cycle.

Recommandation SaaS : Pour la plupart des entreprises SaaS visant une certification initiale, commencez par un audit exhaustif unique planifié 2 à 3 mois avant votre audit de certification d’Étape 2. Cela vous laisse suffisamment de temps pour traiter les constatations avant l’arrivée de l’auditeur de certification. Après la certification initiale, passez à un programme glissant qui répartit la charge de travail sur l’année.

Priorisation basée sur les risques

Tous les domaines de l’ISMS ne présentent pas le même niveau de risque. Votre programme d’audit doit en tenir compte en allouant davantage de temps et de profondeur d’audit aux domaines à risque plus élevé.

Domaines à risque plus élevé (plus de temps et de profondeur d’audit) :

• Contrôle d’accès — La source la plus fréquente de constatations d’audit
• Gestion des incidents — Impact direct sur la confiance des clients et les obligations réglementaires
• Évaluation et traitement des risques — Le fondement de l’ISMS ; les faiblesses ici compromettent tout le reste
• Gestion des fournisseurs — Surveillance accrue en raison des attaques de la chaîne d’approvisionnement
• Domaines ayant subi des changements significatifs depuis le dernier audit
• Domaines où des audits précédents ont identifié des non-conformités

Domaines à risque plus faible (couverture d’audit standard) :

• Sécurité physique (pour les entreprises SaaS exclusivement cloud avec une infrastructure physique minimale)
• Gestion documentaire (importante mais généralement stable une fois établie)
• Domaines n’ayant pas changé et sans constatations antérieures

Documentation du programme d’audit

Documentez votre programme d’audit sous forme de plan formel. Il doit inclure :

• La période du cycle d’audit (par ex., janvier 2026 à décembre 2026)
• Tous les audits planifiés avec les dates cibles
• Le périmètre (domaines/contrôles de l’ISMS) couvert par chaque audit
• Les critères d’audit pour chaque audit
• Les auditeurs assignés
• L’objectif global du programme
• La référence aux résultats du cycle précédent et leur influence sur les priorités actuelles

Ce document constitue la preuve que vous respectez la Clause 9.2.2(a). Les auditeurs de certification le demanderont.

Compétence et indépendance des auditeurs

Qui peut réaliser des audits internes ?

L’ISO 27001 exige que les auditeurs soient objectifs, impartiaux et compétents. Elle n’exige pas que les auditeurs détiennent des certifications ou qualifications spécifiques. Cependant, ils doivent posséder des connaissances suffisantes en :

• Exigences de l’ISO 27001 (Clauses 4-10 et Annex A)
• Principes et techniques d’audit
• ISMS de l’organisation et son contexte
• Concepts de sécurité de l’information pertinents pour les domaines audités

Indépendance et impartialité

La règle fondamentale : les auditeurs ne doivent pas auditer leur propre travail. La personne qui a conçu un contrôle, rédigé une politique ou gère un processus ne peut pas auditer ce contrôle, cette politique ou ce processus. Cela ne signifie pas que les auditeurs doivent être entièrement externes à l’organisation — cela signifie qu’ils doivent être indépendants du domaine spécifique audité.

Options pour atteindre l’indépendance dans les entreprises SaaS :

Audit croisé interne. Les membres de l’équipe auditent des domaines hors de leur responsabilité. Le responsable ingénierie audite la sécurité RH. Le responsable des opérations audite le contrôle d’accès. Le responsable conformité audite la réponse aux incidents (en supposant qu’il n’a pas conçu le processus de réponse aux incidents).

Avantages : Pas de coût externe, les auditeurs comprennent l’organisation, les constatations sont exploitables. Défis : Nécessite plusieurs personnes ayant des compétences d’audit, potentiel de biais inconscient entre collègues.

Consultant ou cabinet d’audit contractuel. Faire appel à un consultant externe pour réaliser ou diriger l’audit interne. Cela garantit une indépendance claire et apporte généralement des compétences d’audit expérimentées.

Avantages : Indépendance incontestable, méthodologie d’audit professionnelle, benchmarking avec d’autres organisations. Défis : Coût (5 000 $ à 20 000 $+ selon le périmètre et la complexité), moins de contexte organisationnel, nécessite de la coordination.

Approche hybride. Un auditeur principal externe réalise l’audit avec du personnel interne servant de co-auditeurs ou de guides. Cela combine indépendance et connaissance organisationnelle.

Recommandation SaaS : Pour la certification initiale, envisagez de faire appel à un consultant externe pour au moins le premier audit interne. Il apporte une expertise en méthodologie d’audit et peut encadrer le personnel interne qui réalisera les audits futurs. Pour les années suivantes, passez à un modèle d’audit croisé interne complété par des ressources externes pour les domaines à haut risque.

Formation des auditeurs

Si vous prévoyez d’utiliser du personnel interne pour les audits, investissez dans leur développement :

• Formation d’auditeur interne ISO 27001 (généralement 2 jours, disponible auprès de BSI, PECB, prestataires certifiés IRCA) — C’est l’investissement de formation le plus courant et couvre la planification d’audit, la collecte de preuves, la classification des constatations et le reporting
• Formation ISO 19011 — La norme pour l’audit des systèmes de management, qui fournit des orientations complètes sur les principes et la méthodologie d’audit
• Observation d’auditeurs expérimentés lors d’audits externes ou de certification pour apprendre les techniques et l’approche

Conservez les registres de formation comme preuve de la compétence des auditeurs. Les auditeurs de certification vérifieront que vos auditeurs internes étaient compétents.

Planification d’un audit individuel

Chaque audit au sein de votre programme nécessite sa propre phase de planification. Une planification approfondie fait la différence entre un audit qui produit des constatations exploitables et un audit qui fait perdre du temps à tout le monde.

Définir le périmètre d’audit

Le périmètre d’audit spécifie exactement ce qui sera examiné. Soyez précis :

• Quels domaines/clauses/contrôles de l’ISMS seront audités
• Quels départements, équipes ou fonctions seront inclus
• Quels systèmes, applications ou composants d’infrastructure sont dans le périmètre
• Quels sites (pour les organisations distribuées)
• Quelle période l’audit couvre (preuves de quand à quand)

Exemple de déclaration de périmètre : « Cet audit couvre la mise en oeuvre et l’efficacité du contrôle d’accès (contrôles Annex A A.5.15 à A.5.18 et A.8.2 à A.8.5) sur tous les systèmes de production, l’infrastructure cloud et les applications d’entreprise dans le périmètre de l’ISMS. La période d’audit est du 1er janvier 2026 au 31 mars 2026. Les équipes ingénierie, opérations IT et gestion du personnel sont dans le périmètre. »

Définir les critères d’audit

Les critères d’audit sont les références contre lesquelles vous évaluez la conformité. Ils incluent généralement :

• Les exigences de l’ISO 27001:2022 (clauses spécifiques)
• La documentation de l’ISMS de l’organisation (politiques, procédures, standards)
• La Déclaration d’Applicabilité
• Les exigences légales, réglementaires ou contractuelles applicables
• Les constatations d’audits précédents et les actions correctives

Élaboration du plan d’audit

Le plan d’audit est le document opérationnel qui structure l’exécution de l’audit :

Objectifs de l’audit : Ce que l’audit vise à déterminer. Exemple : « Déterminer si les politiques et procédures de contrôle d’accès sont conformes aux exigences de l’Annex A de l’ISO 27001 et sont effectivement mises en oeuvre sur les systèmes de production. »

Calendrier de l’audit : Date(s), heure(s) et lieux. Pour un audit ciblé (un seul domaine de l’ISMS), cela peut être une seule journée. Pour un audit exhaustif, 3 à 5 jours.

Équipe d’audit : Auditeur principal et éventuels co-auditeurs ou spécialistes techniques.

Contacts audités : Les personnes qui participeront aux entretiens et fourniront les preuves. Prévenez-les suffisamment à l’avance pour leur permettre de se préparer.

Liste de demande de preuves : Une liste préliminaire des documents, registres et accès système dont vous aurez besoin. L’envoyer à l’avance réduit les retards pendant l’audit. Exemples de demandes de preuves pour un audit de contrôle d’accès :

• Politique de contrôle d’accès actuelle (et preuves d’approbation et de communication)
• Listes d’accès utilisateurs pour tous les systèmes de production
• Listes d’accès privilégiés
• Registres de revue d’accès pour la période d’audit
• Registres de provisionnement et de déprovisionnement (échantillon de 10 à 15 sur la période d’audit)
• Liste des employés ayant quitté l’entreprise sur la période d’audit
• Configurations d’application du MFA
• Registres d’incidents liés aux accès

Liste de contrôle d’audit : Une liste détaillée de questions et de vérifications organisée par contrôle ou clause. C’est votre outil de travail pendant l’audit — il garantit que vous couvrez systématiquement chaque exigence.

Préparation de la liste de contrôle d’audit

Une liste de contrôle d’audit efficace traduit chaque exigence en questions spécifiques et testables. Pour chaque contrôle ou clause, incluez :

• L’exigence testée (référence à la clause, au contrôle ou à la déclaration de politique spécifique)
• La ou les questions d’audit — ce que vous allez demander ou vérifier
• La preuve attendue — à quoi ressemble la conformité
• Un espace pour les notes de l’auditeur, les références de preuves et la constatation préliminaire

Exemple d’entrée de liste de contrôle :

Référence	Exigence	Question d’audit	Preuve attendue
A.5.15 / Politique de contrôle d’accès Section 4.2	L’accès est accordé selon le principe du moindre privilège	Comment l’organisation s’assure-t-elle que les utilisateurs reçoivent uniquement l’accès nécessaire à leur rôle ? Pouvez-vous me montrer le modèle RBAC et son application ?	Modèle RBAC documenté. Registres d’accès utilisateurs correspondant aux définitions de rôle. Aucun utilisateur avec des permissions excessives.
A.5.18 / Politique de contrôle d’accès Section 6.1	Les droits d’accès sont révisés à des intervalles définis	Les revues d’accès ont-elles été réalisées selon le calendrier de la politique ? Montrez-moi les registres de revue.	Registres de revue d’accès complétés pour chaque période de revue planifiée. Constatations documentées et remédiations.
A.8.2 / Politique de contrôle d’accès Section 5	L’accès privilégié est restreint et contrôlé	Qui a un accès privilégié ? Comment est-il autorisé et surveillé ?	Liste documentée des accès privilégiés. Registres d’autorisation. Journaux d’activité des sessions privilégiées. Registres de revue trimestrielle.

Conduite de l’audit

Réunion d’ouverture

Chaque audit commence par une réunion d’ouverture. Elle fixe le ton et les attentes.

Participants : L’équipe d’audit, le responsable ou représentant ISMS, et les parties prenantes clés des domaines audités (responsables de département, propriétaires de systèmes).

Ordre du jour :

1. Confirmer le périmètre, les objectifs et les critères de l’audit
2. Passer en revue le calendrier et la logistique de l’audit
3. Confirmer les contacts clés et la disponibilité pour les entretiens
4. Expliquer la méthodologie d’audit (entretiens, revue documentaire, observation des systèmes, échantillonnage)
5. Expliquer comment les constatations seront classifiées et communiquées
6. Répondre aux questions de l’équipe auditée
7. Confirmer la confidentialité des informations d’audit

Conseil SaaS : Gardez la réunion d’ouverture concise — 20 à 30 minutes. Les équipes d’ingénierie et d’exploitation apprécient l’efficacité. Établissez que l’audit est un exercice constructif visant à identifier des opportunités d’amélioration, et non un examen punitif.

Méthodes de collecte de preuves

Les auditeurs collectent les preuves à travers quatre méthodes principales :

1. Revue documentaire

Examiner les informations documentées (politiques, procédures, registres, journaux) par rapport aux critères d’audit. C’est le fondement de chaque audit.

Ce qu’il faut examiner :

• Politiques et procédures : Sont-elles actuelles, approuvées, communiquées et alignées sur les exigences de l’ISO 27001 ?
• Registres : Démontrent-ils que les processus sont suivis comme documenté ?
• Journaux : Les journaux système confirment-ils que les contrôles techniques fonctionnent ?
• Rapports d’audits précédents et registres d’actions correctives : Les constatations antérieures ont-elles été traitées ?

Ce qu’il faut rechercher :

• Des documents qui font référence à d’autres documents qui n’existent pas (références cassées)
• Des politiques qui décrivent des processus différemment de leur fonctionnement réel
• Des registres manquants pour les activités requises (revues d’accès, évaluations des risques, revues de direction)
• Des documents obsolètes qui n’ont pas été révisés dans leur période de révision
• Des registres d’approbation manquants ou incomplets

2. Entretiens

Parler avec le personnel qui exécute des activités liées à la sécurité pour vérifier qu’il comprend et suit les procédures documentées.

Conseils pour les entretiens :

• Posez des questions ouvertes : « Décrivez-moi ce qui se passe lorsqu’un nouvel employé arrive » plutôt que « Suivez-vous la procédure d’intégration ? »
• Demandez des exemples spécifiques : « Pouvez-vous me montrer la dernière revue d’accès que vous avez réalisée ? »
• Menez les entretiens à plusieurs niveaux : managers (stratégie et supervision), praticiens (opérations quotidiennes) et employés en général (sensibilisation et conformité)
• Soyez attentif aux incohérences entre ce que décrivent différentes personnes — elles indiquent souvent des lacunes de processus

Exemples de questions d’entretien par rôle :

Pour le responsable ISMS :

• Comment suivez-vous la performance de l’ISMS par rapport aux objectifs de sécurité ?
• Décrivez-moi la dernière revue de direction — qu’est-ce qui a été discuté et quelles actions en sont ressorties ?
• Comment vous assurez-vous que tous les contrôles applicables de l’Annex A sont mis en oeuvre et opérationnels ?

Pour les responsables ingénierie :

• Comment l’accès à la production est-il géré pour votre équipe ?
• Que se passe-t-il lorsqu’un membre de l’équipe part — décrivez-moi le processus de déprovisionnement
• Comment gérez-vous les changements d’urgence en production ?

Pour les employés en général :

• Où trouveriez-vous la politique de sécurité de l’information ?
• Que feriez-vous si vous soupçonniez un incident de sécurité ?
• Quand avez-vous effectué votre dernière formation de sensibilisation à la sécurité ?

3. Observation des systèmes

Vérifier directement les contrôles techniques en examinant les configurations système, les tableaux de bord et les résultats.

Exemples :

• Examiner les configurations IAM dans AWS/Azure/GCP pour vérifier l’application du MFA
• Vérifier les paramètres du fournisseur d’identité pour confirmer la configuration SSO et les politiques d’accès conditionnel
• Examiner les tableaux de bord SIEM pour vérifier que la surveillance de sécurité est active
• Examiner les configurations de sauvegarde et vérifier les journaux de réalisation des sauvegardes récentes
• Examiner les paramètres du dépôt de code pour confirmer les règles de protection des branches
• Vérifier les configurations du scanner de vulnérabilités et les résultats de scans récents

Avantage SaaS : La plupart des configurations d’infrastructure SaaS peuvent être vérifiées via l’accès à la console ou les commandes CLI. Cela rend l’observation des systèmes plus rapide et plus complète que dans les environnements traditionnels où les auditeurs pourraient avoir besoin d’inspecter physiquement les centres de données.

4. Échantillonnage

Lorsqu’une revue complète de tous les registres est impraticable, sélectionnez un échantillon représentatif. L’échantillonnage doit être défini et justifié.

Guide d’échantillonnage :

• Pour les populations de moins de 10, examinez tous les éléments
• Pour les populations de 10 à 50, examinez au moins 10 éléments ou 25 % (le plus élevé des deux)
• Pour les populations de plus de 50, utilisez un échantillonnage statistique (généralement 25-30 éléments) ou une sélection basée sur les risques
• Documentez votre méthodologie et votre justification d’échantillonnage
• Incluez des éléments récents et plus anciens dans la période d’échantillonnage pour détecter les tendances

Scénarios d’échantillonnage courants :

• Registres de provisionnement des utilisateurs : Échantillonner 15 à 20 événements de provisionnement d’accès pour les nouvelles embauches sur la période d’audit
• Registres de déprovisionnement : Échantillonner tous les départs si moins de 10 ; sinon échantillonner 15 à 20 et croiser avec les listes de comptes actifs
• Registres de gestion des changements : Échantillonner 15 à 20 déploiements en production et vérifier que chacun a suivi le processus de changement documenté
• Registres de revue d’accès : Examiner toutes les revues d’accès planifiées (car il ne devrait y en avoir que 4 par an pour les revues trimestrielles)

Documentation des preuves

Pour chaque vérification de votre liste de contrôle d’audit, documentez :

• Ce que vous avez examiné (document, registre, système ou entretien spécifique)
• Ce que vous avez trouvé (observation factuelle, pas d’interprétation)
• La référence de preuve (nom du document et version, nom du fichier de capture d’écran, nom de l’interviewé et date, horodatage de l’entrée de journal)
• Votre évaluation préliminaire (conforme, non conforme, observation ou nécessite une investigation complémentaire)

Maintenez un dossier de preuves qui appuie chaque constatation. Si vous identifiez une non-conformité, la preuve doit être suffisamment spécifique pour qu’une personne absente de l’audit puisse comprendre l’écart.

Classification des constatations

Les constatations sont le résultat de l’audit — les écarts, faiblesses et points forts identifiés lors de la collecte de preuves. La façon dont vous classifiez les constatations affecte directement la manière dont elles sont priorisées et traitées.

Non-conformité majeure

Une non-conformité majeure existe lorsque :

• Un processus requis de l’ISMS est entièrement absent (par ex., aucune évaluation des risques n’a été réalisée)
• Un contrôle déclaré applicable dans la Déclaration d’Applicabilité n’est pas du tout mis en oeuvre
• Une défaillance systématique d’un contrôle ou d’un processus affecte la capacité de l’ISMS à atteindre ses résultats escomptés
• Plusieurs non-conformités mineures liées qui indiquent collectivement une défaillance systémique
• Une clause de l’ISO 27001 n’est pas respectée, et l’écart est significatif

Exemple : La politique de contrôle d’accès de l’organisation exige des revues d’accès trimestrielles, mais aucune revue d’accès n’a été réalisée au cours des 12 derniers mois. Les listes d’accès montrent plusieurs comptes actifs appartenant à des employés ayant quitté l’entreprise.

Importance : Lors d’un audit de certification, une non-conformité majeure doit être résolue avant la délivrance du certificat. Lors d’un audit interne, une non-conformité majeure nécessite une action corrective immédiate avec une attention prioritaire de la direction.

Non-conformité mineure

Une non-conformité mineure existe lorsque :

• Un contrôle ou un processus est mis en oeuvre mais présente des lacunes ou incohérences isolées
• Un cas unique de non-conformité qui n’indique pas une défaillance systémique
• Une étape procédurale est occasionnellement ignorée mais pas systématiquement
• La documentation existe mais contient des inexactitudes mineures ou est légèrement obsolète

Exemple : La politique de contrôle d’accès exige un déprovisionnement dans les 24 heures suivant le départ. Sur 15 départs échantillonnés, 13 ont été déprovisionnés dans les 24 heures, mais 2 l’ont été après 48 heures en raison de lacunes de couverture pendant les jours fériés.

Importance : Lors d’un audit de certification, les non-conformités mineures doivent être reconnues avec un plan d’action corrective, mais elles ne bloquent pas la certification. Lors d’un audit interne, elles doivent être traitées dans un délai défini (généralement 30 à 90 jours).

Observations

Une observation est une constatation factuelle qui n’est pas une non-conformité mais mérite attention. Les types d’observations comprennent :

• Opportunité d’amélioration (OFI) : Un domaine conforme où l’organisation pourrait améliorer l’efficacité. Exemple : « Les revues d’accès sont réalisées comme requis, mais le processus de revue est manuel et gourmand en main-d’oeuvre. L’automatisation du flux de revue pourrait améliorer la cohérence et réduire la charge des réviseurs. »
• Observation positive : Un point fort ou une bonne pratique notable. Exemple : « L’organisation a mis en place un accès privilégié juste-à-temps avec révocation automatique, ce qui dépasse les exigences de l’Annex A et réduit significativement le risque d’accès privilégié persistant. »
• Indicateur de risque ou de tendance : Quelque chose qui est actuellement conforme mais tend vers la non-conformité. Exemple : « Les deux dernières revues d’accès ont été réalisées dans la dernière semaine de la période de revue. Si cette tendance se poursuit, une revue pourrait être manquée. »

Les observations sont précieuses pour l’amélioration continue et doivent être rapportées à la direction aux côtés des non-conformités. Elles démontrent que l’audit est allé au-delà de simples vérifications réussite/échec.

Structure du rapport d’audit

Le rapport d’audit est le résultat documenté formel de l’audit interne. Il doit être clair, factuel et exploitable. Les auditeurs de certification examineront vos rapports d’audit interne comme preuve que la Clause 9.2 est respectée.

Sections recommandées du rapport

1. Résumé exécutif

Un aperçu d’une page pour la direction. Incluez :

• Périmètre et objectifs de l’audit
• Dates et équipe d’audit
• Évaluation globale (conforme avec observations, non-conformités mineures identifiées, non-conformité majeure identifiée)
• Nombre de constatations par classification
• Thèmes clés ou problèmes systémiques

2. Détails de l’audit

• Critères d’audit (normes, politiques et documents de référence)
• Méthodologie d’audit (revue documentaire, entretiens, observation des systèmes, approche d’échantillonnage)
• Départements et personnel impliqués
• Limitations ou exclusions (tout élément dans le périmètre qui n’a pas pu être audité et pourquoi)

3. Constatations

Chaque constatation doit inclure :

• Numéro de constatation (pour le suivi et la référence)
• Classification (non-conformité majeure, non-conformité mineure, observation/OFI)
• Référence (la clause, le contrôle ou l’exigence de politique spécifique qui n’est pas respectée)
• Description (déclaration factuelle de ce qui a été trouvé, incluant les références de preuves)
• Impact (pourquoi cette constatation est importante — quel risque crée-t-elle ou quel objectif de l’ISMS affecte-t-elle)
• Action corrective recommandée (la suggestion de l’auditeur — l’audité décide de l’action réelle)

Exemple de constatation :

Constatation n°3 — Non-conformité mineure

Référence : A.8.2 (Droits d’accès privilégiés), Politique de contrôle d’accès v2.1 Section 5.3

Description : La Politique de contrôle d’accès exige des revues trimestrielles de tous les comptes privilégiés. Durant la période d’audit (janvier-mars 2026), une revue trimestrielle était due. La revue a été réalisée le 28 mars 2026, couvrant les comptes administrateurs AWS IAM, Azure AD et Okta. Cependant, la revue n’incluait pas les comptes administrateurs de base de données dans PostgreSQL (RDS) ni les comptes de service du pipeline CI/CD dans GitHub Actions. Ces comptes ont un accès de niveau production et relèvent du périmètre de la politique.

Preuve : Registre de revue d’accès daté du 28 mars 2026 (AR-2026-Q1). Inventaire des accès privilégiés (PAI-2026-03). La comparaison montre 12 comptes privilégiés dans l’inventaire qui n’étaient pas inclus dans la revue.

Impact : Les comptes privilégiés de base de données et CI/CD ne sont pas révisés conformément à la politique, créant un risque d’accès privilégié excessif ou périmé non détecté.

Action recommandée : Élargir le périmètre de la revue d’accès pour inclure tous les comptes privilégiés listés dans l’inventaire des accès privilégiés. Mettre à jour la procédure de revue pour inclure un contrôle de complétude par rapport à l’inventaire avant la clôture de la revue.

4. Observations positives

Documentez les domaines de force et les bonnes pratiques. Cela apporte de l’équilibre, reconnaît les équipes qui font bien les choses et donne à la direction une image complète.

5. Suivi des actions correctives

Un tableau récapitulatif de toutes les non-conformités avec des colonnes pour :

• Numéro de constatation
• Classification
• Description (brève)
• Responsable assigné
• Date de résolution cible
• Statut (ouvert/en cours/clôturé)

Ce suivi devient le document de travail pour le suivi des actions correctives.

6. Suivi de l’audit précédent

Passez en revue le statut des constatations de l’audit interne précédent. Vérifiez que les actions correctives ont été mises en oeuvre et sont efficaces. Si une constatation précédente est toujours ouverte, faites monter sa classification ou signalez-la comme un problème récurrent.

Actions correctives et suivi

Identifier les constatations ne représente que la moitié de la valeur d’un audit interne. L’autre moitié consiste à piloter des actions correctives qui résolvent réellement les problèmes sous-jacents.

Le processus d’action corrective

La Clause 10.1 de l’ISO 27001 exige que lorsqu’une non-conformité survient, l’organisation doit :

a) Réagir à la non-conformité — prendre des mesures immédiates pour la maîtriser et la corriger b) Évaluer la nécessité d’une action pour éliminer les causes — déterminer la cause racine et décider si une action corrective est nécessaire c) Mettre en oeuvre toute action nécessaire d) Examiner l’efficacité de toute action corrective prise e) Apporter des modifications à l’ISMS si nécessaire

C’est un processus structuré de résolution de problèmes, pas simplement une liste de tâches.

Étape 1 : Correction immédiate. Traitez le symptôme immédiat. Si des comptes orphelins ont été trouvés, désactivez-les maintenant. Si une revue d’accès manquante a été identifiée, réalisez la revue immédiatement. Cela stoppe l’hémorragie.

Étape 2 : Analyse des causes racines. Déterminez pourquoi la non-conformité s’est produite. Les comptes orphelins existent parce que la procédure de déprovisionnement ne comprend pas une liste de contrôle de tous les systèmes, et les systèmes hors du fournisseur d’identité sont manqués. La revue d’accès était incomplète parce que la procédure de revue ne fait pas référence à l’inventaire des accès privilégiés.

Techniques d’analyse des causes racines :

• 5 Pourquoi : Posez « pourquoi » de manière répétée jusqu’à atteindre la cause systémique. Pourquoi les comptes étaient-ils orphelins ? Parce que le déprovisionnement était incomplet. Pourquoi était-il incomplet ? Parce qu’il n’y a pas de liste de contrôle. Pourquoi n’y a-t-il pas de liste de contrôle ? Parce que la procédure a été rédigée avant que le paysage système actuel ne soit établi.
• Diagramme en arêtes de poisson/Ishikawa : Catégorisez les causes possibles (Personnes, Processus, Technologie, Politique) et analysez chaque catégorie.

Étape 3 : Plan d’action corrective. Définissez des actions spécifiques qui traitent la cause racine, pas seulement le symptôme. Assignez un responsable et une date cible pour chaque action.

• Correction (immédiate) : Désactiver les 5 comptes orphelins identifiés — Responsable : Opérations IT — Échéance : Sous 48 heures
• Action corrective : Mettre à jour la procédure de déprovisionnement pour inclure une liste de contrôle complète des systèmes — Responsable : Responsable sécurité — Échéance : 30 jours
• Action corrective : Mettre en place une vérification automatisée de la complétude du déprovisionnement comparant mensuellement les registres de départ RH avec les listes d’utilisateurs de tous les systèmes dans le périmètre — Responsable : Opérations IT — Échéance : 60 jours
• Action préventive : Ajouter la complétude du déprovisionnement au périmètre de la revue d’accès trimestrielle — Responsable : Responsable sécurité — Échéance : Prochaine revue trimestrielle

Étape 4 : Mise en oeuvre. Exécutez les actions correctives. Documentez ce qui a été fait, quand et par qui.

Étape 5 : Revue d’efficacité. Après la mise en oeuvre, vérifiez que l’action corrective a réellement résolu le problème. Cela peut signifier :

• Relancer le test d’audit original après la mise en oeuvre de l’action corrective
• Surveiller la récurrence sur une période définie (généralement un cycle)
• Inclure le domaine de la constatation dans le périmètre du prochain audit avec des tests ciblés

La revue d’efficacité est l’étape que la plupart des organisations sautent, et c’est l’étape que les auditeurs de certification vérifient spécifiquement. Si vous avez identifié une non-conformité, mis en oeuvre une action corrective, mais n’avez jamais vérifié que l’action était efficace, l’auditeur questionnera si le processus d’action corrective est véritablement opérationnel.

Délais pour les actions correctives

Définissez des délais standards dans votre procédure d’action corrective :

• Non-conformité majeure : Analyse des causes racines sous 2 semaines, plan d’action corrective sous 30 jours, mise en oeuvre sous 60-90 jours, revue d’efficacité sous 6 mois
• Non-conformité mineure : Analyse des causes racines sous 30 jours, mise en oeuvre de l’action corrective sous 60 jours, revue d’efficacité sous 6 mois
• Observations/OFI : Examinées lors de la revue de direction, traitées selon la priorité et la disponibilité des ressources

Communication à la direction

La Clause 9.2.2(d) exige que les résultats d’audit soient communiqués à la direction concernée. Cela alimente le processus de revue de direction (Clause 9.3), où la direction évalue la performance de l’ISMS et prend des décisions sur les ressources, les priorités et les améliorations.

Quoi communiquer :

• Synthèse des constatations (nombre et classification)
• Thèmes clés et problèmes systémiques
• Statut des actions correctives (ouvertes, en cours, en retard, clôturées)
• Tendances comparées aux audits précédents (amélioration, stabilité, déclin)
• Besoins en ressources pour les actions correctives
• Recommandations pour les améliorations de l’ISMS

Comment communiquer : Incluez les résultats d’audit comme point permanent de l’ordre du jour de votre revue de direction. Pour les constatations significatives, fournissez un briefing intermédiaire à la direction plutôt que d’attendre la prochaine revue planifiée.

Certifications Lead Auditor vs. Lead Implementer

Les équipes SaaS demandent souvent quelles certifications professionnelles sont pertinentes pour l’audit ISO 27001. Comprendre la distinction vous aide à recruter les bonnes personnes et à investir dans la bonne formation.

ISO 27001 Lead Auditor

Ce qu’elle couvre : Principes d’audit, gestion de programme d’audit, planification et exécution d’audit, collecte de preuves, classification des constatations, rapport d’audit et suivi des actions correctives. Basée sur l’ISO 19011 (audit des systèmes de management) et l’ISO 27001.

Qui devrait l’obtenir : Toute personne qui dirigera ou gérera des audits internes. Les consultants externes qui réalisent des audits internes pour votre compte.

Compétences clés : Compréhension de la méthodologie d’audit, objectivité et impartialité, compétences d’entretien, évaluation des preuves, audit basé sur les risques, rédaction de rapports.

Organismes de certification : IRCA (Registre international des auditeurs certifiés), PECB, BSI et d’autres proposent des formations Lead Auditor accréditées (généralement 5 jours).

ISO 27001 Lead Implementer

Ce qu’elle couvre : Conception de l’ISMS, méthodologie d’évaluation des risques, mise en oeuvre des contrôles, élaboration de politiques, gestion de projet pour la mise en oeuvre de l’ISMS et préparation à la certification.

Qui devrait l’obtenir : La personne responsable de la construction et du maintien de l’ISMS. Les responsables conformité, responsables sécurité ou le chef de projet pour la mise en oeuvre de l’ISO 27001.

Compétences clés : Compréhension de toutes les clauses de l’ISO 27001 et des contrôles de l’Annex A, méthodologie de gestion des risques, élaboration de politiques et procédures, gestion de projet, gestion du changement.

Distinction importante : Un Lead Implementer ne devrait pas auditer l’ISMS qu’il a mis en oeuvre — cela viole l’exigence d’indépendance. Cependant, les connaissances du Lead Implementer sont précieuses pour la planification d’audit et pour s’assurer que l’équipe d’audit comprend le contexte de l’ISMS.

ISO 27001 Auditeur interne

Ce qu’elle couvre : Un sous-ensemble du contenu Lead Auditor axé spécifiquement sur les exigences d’audit interne. Couvre la planification d’audit, les bases de l’exécution, la collecte de preuves et le reporting, mais avec moins de profondeur sur la gestion du programme d’audit et les spécificités de l’audit de certification.

Qui devrait l’obtenir : Les membres de l’équipe qui participeront aux audits internes en tant que co-auditeurs ou qui auditeront des domaines spécifiques de l’ISMS dans leur domaine de compétence.

Durée : Généralement 2 jours, contre 5 jours pour le Lead Auditor.

Recommandation SaaS : Si le budget est limité, formez une personne en Lead Auditor et 2 à 3 autres en auditeurs internes. Le Lead Auditor gère le programme et dirige les audits. Les auditeurs internes soutiennent en auditant les domaines hors de leur propre responsabilité.

Erreurs courantes d’audit interne

Erreur 1 : Traiter l’audit comme un exercice de cases à cocher

Le problème : L’auditeur parcourt une liste de contrôle, confirme que les politiques existent et marque tout comme conforme sans tester si les politiques sont réellement suivies ou efficaces.

La conséquence : Les vrais problèmes passent inaperçus. L’auditeur de certification les découvre à la place, pouvant entraîner des non-conformités qui auraient pu être évitées.

La solution : Pour chaque politique ou contrôle, testez la mise en oeuvre et l’efficacité. Ne vous contentez pas de confirmer que la politique existe — vérifiez qu’elle est suivie. Ne vous contentez pas de vérifier qu’elle est suivie — évaluez si elle atteint son objectif visé. Demandez « montrez-moi » au lieu de « dites-moi ».

Erreur 2 : Preuves insuffisantes

Le problème : Les constatations sont documentées comme des observations générales sans références de preuves spécifiques. « Le contrôle d’accès pourrait être amélioré » n’est pas une constatation — c’est une opinion.

La conséquence : Les actions correctives manquent de focus. La direction ne peut pas évaluer la gravité du problème. Les auditeurs de certification ne peuvent pas vérifier que l’audit interne était rigoureux.

La solution : Chaque constatation doit référencer des preuves spécifiques — noms de documents, dates de registres, configurations système, déclarations d’entretiens. Une constatation efficace est factuelle, spécifique et vérifiable.

Erreur 3 : Auditer la conformité uniquement, pas l’efficacité

Le problème : L’audit vérifie que les processus sont conformes aux exigences documentées mais n’évalue pas si ces processus atteignent réellement leurs objectifs de sécurité.

La conséquence : Une organisation peut être pleinement conforme à un ensemble de politiques qui sont inadéquates. Si le processus de revue d’accès existe et est suivi mais ne détecte pas réellement les accès excessifs, le processus est conforme mais pas efficace.

La solution : Incluez des questions d’efficacité dans votre liste de contrôle d’audit. « Le processus est-il suivi ? » ET « Le processus atteint-il son objectif visé ? » Si les revues d’accès sont réalisées trimestriellement mais ne trouvent jamais rien, soit les revues ne sont pas assez approfondies, soit le processus de provisionnement est exceptionnellement bon. Investiguez pour déterminer lequel.

Erreur 4 : Manque d’indépendance de l’auditeur

Le problème : La personne qui a construit l’ISMS audite l’ISMS. Le responsable sécurité qui a rédigé la politique de contrôle d’accès audite la conformité du contrôle d’accès.

La conséquence : Biais inconscient (ou conscient). L’auditeur est moins susceptible d’identifier les faiblesses de son propre travail. Les auditeurs de certification questionneront la validité de l’audit interne.

La solution : Appliquez une indépendance stricte pour chaque domaine d’audit. Utilisez l’audit croisé entre équipes ou faites appel à des ressources externes pour les domaines où l’indépendance interne n’est pas réalisable.

Erreur 5 : Ne pas assurer le suivi des actions correctives

Le problème : Les constatations sont identifiées et les actions correctives sont définies, mais personne ne les suit jusqu’à leur achèvement. Les mêmes constatations apparaissent d’un audit à l’autre.

La conséquence : L’ISMS ne s’améliore pas. Les constatations récurrentes signalent aux auditeurs de certification que le processus d’action corrective (Clause 10.1) n’est pas efficace.

La solution : Assignez une responsabilité claire pour chaque action corrective. Fixez des dates cibles. Suivez le statut dans un système centralisé. Incluez la revue des actions correctives comme point permanent de l’ordre du jour des réunions de direction. Réalisez des revues d’efficacité pour vérifier que les actions ont réellement résolu les problèmes.

Erreur 6 : Périmètre mal défini

Le problème : Le périmètre d’audit est trop large (tentative d’auditer tout superficiellement) ou trop étroit (domaines critiques de l’ISMS manqués).

La conséquence : Les audits trop larges produisent des constatations superficielles manquant de profondeur. Les audits trop étroits laissent des lacunes que les auditeurs de certification testeront.

La solution : Utilisez un périmètre basé sur les risques pour concentrer la profondeur d’audit là où cela compte le plus. Assurez-vous que le programme d’audit complet couvre tous les domaines de l’ISMS sur le cycle, même si les audits individuels sont ciblés.

Erreur 7 : Ne pas partager les résultats avec la direction

Le problème : Le rapport d’audit est classé et jamais discuté. La direction n’est pas informée des constatations, des tendances ou des besoins en ressources.

La conséquence : La Clause 9.2.2(d) n’est pas respectée. La direction ne peut pas remplir ses responsabilités de revue de direction selon la Clause 9.3. Les actions correctives manquent de soutien et de ressources de la direction.

La solution : Présentez les résultats d’audit à chaque revue de direction. Fournissez des briefings intermédiaires pour les constatations significatives. Formulez les constatations en termes de risque et d’impact business, pas seulement d’écarts de conformité.

Questions fréquemment posées

À quelle fréquence les audits internes doivent-ils être réalisés ?

L’ISO 27001 exige des audits « à des intervalles planifiés » — elle ne spécifie pas de fréquence minimale. Cependant, l’ensemble de l’ISMS doit être audité au moins une fois par cycle de certification (généralement annuellement pour les audits de surveillance, tous les trois ans pour la recertification). La plupart des organisations réalisent des audits internes annuellement. Certaines utilisent un programme glissant avec plusieurs audits plus petits tout au long de l’année.

Pouvons-nous utiliser le même cabinet pour l’audit interne et l’audit de certification ?

Non. Utiliser le même cabinet pour l’audit interne et la certification compromettrait l’indépendance de l’organisme de certification. Votre organisme de certification ne peut pas fournir de services de conseil ou d’audit interne pour l’ISMS qu’il certifie. Vous pouvez utiliser un autre cabinet externe pour les audits internes, ou réaliser les audits internes avec votre propre personnel.

Que se passe-t-il si l’audit interne trouve une non-conformité majeure juste avant l’audit de certification ?

C’est en fait un bon résultat — mieux vaut la trouver vous-même que de laisser l’auditeur de certification la découvrir. Traitez le problème immédiat (correction), élaborez un plan d’action corrective avec analyse des causes racines, et commencez la mise en oeuvre avant l’audit de certification. L’auditeur de certification verra que vous avez identifié le problème, pris des mesures et le gérez via votre processus d’action corrective. Cela démontre la maturité de l’ISMS. Cacher ou ignorer la constatation est bien pire.

Devons-nous auditer chaque contrôle de l’Annex A chaque année ?

Votre programme d’audit devrait couvrir tous les contrôles applicables de l’Annex A sur le cycle d’audit, mais vous n’avez pas besoin d’auditer chaque contrôle dans un seul audit. Un programme basé sur les risques alloue davantage de temps d’audit aux contrôles à risque plus élevé et peut auditer les contrôles à risque plus faible moins fréquemment (mais au moins une fois par cycle). Consultez notre guide des contrôles Annex A de l’ISO 27001 pour une liste complète.

Quel est le lien entre l’audit interne et le processus d’audit SOC 2 ?

Les audits internes et les audits SOC 2 ont des objectifs différents mais se chevauchent en pratique. L’audit interne ISO 27001 est une activité d’assurance interne qui évalue la conformité et l’efficacité de l’ISMS. L’audit SOC 2 est un engagement d’attestation externe par un cabinet d’expertise comptable. Si votre entreprise SaaS détient les deux certifications, coordonnez les deux activités d’audit pour partager les preuves, réduire les doublons et aligner le suivi des actions correctives.

Quels registres devons-nous conserver de l’audit interne ?

Conservez le programme d’audit (plan annuel), les plans d’audit individuels, les listes de contrôle et documents de travail d’audit, les preuves collectées, le rapport d’audit, les registres d’actions correctives (incluant l’analyse des causes racines, les plans d’action, les preuves de mise en oeuvre et les revues d’efficacité), et les procès-verbaux de revue de direction où les résultats d’audit ont été discutés. Conservez ces registres pendant au moins le cycle de certification actuel et le précédent (généralement 3 à 6 ans). Votre liste de contrôle de certification devrait inclure un rappel pour vérifier la conservation des registres d’audit.

Comment GRCTrail vous aide

GRCTrail simplifie la planification, l’exécution et le suivi des audits internes ISO 27001 pour les équipes SaaS :

• Gestion de programme d’audit avec des modèles d’audit pré-construits mappés sur chaque clause de l’ISO 27001 et chaque contrôle de l’Annex A, planification automatisée et priorisation basée sur les risques qui alloue l’effort d’audit là où il compte le plus
• Intégration de la collecte de preuves qui extrait les preuves d’audit directement de vos systèmes connectés (plateformes cloud, fournisseurs d’identité, dépôts de code), éliminant la collecte manuelle de captures d’écran et accélérant la collecte de preuves
• Suivi des actions correctives avec responsabilité assignée, dates cibles, rappels automatisés et flux de revue d’efficacité qui garantissent que les constatations sont résolues plutôt qu’oubliées

Démarrer avec GRCTrail

Guides associés

• Qu’est-ce que l’ISO 27001 ? Un guide pratique pour les entreprises SaaS
• Exigences ISO 27001 : Comprendre les Clauses 4 à 10
• Amélioration continue ISO 27001 : Construire un ISMS auto-améliorant
• Liste de contrôle de certification ISO 27001
• Déclaration d’Applicabilité ISO 27001 : Un guide complet
• Le processus d’audit SOC 2 : Calendrier, étapes et à quoi s’attendre