Éléments probants d’audit ISO 27001 pour NIS2 et DORA

Il est 08 h 17 un mardi, et le RSSI d’une société fintech SaaS en forte croissance a trois messages en attente.

Le premier vient d’un grand client bancaire : « Veuillez nous transmettre votre dernier rapport d’audit interne, les comptes rendus de revue de direction, l’état des actions correctives, la procédure de notification des incidents, le registre des fournisseurs et les éléments probants de supervision par le conseil d’administration. »

Le deuxième vient du directeur financier : « Sommes-nous dans le champ d’application de NIS2 ou de DORA, et quels éléments probants avons-nous déjà ? »

Le troisième vient du directeur général : « Pouvons-nous dire que nous sommes prêts pour l’audit ? »

Dans de nombreuses organisations, la réponse inconfortable n’est pas que rien n’est fait. C’est pire. Les activités de sécurité sont menées partout, mais les éléments probants ne sont centralisés nulle part. Il existe des contrôles, mais pas de piste d’audit. Il existe des tickets, mais pas de lien clair avec les risques. Il existe des points de suivi avec la direction, mais pas de livrables formels de revue de direction. Il existe des échanges avec les fournisseurs, mais pas de registre des fournisseurs défendable, pas de revue contractuelle et pas de stratégie de sortie.

C’est précisément dans cet écart que l’audit interne et la revue de direction ISO/IEC 27001:2022 dépassent le simple exercice de certification. Ils deviennent le rythme opérationnel de NIS2, de DORA, de GDPR, des programmes d’assurance demandés par les clients, de la cyberassurance et de la responsabilité du conseil d’administration.

Les équipes SaaS, cloud, MSP, MSSP et fintech échouent rarement parce qu’elles manquent d’activités de sécurité. Elles échouent parce que ces activités sont dispersées entre Slack, Jira, des feuilles de calcul, des portails fournisseurs, des tickets SOC, des dossiers achats et des présentations au conseil d’administration. Un régulateur, un auditeur externe ou un client grand compte n’attend pas une explication héroïque. Il attend des éléments probants objectifs.

La solution pratique n’est pas de lancer des programmes d’audit séparés pour chaque référentiel. Elle consiste à utiliser le SMSI ISO 27001 comme moteur central d’éléments probants, puis à baliser ces éléments pour NIS2, DORA, GDPR et les exigences contractuelles. Bien conduit, un cycle d’audit interne et de revue de direction peut répondre à de nombreuses questions de conformité.

De la fatigue liée aux référentiels à un modèle unifié d’éléments probants du SMSI

De nombreux RSSI rencontrent une variante du problème de Maria. Maria dirige la sécurité d’une entreprise SaaS B2B ayant des clients dans le secteur financier. Son équipe a passé avec succès un audit de certification ISO/IEC 27001:2022 il y a six mois. Le SMSI gagne en maturité, les politiques sont appliquées et les responsables de contrôle comprennent leurs responsabilités. Puis le directeur général lui transmet deux articles, l’un sur la directive NIS2 et l’autre sur DORA, avec une question brève : « Sommes-nous couverts ? »

La réponse dépend du domaine d’application, des services, des clients et des entités juridiques. Mais la réponse opérationnelle est claire : si Maria traite NIS2 et DORA comme des projets de conformité distincts, elle créera des travaux en double, des éléments probants incohérents et une fatigue d’audit croissante. Si elle les traite comme des exigences de parties intéressées dans le SMSI, elle peut utiliser ISO 27001 pour intégrer ces exigences, les tester et démontrer la préparation.

ISO/IEC 27001:2022 est conçue pour cela. La clause 4 exige que l’organisation comprenne son contexte et les exigences des parties intéressées, y compris les obligations légales, réglementaires, contractuelles et liées aux dépendances. La clause 5 exige le leadership et l’intégration dans les processus métier. La clause 6 exige l’appréciation des risques et le traitement des risques. La clause 9 exige l’évaluation des performances au moyen de la surveillance, de l’audit interne et de la revue de direction. La clause 10 exige l’amélioration et l’action corrective.

NIS2 et DORA s’intègrent naturellement dans cette structure.

NIS2 impose aux entités essentielles et importantes de mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées de gestion des risques de cybersécurité. Elle fait également peser sur les organes de direction la responsabilité d’approuver ces mesures, d’en superviser la mise en œuvre et de pouvoir être tenus responsables en cas de manquement. Ses mesures minimales couvrent l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, la gestion des vulnérabilités, l’évaluation de l’efficacité, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et, le cas échéant, l’authentification multifacteur ou l’authentification continue.

DORA s’applique à partir du 17 janvier 2025 et établit un régime sectoriel de résilience opérationnelle numérique pour les entités financières. Il exige la responsabilité de l’organe de direction en matière de gestion des risques liés aux TIC, un cadre documenté de gestion des risques liés aux TIC, une stratégie de résilience opérationnelle numérique, des plans de continuité TIC et de reprise, des tests de résilience, une gouvernance des incidents liés aux TIC et une gestion des risques liés aux prestataires TIC tiers. Pour les fournisseurs SaaS et cloud servant des entités financières, DORA peut apparaître au travers d’obligations contractuelles, d’audits clients et d’attentes relatives à la gestion des risques liés aux prestataires TIC tiers, même lorsque le fournisseur n’est pas lui-même une entité financière.

GDPR ajoute la couche de responsabilité. Lorsque des données à caractère personnel sont traitées dans le champ d’application de GDPR, les organisations doivent être en mesure de démontrer leur conformité aux principes de protection des données et aux mesures techniques et organisationnelles appropriées.

ISO 27001 n’est pas un certificat de conformité magique pour ces obligations. C’est le système de management qui permet de les organiser, de les étayer par des éléments probants et de les améliorer.

La question du domaine d’application : que démontrez-vous, et pour qui ?

Avant de constituer un dossier d’éléments probants prêt pour l’audit, la direction doit répondre à une question fondamentale : quelles obligations relèvent du domaine d’application ?

Pour les entreprises SaaS et cloud, le périmètre NIS2 peut être plus large qu’attendu. NIS2 s’applique aux entités publiques ou privées de secteurs listés qui atteignent certains seuils de taille, ainsi qu’à certaines entités à fort impact indépendamment de leur taille. Les secteurs pertinents peuvent inclure l’infrastructure numérique, les fournisseurs de services cloud, les fournisseurs de centres de données, les réseaux de diffusion de contenu, les prestataires de services de confiance, les fournisseurs publics de communications électroniques et les fournisseurs B2B de gestion de services TIC tels que les prestataires de services managés et les prestataires de services de sécurité managés. Les fournisseurs SaaS doivent examiner attentivement la manière dont les services sont fournis, les secteurs qu’ils soutiennent et la question de savoir s’ils permettent une administration à la demande et un large accès à distance à des ressources informatiques partagées, évolutives et mutualisées.

Pour les fintechs et les prestataires de services du secteur financier, DORA doit être analysé séparément. DORA couvre directement un large éventail d’entités financières, notamment les établissements de crédit, les établissements de paiement, les prestataires de services d’information sur les comptes, les établissements de monnaie électronique, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les plateformes de négociation, les gestionnaires de fonds, les entreprises d’assurance et de réassurance et les prestataires de services de financement participatif. Les prestataires de services TIC tiers font également partie de l’écosystème DORA, car les entités financières doivent gérer leurs dépendances TIC, tenir des registres des accords contractuels et inclure des dispositions contractuelles spécifiques pour les services TIC soutenant des fonctions critiques ou importantes.

NIS2 et DORA interagissent également. Lorsqu’un acte juridique sectoriel de l’UE impose des exigences équivalentes en matière de gestion des risques de cybersécurité ou de notification des incidents, les dispositions NIS2 correspondantes peuvent ne pas s’appliquer à ces entités pour ces domaines. DORA constitue le régime sectoriel de résilience opérationnelle pour les entités financières. Cela ne rend pas NIS2 sans objet pour tous les fournisseurs environnants. Cela signifie que le modèle d’éléments probants doit distinguer si l’organisation est une entité financière directement soumise à DORA, un prestataire de services TIC tiers soutenant des entités financières, un fournisseur SaaS dans le champ de NIS2 ou un groupe comportant plusieurs entités juridiques et lignes de services.

Cette analyse du domaine d’application doit figurer dans le contexte du SMSI et dans le registre des parties intéressées. Sans elle, le plan d’audit testera les mauvais éléments.

Une piste d’audit, de nombreuses questions de conformité

Une erreur fréquente consiste à créer des dossiers d’éléments probants séparés pour ISO 27001, NIS2, DORA, GDPR, la cyberassurance et les audits clients. Cette approche crée des doublons et des réponses contradictoires. Une meilleure approche consiste à disposer d’un modèle unique d’éléments probants avec plusieurs angles de lecture.

Au centre se trouve le SMSI. Autour de lui, cinq familles d’éléments probants.

Cette structure est alignée sur Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint. Dans la phase Audit, revue et amélioration, l’étape 25 porte sur le programme d’audit interne, l’étape 26 sur l’exécution de l’audit, l’étape 28 sur la revue de direction et l’étape 29 sur l’amélioration continue.

Les recommandations de l’étape 25 du Blueprint sont volontairement pratiques :

« Élaborez un calendrier indiquant quand les audits auront lieu et ce qu’ils couvriront. »

« Utilisez le modèle de plan d’audit interne s’il est fourni ; il peut s’agir d’un document simple ou d’une feuille de calcul listant les dates d’audit, le champ d’application et les auditeurs désignés. »

Extrait de Zenith Blueprint, phase Audit, revue et amélioration, étape 25 : Programme d’audit interne Zenith Blueprint

Ce plan d’audit simple devient puissant lorsqu’il est fondé sur les risques et balisé selon les obligations NIS2, DORA et GDPR.

Les contrôles ISO 27001 qui ancrent la préparation à l’audit

Pour la préparation à l’audit, trois contrôles ISO/IEC 27002:2022 sont particulièrement importants lorsqu’ils sont interprétés au moyen de Zenith Controls: The Cross-Compliance Guide Zenith Controls :

• 5.4 Responsabilités de la direction
• 5.35 Revue indépendante de la sécurité de l’information
• 5.36 Conformité aux politiques, règles et normes de sécurité de l’information

Il ne s’agit pas de « contrôles Zenith » distincts. Ce sont des contrôles ISO/IEC 27002:2022 que Zenith Controls aide à cartographier, auditer et interpréter entre différents référentiels.

Le contrôle 5.4 demande si les responsabilités de sécurité de l’information sont attribuées et comprises. Le contrôle 5.35 demande si la sécurité de l’information fait l’objet d’une revue indépendante. Le contrôle 5.36 demande si l’organisation respecte ses politiques, règles et normes.

Zenith Controls classe le contrôle 5.35 selon une approche orientée assurance :

Le contrôle ISO/IEC 27002:2022 5.35, « Revue indépendante de la sécurité de l’information », est traité dans Zenith Controls comme « préventif, correctif », soutenant la confidentialité, l’intégrité et la disponibilité au travers des concepts de cybersécurité « identifier » et « protéger », avec une capacité opérationnelle en « assurance de la sécurité de l’information ». Zenith Controls

C’est important, car l’audit interne est à la fois préventif et correctif. Il prévient les angles morts en testant le SMSI avant tout examen externe, et il corrige les faiblesses au moyen d’actions documentées.

La correspondance plus large part des exigences NIS2 et DORA, puis identifie les éléments probants ISO 27001 permettant de les démontrer.

La cartographie des contrôles n’est utile que si les éléments probants sont solides. Si l’enregistrement est faible, aucune matrice de correspondance ne le sauvera. Si l’enregistrement est complet, les mêmes éléments probants peuvent répondre aux questions de type ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 et COBIT 2019.

Les éléments probants de politique que Clarysec attend des organisations

Les politiques Clarysec transforment la théorie du SMSI en attentes concrètes en matière d’éléments probants.

Pour les PME, Politique PME d’audit et de surveillance de la conformité Politique PME d’audit et de surveillance de la conformité exige l’approbation de la direction et une discipline d’audit :

« Le Directeur général (DG) doit approuver un plan d’audit annuel. »

Extrait de Politique PME d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.1.1 Politique PME d’audit et de surveillance de la conformité

Elle fixe également une cadence minimale :

« Les audits internes ou les revues de conformité doivent être réalisés au moins une fois par an. »

Extrait de Politique PME d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.2.1

Elle relie aussi les constats à la correction et à la revue de direction :

« Le DG doit approuver un plan d’actions correctives et suivre sa mise en œuvre. »

Extrait de Politique PME d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.4.2

« Les constats d’audit et les mises à jour de statut doivent être inclus dans le processus de revue de direction du SMSI. »

Extrait de Politique PME d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.4.3

La conservation des éléments probants est également explicite :

« Les éléments probants doivent être conservés pendant au moins deux ans, ou plus longtemps lorsque la certification ou les accords clients l’exigent. »

Extrait de Politique PME d’audit et de surveillance de la conformité, Exigences de mise en œuvre de la politique, clause 6.2.4

Pour les organisations plus importantes, Politique d’audit et de surveillance de la conformité Politique d’audit et de surveillance de la conformité, également référencée dans certains supports Clarysec comme la P33 Politique d’audit et de surveillance de la conformité, élargit la structure :

« Un plan d’audit fondé sur les risques doit être élaboré et approuvé annuellement, en tenant compte de : »

Extrait de Politique d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.2 Politique d’audit et de surveillance de la conformité

« L’organisation doit tenir un registre des audits contenant : »

Extrait de Politique d’audit et de surveillance de la conformité, Exigences de gouvernance, clause 5.4

« Les audits internes doivent suivre une procédure documentée comprenant : »

Extrait de Politique d’audit et de surveillance de la conformité, Exigences de mise en œuvre de la politique, clause 6.1.1

« Tous les constats doivent donner lieu à une CAPA documentée comprenant : »

Extrait de Politique d’audit et de surveillance de la conformité, Exigences de mise en œuvre de la politique, clause 6.2.1

La revue de direction est ancrée dans la Politique de sécurité de l’information Politique de sécurité de l’information, également référencée dans certains supports Clarysec comme P01 Politique de sécurité de l’information :

« Les activités de revue de direction (conformément à la clause 9.3 d’ISO/IEC 27001) doivent être menées au moins une fois par an et doivent inclure : »

Extrait de Politique de sécurité de l’information, Exigences de gouvernance, clause 5.3 Politique de sécurité de l’information

Ces exigences créent la chaîne d’éléments probants attendue par les auditeurs : plan approuvé, procédure définie, registre des audits, constats, CAPA, conservation et revue par la direction.

Constituer le dossier d’éléments probants prêt pour l’audit

Un dossier d’éléments probants prêt pour l’audit n’est pas un dossier volumineux créé deux jours avant l’audit. C’est une structure vivante, maintenue tout au long de l’année.

Le dossier d’éléments probants doit être cartographié avec les clauses ISO/IEC 27001:2022 et les contrôles de l’annexe A, mais également balisé selon sa pertinence réglementaire. Par exemple, un enregistrement d’audit fournisseur peut soutenir les contrôles fournisseurs de l’annexe A, la sécurité de la chaîne d’approvisionnement NIS2 et la gestion des risques liés aux prestataires TIC tiers DORA. Un enregistrement d’exercice sur table relatif à un incident peut soutenir la gestion des incidents ISO 27001, la préparation à la notification échelonnée NIS2 et la gouvernance DORA des incidents majeurs liés aux TIC.

Comment réaliser l’audit interne intégré

L’étape 26 de Zenith Blueprint met l’accent sur les éléments probants objectifs :

« Réalisez l’audit en collectant des éléments probants objectifs pour chaque élément de votre liste de contrôle. »

« Interrogez le personnel concerné. »

« Examinez la documentation. »

« Observez les pratiques. »

« Échantillonnez et effectuez des contrôles ponctuels. »

Extrait de Zenith Blueprint, phase Audit, revue et amélioration, étape 26 : Exécution de l’audit Zenith Blueprint

C’est exactement ce qu’exige la préparation à NIS2 et DORA. Les régulateurs et les clients n’accepteront pas « nous pensons que cela fonctionne ». Ils demanderont comment vous le savez.

Un audit bien conduit teste quatre dimensions des éléments probants.

Prenons l’exemple d’un événement de rançongiciel simulé sur un serveur de préproduction. L’auditeur vérifie si le processus de réponse aux incidents peut satisfaire les exigences ISO 27001, les attentes NIS2 de notification échelonnée et les obligations client DORA.

NIS2 prévoit une structure de notification échelonnée pour les incidents significatifs, incluant une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures et un rapport final dans le mois suivant la notification d’incident. DORA dispose de son propre cadre de classification et de notification des incidents liés aux TIC pour les entités financières. L’audit interne doit vérifier que les procédures opérationnelles de réponse capturent l’heure de prise de connaissance, les critères de gravité, les services affectés, les indicateurs de compromission, les actions d’atténuation, la cause racine, les obligations de notification client et les données du rapport final.

Transformer un constat d’audit en éléments probants NIS2 et DORA

Un constat fournisseur réaliste montre comment les éléments probants doivent circuler.

Lors de l’audit interne, l’auditeur échantillonne cinq fournisseurs critiques. Un fournisseur cloud de journalisation soutient la surveillance de la fraude et les alertes de sécurité de la plateforme fintech. Le fournisseur est listé dans l’inventaire, mais il n’existe pas de plan de sortie documenté, pas d’élément probant de revue annuelle de sécurité et aucune confirmation que le contrat inclut une assistance en cas d’incident ou des droits d’audit.

L’auditeur enregistre une non-conformité relative aux exigences de sécurité fournisseur et de sortie cloud. Une réponse faible serait : « revue fournisseur manquante ». Une réponse solide crée une chaîne d’éléments probants de conformité croisée :

1. Enregistrer le constat dans le rapport d’audit, avec la taille de l’échantillon, le nom du fournisseur, la référence contractuelle et les éléments probants manquants.
2. Ajouter une entrée CAPA avec la cause racine, par exemple : « la liste de contrôle d’intégration des fournisseurs n’incluait pas la classification de criticité ni le déclencheur de plan de sortie ».
3. Désigner le responsable fournisseur et le propriétaire du risque.
4. Mettre à jour le registre des fournisseurs afin d’indiquer que le service soutient une fonction critique ou importante.
5. Réaliser une appréciation des risques couvrant l’interruption de service, l’accès aux données, le risque de concentration, la dépendance de notification des incidents et les lacunes contractuelles.
6. Mettre à jour le plan de traitement des risques et la Déclaration d’applicabilité lorsque cela est pertinent.
7. Obtenir un avenant contractuel mis à jour ou une acceptation du risque documentée.
8. Créer ou tester un plan de sortie.
9. Réauditer les éléments probants fournisseur après remédiation.
10. Présenter le constat, le risque et les besoins en ressources en revue de direction.

Cette chaîne unique soutient plusieurs obligations. NIS2 attend la sécurité de la chaîne d’approvisionnement et la prise en compte des vulnérabilités des fournisseurs, de leurs pratiques de cybersécurité et de leurs procédures de développement sécurisé. DORA exige des entités financières qu’elles gèrent les risques liés aux prestataires TIC tiers, tiennent des registres des accords contractuels, évaluent les prestataires avant contractualisation, incluent des droits d’audit et d’inspection le cas échéant, maintiennent des droits de résiliation et documentent des stratégies de sortie pour les services TIC soutenant des fonctions critiques ou importantes. GDPR peut également être pertinent si le fournisseur traite des données à caractère personnel.

L’enregistrement d’audit n’est alors plus seulement un élément probant de conformité. C’est un élément probant de résilience.

Revue de direction : là où les éléments probants deviennent responsabilité

L’audit interne établit les faits. La revue de direction décide des suites à donner.

L’étape 28 de Zenith Blueprint décrit le dossier d’entrée de revue de direction :

« ISO 27001 précise plusieurs éléments d’entrée requis pour la revue de direction. Préparez un bref rapport ou une présentation couvrant ces points. »

Le Blueprint liste l’état des actions précédentes, les changements dans les enjeux externes et internes, la performance et l’efficacité du SMSI, les incidents ou non-conformités, les opportunités d’amélioration et les besoins en ressources.

Extrait de Zenith Blueprint, phase Audit, revue et amélioration, étape 28 : Revue de direction Zenith Blueprint

Pour NIS2 et DORA, la revue de direction est le moment où la responsabilité au niveau du conseil d’administration devient visible. La revue ne doit pas seulement indiquer que « la sécurité a été discutée ». Elle doit montrer que la direction a examiné :

• Les évolutions des exigences NIS2, DORA, GDPR, clients et contractuelles.
• Les changements de domaine d’application, y compris nouveaux pays, produits, clients réglementés ou dépendances TIC.
• Les résultats d’audit interne, y compris les non-conformités majeures et mineures.
• L’état des CAPA et des actions en retard.
• Les objectifs et indicateurs de sécurité.
• Les tendances des incidents, quasi-incidents et retours d’expérience.
• Les risques de concentration liés aux fournisseurs et au cloud.
• Les résultats des tests de continuité d’activité et de sauvegarde.
• La performance en matière de vulnérabilités et d’application des correctifs.
• Les besoins en ressources, y compris les personnes, les outils, la formation et le budget.
• Les risques résiduels nécessitant une acceptation formelle.
• Les décisions d’amélioration et les responsables désignés.

C’est là que Maria peut transformer un rapport technique en assurance stratégique. Au lieu de dire « nous avons trouvé une lacune dans le processus d’incident », elle peut dire : « L’audit a identifié une non-conformité mineure dans nos critères de décision de notification des incidents NIS2. La CAPA met à jour la procédure, ajoute une matrice de décision et impose un exercice sur table dans les 30 jours. Nous avons besoin de l’approbation de la direction pour la revue juridique et le temps de formation. »

C’est le type d’enregistrement qui soutient la gouvernance, la supervision et une prise de décision défendable.

Action corrective : la différence entre un constat et la maturité

Un audit interne sans action corrective n’est qu’un diagnostic.

L’étape 29 de Zenith Blueprint demande aux organisations d’utiliser un registre CAPA :

« Alimentez-le avec chaque problème : description du problème, cause racine, action corrective, responsable, date cible d’achèvement, statut. »

Extrait de Zenith Blueprint, phase Audit, revue et amélioration, étape 29 : Amélioration continue Zenith Blueprint

Elle établit également une distinction importante :

« En termes d’audit : la correction corrige le symptôme, l’action corrective corrige la cause. Les deux sont importantes. »

Extrait de Zenith Blueprint, phase Audit, revue et amélioration, étape 29 : Amélioration continue

Si les éléments probants de restauration de sauvegarde sont manquants, la correction peut consister à exécuter et documenter un test de restauration cette semaine. L’action corrective consiste à modifier la procédure de sauvegarde afin que les tests de restauration soient planifiés trimestriellement, automatiquement ticketés, revus par le responsable de service et inclus dans les indicateurs de revue de direction.

Les auditeurs recherchent cette maturité. Un auditeur ISO 27001 teste la conformité au SMSI et aux contrôles sélectionnés. Un évaluateur NIS2 demande si les mesures de gestion des risques sont efficaces et supervisées. Un évaluateur DORA recherche l’intégration du cadre de gestion des risques TIC, les tests de résilience, la gestion des dépendances vis-à-vis de tiers et la remédiation. Un évaluateur NIST Cybersecurity Framework 2.0 peut demander si les résultats de gouvernance, d’identification, de protection, de détection, de réponse et de rétablissement fonctionnent. Un auditeur COBIT 2019 peut se concentrer sur les objectifs de gouvernance, la propriété, les indicateurs de performance et l’assurance.

Le même enregistrement CAPA peut satisfaire ces angles de lecture s’il inclut la cause racine, le responsable, l’impact sur le risque, l’action corrective, l’échéance, les éléments probants de mise en œuvre, la revue d’efficacité et la visibilité par la direction.

Les multiples angles de lecture de l’auditeur

Des auditeurs différents lisent les mêmes éléments probants différemment. Zenith Controls aide à anticiper ces questions en agissant comme guide de conformité croisée pour les contrôles ISO/IEC 27002:2022 et les référentiels associés.

Le contrôle 5.36 est un bon exemple. L’auditeur ISO 27001 peut se concentrer sur l’existence de revues de conformité et leur alimentation des actions correctives. L’évaluateur NIS2 peut demander si ces revues testent les mesures légales de cybersécurité, et pas seulement les règles internes. L’évaluateur DORA peut se concentrer sur l’inclusion des prestataires TIC critiques et de l’application contractuelle dans les revues de conformité.

C’est pourquoi les éléments probants doivent être conçus dès le départ pour plusieurs lecteurs.

Un sprint pratique de préparation à l’audit en 30 jours

Si le directeur général demande si l’organisation peut être prête pour l’audit en 30 jours, la réponse honnête est la suivante : vous pouvez constituer un socle crédible d’éléments probants si la direction soutient le sprint et si le domaine d’application est réaliste.

Ce sprint ne remplace pas la maturité à long terme. Il crée un socle opérationnel défendable. La vraie valeur apparaît lorsque l’organisation répète le cycle chaque trimestre ou semestre, et pas seulement une fois par an.

Défaillances courantes des éléments probants observées par Clarysec

Les mêmes faiblesses apparaissent dans les audits SaaS, cloud et fintech :

• Le plan d’audit existe, mais il n’est pas fondé sur les risques.
• La liste de contrôle d’audit teste les clauses ISO, mais ignore NIS2, DORA, GDPR et les obligations clients.
• Les comptes rendus de revue de direction existent, mais ils ne montrent ni décisions, ni allocation de ressources, ni acceptation du risque.
• Les enregistrements CAPA listent des actions, mais aucune cause racine.
• Les constats sont clôturés sans vérification d’efficacité.
• Des revues fournisseurs sont réalisées, mais les fournisseurs critiques ne sont pas distingués des fournisseurs à faible risque.
• Les procédures opérationnelles de réponse aux incidents existent, mais personne ne peut prouver que le flux de notification dans les 24 heures ou 72 heures fonctionnerait.
• Les tâches de sauvegarde sont au vert, mais les tests de restauration ne sont pas étayés par des éléments probants.
• Les revues d’accès sont exportées, mais les exceptions ne sont pas suivies jusqu’à leur clôture.
• Les journaux sont collectés, mais personne ne peut démontrer la surveillance, l’escalade ou la réponse.
• Les éléments probants sont stockés dans des dossiers personnels au lieu d’un référentiel maîtrisé.
• Les exigences de conservation sont floues ou incohérentes avec les contrats clients.

Ces défaillances peuvent être corrigées. Elles exigent une architecture structurée des éléments probants du SMSI, et non une chasse aux documents de dernière minute.

À quoi ressemble une bonne réponse pour le conseil d’administration

Lorsque le RSSI revient vers le directeur général et le directeur financier, la réponse la plus solide n’est pas « nous avons passé une liste de contrôle d’audit ». C’est :

« Nous avons un plan d’audit approuvé. Nous avons réalisé un audit interne fondé sur les risques. Nous avons identifié des constats avec des éléments probants objectifs. Nous avons approuvé des CAPA avec responsables et échéances. Nous avons escaladé les risques significatifs, les incidents, les dépendances fournisseurs et les besoins en ressources en revue de direction. Nous avons cartographié les éléments probants avec ISO/IEC 27001:2022, NIS2, DORA et GDPR. Nous pouvons produire la piste d’audit. »

Cette réponse change la conversation. Elle donne au directeur général de la confiance face aux clients. Elle donne au directeur financier de la clarté sur l’exposition réglementaire. Elle donne au conseil d’administration un enregistrement de supervision défendable. Elle donne au RSSI une feuille de route priorisée plutôt qu’une pile de demandes déconnectées.

Surtout, elle fait passer l’organisation d’un théâtre de la conformité à la résilience opérationnelle.

Prochaines étapes avec Clarysec

Votre prochain audit ne doit pas être une course dans l’urgence. Il doit constituer une preuve visible que votre SMSI fonctionne, que la direction est impliquée et que l’organisation est prête pour ISO 27001, NIS2, DORA, GDPR et les programmes d’assurance demandés par les clients.

Clarysec peut vous aider à :

• Construire un plan d’audit interne fondé sur les risques avec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint.
• Cartographier les éléments probants d’audit au moyen de Zenith Controls: The Cross-Compliance Guide Zenith Controls.
• Mettre en œuvre une gouvernance d’audit pour PME ou entreprise avec Politique PME d’audit et de surveillance de la conformité Politique PME d’audit et de surveillance de la conformité ou Politique d’audit et de surveillance de la conformité Politique d’audit et de surveillance de la conformité.
• Préparer des dossiers de revue de direction alignés sur la Politique de sécurité de l’information Politique de sécurité de l’information et les attentes de la clause 9.3 d’ISO/IEC 27001:2022.
• Transformer les constats en enregistrements CAPA, décisions de direction et amélioration mesurable.

Téléchargez les kits d’outils Clarysec, réservez une évaluation de préparation ou demandez une démonstration pour transformer votre prochain audit interne en éléments probants prêts pour le conseil d’administration, pour ISO 27001, NIS2, DORA et au-delà.