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

Maria, RSSI d’une société d’analyse financière en forte croissance, disposait de six semaines avant la convergence de trois échéances. Son audit de surveillance ISO 27001:2022 était déjà planifié. NIS2 plaçait l’entreprise, en tant qu’entité importante, sous un niveau accru de responsabilité de la direction. DORA allait vérifier si ses opérations fintech pouvaient démontrer leur résilience opérationnelle numérique. Dans le même temps, un grand client entreprise suspendait la signature d’un contrat tant que son équipe n’avait pas réussi une revue approfondie d’assurance sécurité.

L’entreprise n’était pas dépourvue de sécurité. Elle exécutait des charges de travail de production dans AWS et Azure, utilisait Microsoft 365 et plusieurs plateformes SaaS critiques, imposait le MFA, sauvegardait les données, réalisait des analyses de vulnérabilités et collectait les journaux cloud. Le problème était la preuve.

Les éléments probants étaient dispersés entre captures d’écran Slack, pages wiki de développeurs, exports de consoles cloud, dossiers achats, contrats juridiques et assurances verbales des propriétaires de plateformes. Lorsqu’un auditeur demandait : « Montrez-moi comment vous maîtrisez votre environnement cloud », un lien vers la page de conformité d’un fournisseur cloud ne suffisait pas. Les certificats du fournisseur prouvaient les contrôles du fournisseur. Ils ne prouvaient pas la part de Maria dans le modèle de responsabilité partagée.

C’est là que de nombreux programmes d’éléments probants d’audit de sécurité cloud échouent. Non parce que les contrôles sont absents, mais parce que l’organisation ne peut pas démontrer, de manière structurée et traçable, quelles responsabilités incombent au fournisseur, lesquelles incombent au client, comment les contrôles SaaS et IaaS sont configurés, comment les engagements fournisseurs sont appliqués et comment les éléments probants sont conservés pour les auditeurs, les autorités compétentes et les clients.

La conformité cloud n’est plus une annexe technique. Pour un fournisseur SaaS soumis à NIS2, une entité financière soumise à DORA ou toute organisation ISO 27001:2022 utilisant IaaS, PaaS et SaaS, la gouvernance cloud fait partie du domaine d’application du SMSI, du plan de traitement des risques, du cycle de vie des fournisseurs, du processus de gestion des incidents, de la responsabilité en matière de protection de la vie privée et de la revue de direction.

L’objectif opérationnel est simple : construire une architecture unique d’éléments probants cloud, prête pour les autorités compétentes, capable de répondre aux questions ISO 27001:2022, NIS2, DORA, GDPR, d’assurance client et d’audit interne sans reconstruire la preuve pour chaque référentiel.

Le cloud reste dans le périmètre, même lorsque l’infrastructure est externalisée

Le premier piège d’audit consiste à considérer que l’infrastructure externalisée est hors du SMSI. Ce n’est pas le cas. L’externalisation modifie la frontière de contrôle ; elle ne supprime pas la responsabilité.

ISO/IEC 27001:2022 exige que l’organisation définisse son contexte, ses parties intéressées, le domaine d’application du SMSI, ses interfaces, ses dépendances et ses processus. Dans une entreprise dont les services reposent prioritairement sur le cloud, le fournisseur d’identité, le compte d’hébergement cloud, le CRM, la plateforme de messagerie, l’entrepôt de données, le pipeline CI/CD, l’outil de gestion des tickets et le service de sauvegarde constituent souvent une infrastructure métier essentielle.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint souligne ce point dans la phase ISMS Foundation & Leadership, étape 2, besoins des parties prenantes et domaine d’application du SMSI :

« Si vous externalisez votre infrastructure informatique auprès d’un fournisseur cloud, cela ne l’exclut pas du périmètre ; au contraire, vous incluez la gestion de cette relation et les actifs cloud dans le périmètre, car la sécurité de vos données dans le cloud relève de votre responsabilité. »

Cette affirmation constitue un point d’ancrage d’audit. Votre périmètre ne doit pas indiquer : « AWS est exclu parce qu’Amazon le gère. » Il doit préciser que les actifs informationnels et les processus liés aux services hébergés sur AWS sont dans le périmètre, y compris la gestion des contrôles de sécurité cloud, de l’identité, de la journalisation, du chiffrement, des sauvegardes, de l’assurance fournisseur et de la réponse aux incidents.

Pour ISO 27001:2022, cela soutient les clauses 4.1 à 4.4 relatives au contexte, aux parties intéressées, au périmètre et aux processus du SMSI. Pour NIS2, cela soutient les attentes de l’Article 21 en matière d’analyse des risques, de gestion des incidents, de continuité d’activité, de sécurité de la chaîne d’approvisionnement, d’acquisition et de maintenance sécurisées, de contrôle d’accès, de gestion des actifs, de cryptographie, d’efficacité des contrôles et de MFA le cas échéant. Pour DORA, cela soutient le principe selon lequel les entités financières restent responsables du risque lié aux TIC même lorsque les services TIC sont externalisés.

La question n’est pas de savoir si votre fournisseur cloud est sécurisé. La question est de savoir si vous gouvernez votre utilisation du fournisseur, configurez correctement votre environnement, surveillez le service, gérez les engagements fournisseurs et conservez les éléments probants.

La responsabilité partagée doit devenir une preuve partagée

Les fournisseurs cloud expliquent la responsabilité partagée. Les auditeurs vérifient si vous l’avez opérationnalisée.

En IaaS, le fournisseur sécurise généralement les installations physiques, l’infrastructure de base et l’hyperviseur. Le client maîtrise l’identité, la configuration des charges de travail, le durcissement des systèmes d’exploitation, la sécurité des applications, la classification des données, les paramètres de chiffrement, les règles réseau, la journalisation, les sauvegardes, l’application des correctifs et la réponse aux incidents.

En SaaS, le fournisseur contrôle l’essentiel des opérations de plateforme, mais le client conserve la maîtrise de la configuration du tenant, des utilisateurs, des rôles d’administration, des intégrations, du partage de données, de la conservation, des options de journalisation et des procédures d’escalade.

Le Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls traite la mesure 5.23 d’ISO/IEC 27002:2022, sécurité de l’information pour l’utilisation des services cloud, comme un contrôle central de gouvernance cloud à finalité préventive sur la confidentialité, l’intégrité et la disponibilité. Il relie les services cloud aux relations fournisseurs, au transfert sécurisé de l’information, à l’inventaire des actifs, à la prévention des fuites de données, à la sécurité des terminaux et du réseau, ainsi qu’aux pratiques de développement sécurisé.

Une interprétation clé de Zenith Controls indique :

« Les fournisseurs de services cloud (CSP) fonctionnent comme des fournisseurs critiques ; à ce titre, tous les contrôles relatifs à la sélection des fournisseurs, à la contractualisation et à la gestion des risques au titre de 5.19 s’appliquent. Toutefois, 5.23 va plus loin en traitant les risques propres au cloud, tels que la mutualisation, la transparence de la localisation des données et les modèles de responsabilité partagée. »

Cette distinction est essentielle. Les certificats fournisseurs seuls ne satisfont pas à l’annexe A.5.23. Vous devez disposer d’éléments probants côté client montrant que le service cloud est gouverné, configuré, surveillé et revu.

C’est la différence entre disposer de contrôles cloud et disposer de contrôles cloud exploitables en audit.

Commencez par un registre des services cloud exploitable par les auditeurs

Le moyen le plus rapide d’améliorer la préparation à l’audit cloud consiste à créer un registre complet des services cloud. Il ne doit pas être une simple liste achats ni un export financier. Il doit relier les services cloud aux données, aux propriétaires, aux régions, aux accès, aux contrats, à la criticité, à la pertinence réglementaire et aux éléments probants.

La Politique d’utilisation du cloud-sme de Clarysec Cloud Usage Policy-sme fournit un socle compact et compatible avec les exigences d’audit à la clause 5.3 :

« Un registre des services cloud doit être tenu par le prestataire informatique ou le DG. Il doit enregistrer : 5.3.1 Le nom et l’objet de chaque service cloud approuvé 5.3.2 La personne ou l’équipe responsable (propriétaire d’application) 5.3.3 Les types de données stockées ou traitées 5.3.4 Le pays ou la région où les données sont stockées 5.3.5 Les autorisations d’accès utilisateur et les comptes d’administration 5.3.6 Les informations contractuelles, les dates de renouvellement et les contacts support »

Pour les environnements d’entreprise, la Politique d’utilisation du cloud de Clarysec Cloud Usage Policy établit le mandat plus large :

« Cette politique établit les exigences obligatoires de l’organisation pour une utilisation sécurisée, conforme et responsable des services d’informatique en nuage dans les modèles de fourniture Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) et Software-as-a-Service (SaaS). »

La Politique d’utilisation du cloud exige un registre centralisé détenu par le RSSI et des configurations de référence approuvées pour les environnements cloud. Ce registre devient le socle probatoire de plusieurs obligations simultanément.

Pour ISO 27001:2022, il soutient l’inventaire des actifs, la gouvernance des usages du cloud, les relations fournisseurs, le contrôle d’accès, les exigences légales et contractuelles, le traitement des risques et les informations documentées. Pour NIS2, il soutient la sécurité de la chaîne d’approvisionnement, la gestion des actifs, l’analyse des risques, la gestion des incidents et la continuité. Pour DORA, il soutient la cartographie des actifs et dépendances TIC, les registres des prestataires tiers de services TIC, la cartographie des fonctions critiques ou importantes et l’analyse du risque de concentration. Pour GDPR, il identifie si des données à caractère personnel sont traitées, où elles sont localisées, quel fournisseur agit comme sous-traitant et quelles clauses de transfert ou de traitement de données s’appliquent.

Si le registre n’identifie pas les catégories de données et les régions, les éléments probants relatifs à la protection de la vie privée et à la résilience seront incomplets. S’il n’identifie pas les propriétaires d’applications, les revues des droits d’accès seront orphelines. S’il n’identifie pas les contrats et les dates de renouvellement, les clauses de sécurité fournisseur ne pourront pas être testées.

Faites d’ISO 27001:2022 la colonne vertébrale de la preuve cloud

ISO 27001:2022 constitue la meilleure colonne vertébrale des éléments probants cloud, car elle relie le contexte métier, les risques, les contrôles, les preuves opérationnelles, la surveillance et l’amélioration.

Les principales exigences ISO 27001:2022 pertinentes pour le cloud comprennent :

• Les clauses 4.1 à 4.4 relatives au contexte, aux parties intéressées, au domaine d’application du SMSI, aux interfaces, aux dépendances et aux processus.
• Les clauses 5.1 à 5.3 relatives au leadership, à la politique, aux rôles, aux responsabilités et à la redevabilité.
• Les clauses 6.1.1 à 6.1.3 relatives à l’appréciation des risques, au traitement des risques, à la comparaison avec l’annexe A, à la Déclaration d’applicabilité et à l’acceptation du risque résiduel.
• La clause 7.5 relative aux informations documentées maîtrisées.
• Les clauses 8.1 à 8.3 relatives à la planification opérationnelle, à l’exécution de l’appréciation des risques et à l’exécution du traitement des risques.
• Les clauses 9.1 à 9.3 relatives à la surveillance, à la mesure, à l’audit interne et à la revue de direction.
• La clause 10 relative à la non-conformité, à l’action corrective et à l’amélioration continue.

Les contrôles de l’annexe A qui portent le plus de poids probatoire cloud comprennent A.5.19 Sécurité de l’information dans les relations fournisseurs, A.5.20 Traitement de la sécurité de l’information dans les accords avec les fournisseurs, A.5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, A.5.22 Surveillance, revue et gestion des changements des services fournisseurs, A.5.23 Sécurité de l’information pour l’utilisation des services cloud, A.5.24 à A.5.27 gestion des incidents, A.5.29 Sécurité de l’information pendant une perturbation, A.5.30 Préparation des TIC à la continuité d’activité, A.5.31 Exigences légales, statutaires, réglementaires et contractuelles, A.5.34 Protection de la vie privée et des informations à caractère personnel, A.5.36 Conformité aux politiques, règles et normes de sécurité de l’information, A.8.8 Gestion des vulnérabilités techniques, A.8.9 Gestion des configurations, A.8.13 Sauvegarde des informations, A.8.15 Journalisation, A.8.16 Activités de surveillance, A.8.24 Utilisation de la cryptographie, A.8.25 Cycle de vie de développement sécurisé, A.8.29 Tests de sécurité en développement et en acceptation, et A.8.32 Gestion des changements.

Dans Zenith Blueprint, la phase Controls in Action, étape 23, explique les services cloud dans un langage parlant pour les auditeurs :

« Le passage aux services cloud introduit des changements profonds dans le modèle de confiance. Vous ne contrôlez plus le serveur, le périmètre réseau ni l’hyperviseur. Souvent, vous ne savez même pas où les données résident physiquement. Ce que vous contrôlez, et ce que ce contrôle impose, c’est la gouvernance de cette relation, la visibilité sur ce que vous utilisez et les exigences de sécurité que vous imposez à vos fournisseurs. »

Une entrée solide de Déclaration d’applicabilité pour A.5.23 ne doit pas se limiter à « Applicable, fournisseur cloud certifié ». Elle doit expliquer pourquoi le contrôle s’applique, quels risques il traite, comment il est mis en œuvre et où les éléments probants sont stockés.

Ajoutez une colonne d’emplacement des éléments probants dans la SoA ou l’outil de suivi des contrôles. Les auditeurs ne doivent pas avoir à rechercher la preuve dans les courriels, les systèmes de gestion des tickets et les lecteurs partagés.

Utilisez un modèle probatoire unique pour ISO 27001:2022, NIS2 et DORA

NIS2 et DORA exigent tous deux une cybersécurité documentée, fondée sur les risques et pilotée par la direction. Le chevauchement est important, mais la pression de supervision diffère.

NIS2 s’applique à de nombreuses entités essentielles et importantes dans l’UE, notamment les fournisseurs d’infrastructures numériques, les prestataires de services managés, les prestataires de services de sécurité managés, les établissements bancaires, les infrastructures de marchés financiers et les fournisseurs numériques. L’Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, incluant l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et la maintenance sécurisées, le traitement des vulnérabilités, l’évaluation de l’efficacité des contrôles, l’hygiène cyber, la formation, la cryptographie, le contrôle d’accès, la gestion des actifs et le MFA ou des communications sécurisées le cas échéant.

Pour les éléments probants d’audit de sécurité cloud, NIS2 demande si les risques cloud et fournisseurs sont gérés dans le cadre du risque de fourniture de service. Elle introduit également une notification structurée des incidents significatifs, avec une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures et un rapport final dans un délai d’un mois.

DORA s’applique depuis le 17 janvier 2025 à de nombreuses entités financières de l’UE et crée des exigences uniformes relatives à la gestion des risques liés aux TIC, à la notification des incidents majeurs liés aux TIC, aux tests de résilience opérationnelle numérique, au partage d’informations et au risque lié aux prestataires tiers de services TIC. Pour les entités financières également identifiées au titre de NIS2, DORA est traité comme l’acte juridique sectoriel spécifique de l’Union pour les obligations opérationnelles qui se chevauchent.

Pour le cloud, DORA est direct. Les entités financières demeurent responsables du risque lié aux TIC lorsque les services sont externalisés. Elles doivent disposer de stratégies relatives aux prestataires tiers de services TIC, de registres contractuels, d’évaluations précontractuelles, de diligence raisonnable, de droits d’audit et d’accès, de déclencheurs de résiliation, d’analyses du risque de concentration, de contrôles de sous-traitance et de stratégies de sortie testées.

Zenith Controls cartographie la mesure 5.23 d’ISO/IEC 27002:2022 vers NIS2 Article 21 de l’UE et DORA Articles 28 à 31. Il renvoie également à des normes de soutien telles qu’ISO/IEC 27017 pour les rôles de sécurité cloud et la surveillance, ISO/IEC 27018 pour la protection des informations à caractère personnel dans le cloud public, ISO/IEC 27701 pour la gestion de la vie privée dans les relations entre sous-traitants et responsables de traitement cloud, ISO/IEC 27036-4 pour la surveillance des services cloud et les accords fournisseurs, et ISO/IEC 27005 pour l’appréciation des risques cloud.

L’implication pratique est simple. Ne constituez pas des dossiers probatoires séparés pour ISO 27001:2022, NIS2, DORA et GDPR. Construisez une architecture unique d’éléments probants cloud avec des cartographies propres à chaque référentiel.

Les contrats fournisseurs sont des éléments probants de contrôle, pas des archives juridiques

Les éléments probants d’audit cloud se rompent souvent au niveau contractuel. La sécurité détient un questionnaire fournisseur. Le juridique détient le MSA. Les achats détiennent la date de renouvellement. Le DPO détient l’accord de traitement des données. Personne ne dispose d’une vue unique indiquant si l’accord contient les clauses de sécurité exigées par ISO 27001:2022, NIS2, DORA et GDPR.

La Third-Party and Supplier Security Policy-sme de Clarysec Third-Party and Supplier Security Policy-sme indique à la clause 5.3 :

« Les contrats doivent inclure des clauses obligatoires couvrant : 5.3.1 La confidentialité et la non-divulgation 5.3.2 Les obligations de sécurité de l’information 5.3.3 Les délais de notification des violations de données, par exemple sous 24 à 72 heures 5.3.4 Les droits d’audit ou la disponibilité d’éléments probants de conformité 5.3.5 Les restrictions à toute sous-traitance ultérieure sans approbation 5.3.6 Les conditions de résiliation, y compris le retour ou la destruction sécurisée des données »

Pour assurer la cohérence en audit, traduisez ces clauses en matrice de revue contractuelle. L’annexe A.5.20 d’ISO 27001:2022 attend que les exigences de sécurité soient convenues avec les fournisseurs. GDPR Article 28 exige des clauses de sous-traitance couvrant la confidentialité, les mesures de sécurité, l’assistance, les sous-traitants ultérieurs, la suppression ou la restitution des données et le soutien à l’audit. DORA Article 30 exige des dispositions contractuelles détaillées pour les prestataires tiers de services TIC, incluant les descriptions de services, la localisation des données, la sécurité, l’assistance en cas d’incident, la coopération avec les autorités, les droits d’audit, les droits d’accès, la résiliation et les modalités de transition. La sécurité de la chaîne d’approvisionnement NIS2 nécessite également une coopération fournisseur opposable.

Zenith Controls cartographie la mesure 5.20 d’ISO/IEC 27002:2022 vers les accords fournisseurs et signale les liens avec 5.19 relations fournisseurs, 5.14 transfert d’informations, 5.22 surveillance des fournisseurs, 5.11 restitution des actifs et 5.36 conformité.

Le point essentiel est l’opérationnalisation. Si un contrat cloud accorde l’accès aux rapports SOC 2, les auditeurs peuvent demander si vous avez obtenu le rapport, revu les exceptions, suivi la remédiation et réévalué le risque. Si le contrat prévoit une notification de violation, ils peuvent demander si votre procédure d’incident inclut le circuit de contact fournisseur et les points de décision réglementaires. Si les changements de sous-traitants exigent approbation ou notification, ils peuvent demander si les notifications de sous-traitants ultérieurs sont revues avant acceptation.

Un contrat sans éléments probants de revue est une archive. Un contrat relié au risque fournisseur, aux enregistrements de surveillance et aux flux de gestion des incidents est un contrôle.

La journalisation et la configuration SaaS sont des angles morts fréquents en audit

Les constats cloud proviennent souvent du SaaS, non de l’IaaS. Les équipes infrastructure disposent généralement de propriétaires techniques, de pipelines de journalisation, de configurations de référence et d’enregistrements de changements. Les plateformes SaaS sont fragmentées entre les ventes, les ressources humaines, la finance, le succès client, le marketing et les opérations. Chacune peut traiter des données sensibles ou réglementées.

La Politique de journalisation et de surveillance-sme de Clarysec Logging and Monitoring Policy-sme traite directement ce point à la clause 5.5 :

« 5.5 Services cloud et journalisation des tiers 5.5.1 Pour les plateformes dont la journalisation n’est pas sous le contrôle direct de l’informatique, par exemple la messagerie SaaS, les exigences suivantes s’appliquent : 5.5.1.1 La journalisation doit être activée et configurée lorsqu’elle est disponible 5.5.1.2 Les alertes doivent être routées vers le prestataire de support informatique 5.5.1.3 Les contrats doivent exiger des fournisseurs qu’ils conservent les journaux pendant au moins 12 mois et donnent accès à ceux-ci sur demande »

Pour les entreprises, la Politique d’utilisation du cloud ajoute :

« Les services cloud doivent être intégrés au SIEM de l’organisation pour une surveillance continue. »

Cette exigence fait passer le SaaS du statut d’« outil métier » à celui de « système d’information surveillé ». Les éléments probants doivent inclure les exports de paramètres de journalisation, la preuve du connecteur SIEM, les règles d’alerte, les tickets de triage, les paramètres de conservation et les revues d’accès administratifs.

Pour les SaaS critiques, préparez les éléments probants relatifs à la création de comptes administrateur, aux connexions suspectes, aux téléchargements massifs, au partage public, à la désactivation du MFA, à la création de jetons API, à l’activité d’invités externes et à l’élévation de privilèges. Pour l’IaaS, préparez CloudTrail ou une journalisation équivalente du plan de contrôle, les journaux d’accès au stockage, les changements IAM, les journaux de flux le cas échéant, les constats CSPM, les analyses de vulnérabilités, les éléments probants d’application des correctifs, les paramètres de chiffrement, le statut des sauvegardes, les revues des groupes de sécurité réseau et les tickets de changement.

La méthodologie d’audit de Zenith Controls pour la mesure 5.23 note qu’un audit de type ISO/IEC 27007 peut inspecter les autorisations de compartiments AWS S3, le chiffrement, les politiques IAM et la journalisation CloudTrail. Un auditeur orienté COBIT peut examiner les configurations d’alertes, les contrôles DLP, l’utilisation de Microsoft 365 Secure Score et les journaux de gestion des changements. Une approche NIST SP 800-53A peut tester la gestion des comptes et la surveillance, y compris si les charges de travail cloud sont corrigées, scannées et surveillées avec la même rigueur que les systèmes internes.

Les auditeurs parlent des dialectes différents. Vos éléments probants doivent rester les mêmes.

Constituez un dossier probatoire prêt pour les autorités compétentes pour un service SaaS et un service IaaS

Un flux de travail pratique commence par une plateforme SaaS critique et un environnement IaaS critique. Par exemple, Microsoft 365 pour la collaboration et AWS pour l’hébergement de production.

Étape 1 : mettre à jour le registre des services cloud

Pour Microsoft 365, enregistrez l’objet, le propriétaire, les types de données, la région, les comptes administrateur, le contrat, l’accord de traitement des données, le contact support, la date de renouvellement et la criticité. Pour AWS, enregistrez le compte de production, les régions, les catégories de données, les charges de travail, le propriétaire du compte, le statut du compte racine, le plan de support, les conditions contractuelles et les services métier liés.

Utilisez les champs de la Politique d’utilisation du cloud-sme comme jeu de données minimal. Ajoutez la criticité, la pertinence réglementaire et l’emplacement des éléments probants.

Étape 2 : documenter la responsabilité partagée

Pour Microsoft 365, les responsabilités client comprennent le cycle de vie des utilisateurs, le MFA, l’accès conditionnel, le partage invité, les étiquettes de conservation, la DLP lorsqu’elle est utilisée, la journalisation et l’escalade des incidents. Pour AWS, les responsabilités client comprennent IAM, les règles réseau, le durcissement des charges de travail, la configuration du chiffrement, la sauvegarde, la journalisation, l’application des correctifs et la sécurité des applications.

Joignez la documentation fournisseur relative à la responsabilité partagée, puis associez chaque responsabilité client à un responsable de contrôle et à une source d’éléments probants.

Étape 3 : capturer les éléments probants de configuration

Pour Microsoft 365, exportez ou capturez les politiques MFA et d’accès conditionnel, les rôles administrateur, les paramètres de partage externe, la journalisation d’audit, la configuration de conservation et les actions liées au score de sécurité. Pour AWS, exportez la politique de mot de passe IAM, le statut MFA des comptes à privilèges, la configuration CloudTrail, le blocage d’accès public S3, le statut du chiffrement, la revue des groupes de sécurité, les tâches de sauvegarde et le statut des analyses de vulnérabilités.

La Politique d’utilisation du cloud exige que les environnements cloud respectent une configuration de référence documentée et approuvée par l’architecte de sécurité cloud. Votre dossier probatoire doit inclure à la fois la configuration de référence et la preuve d’alignement.

Étape 4 : relier les éléments probants fournisseurs et vie privée

Joignez le contrat, l’accord de traitement des données, la liste des sous-traitants ultérieurs, les clauses de notification de violation, les rapports d’assurance d’audit et les éléments probants de localisation des données. Si des données à caractère personnel sont traitées, indiquez si le fournisseur agit comme sous-traitant, comment la suppression est traitée, comment l’assistance aux demandes des personnes concernées fonctionne et quelles garanties de transfert s’appliquent.

Pour DORA, identifiez si le service cloud soutient une fonction critique ou importante. Si oui, reliez les éléments probants au registre des prestataires tiers de services TIC, au dossier de diligence raisonnable, aux droits d’audit, au plan de sortie et à la revue du risque de concentration.

Étape 5 : connecter la journalisation à la réponse aux incidents

Montrez que les journaux sont activés, routés, revus et utilisés. Joignez les tableaux de bord SIEM, les règles d’alerte et au moins un ticket d’alerte clôturé. Cartographiez ensuite le flux de travail vers les points de décision de notification NIS2 et DORA.

Pour NIS2, le processus d’incident doit permettre l’alerte précoce sous 24 heures, la notification d’incident sous 72 heures et un rapport final sous un mois pour les incidents significatifs. Pour DORA, le processus d’incident lié aux TIC doit classifier les incidents selon les clients affectés, les transactions, la durée, l’indisponibilité, l’étendue géographique, l’impact sur les données, la criticité du service et l’impact économique.

Étape 6 : stocker les éléments probants avec rigueur

La clause 6.2 de la Politique d’audit et de surveillance de la conformité-sme de Clarysec Audit and Compliance Monitoring Policy-sme définit une discipline probatoire pratique :

« 6.2 Collecte des éléments de preuve et documentation 6.2.1 Tous les éléments de preuve doivent être stockés dans un dossier d’audit centralisé. 6.2.2 Les noms de fichiers doivent clairement faire référence au sujet d’audit et à la date. 6.2.3 Les métadonnées, par exemple qui les a collectées, quand et depuis quel système, doivent être documentées. 6.2.4 Les éléments de preuve doivent être conservés pendant au moins deux ans, ou plus longtemps lorsque la certification ou les accords clients l’exigent. »

La Politique d’audit et de surveillance de la conformité d’entreprise Audit and Compliance Monitoring Policy énonce l’objectif :

« Générer des éléments probants défendables et une piste d’audit à l’appui des demandes des autorités de régulation, des procédures judiciaires ou des demandes d’assurance client. »

Une capture d’écran nommée « screenshot1.png » constitue une preuve faible. Un fichier nommé « AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png » est plus solide, car il décrit le système, le contrôle, la date et le collecteur. Les métadonnées sont importantes parce que les auditeurs doivent pouvoir faire confiance à la date de collecte, à l’identité du collecteur et au système source.

Comment les auditeurs testent le même contrôle cloud

Les dossiers probatoires cloud les plus robustes sont conçus pour plusieurs angles d’audit. Les auditeurs ISO 27001:2022 vérifient si le contrôle figure dans le SMSI, l’appréciation des risques, le traitement des risques et la SoA. Les évaluateurs orientés NIST testent la mise en œuvre technique. Les auditeurs COBIT 2019 testent la gouvernance, la performance des fournisseurs et l’intégration des processus. Les auditeurs vie privée se concentrent sur les obligations des sous-traitants, la localisation des données, la préparation aux violations et les droits des personnes concernées. Les revues de supervision DORA se concentrent sur le risque lié aux prestataires tiers de services TIC et la résilience.

Zenith Controls inclut ces différences méthodologiques d’audit pour les services cloud, les accords fournisseurs et la surveillance des fournisseurs. Pour 5.22, Surveillance, revue et gestion des changements des services fournisseurs, il souligne que les auditeurs peuvent inspecter les comptes rendus trimestriels de revue fournisseur, les rapports KPI, les évaluations de rapports SOC, les journaux des modifications, les appréciations des risques, les incidents fournisseurs et le suivi des points ouverts. Pour 5.20, Traitement de la sécurité de l’information dans les accords fournisseurs, il souligne l’échantillonnage contractuel pour la confidentialité, les obligations de sécurité, la notification des violations, les droits d’audit, l’approbation des sous-traitants et les conditions de résiliation.

Les contrôles de conformité croisée qui portent la charge d’audit cloud

Un modèle d’éléments probants cloud prêt pour les autorités compétentes repose sur un petit nombre de contrôles à fort levier. Ces contrôles portent une grande partie de la charge de conformité sur ISO 27001:2022, NIS2, DORA, GDPR, NIST et COBIT 2019.

NIST SP 800-53 Rev.5 ajoute une profondeur technique par la gestion des comptes, les services de systèmes externes, la surveillance continue, la surveillance des systèmes et la protection des frontières. COBIT 2019 ajoute une profondeur de gouvernance par la gestion de la relation fournisseur, le risque fournisseur, l’échange de données, la sécurité réseau et la préparation aux changements.

Les normes ISO de soutien affinent le modèle probatoire. ISO/IEC 27017 fournit des orientations spécifiques au cloud sur les rôles partagés, la configuration des machines virtuelles et la surveillance de l’activité client. ISO/IEC 27018 se concentre sur la protection des informations à caractère personnel dans le cloud public. ISO/IEC 27701 étend les obligations de vie privée aux opérations de sous-traitant et de responsable de traitement. ISO/IEC 27036-4 soutient les accords fournisseurs cloud et la surveillance. ISO/IEC 27005 couvre l’appréciation des risques cloud.

La revue de direction doit voir le risque cloud, pas seulement la disponibilité cloud

L’un des livrables justificatifs d’audit les plus négligés est la revue de direction. ISO 27001:2022 attend de la revue de direction qu’elle prenne en compte les changements, les besoins des parties intéressées, les tendances de performance, les résultats d’audit, le statut du traitement des risques et les opportunités d’amélioration. NIS2 exige que les organes de direction approuvent les mesures de gestion des risques de cybersécurité et supervisent leur mise en œuvre. DORA exige que l’organe de direction définisse, approuve, supervise et demeure responsable de la gestion des risques liés aux TIC.

Un tableau de bord trimestriel de sécurité cloud et fournisseurs doit présenter :

• Le nombre de services cloud approuvés.
• Les services cloud critiques et leurs propriétaires.
• Les services traitant des données à caractère personnel.
• Les services soutenant des fonctions critiques ou importantes.
• Les mauvaises configurations cloud à haut risque ouvertes.
• Le statut des revues MFA et des accès à privilèges.
• La couverture de journalisation des plateformes SaaS et IaaS critiques.
• Les rapports d’assurance fournisseur reçus et revus.
• Les exceptions contractuelles et les risques acceptés.
• Les incidents cloud, quasi-accidents et enseignements tirés.
• Les résultats des tests de sauvegarde et de reprise.
• Le statut du risque de concentration et du plan de sortie.

Ce tableau de bord devient un élément probant pour le leadership et l’évaluation de la performance ISO 27001:2022, la gouvernance NIS2 et la responsabilité de la direction DORA.

Zenith Blueprint, dans la phase Risk Management, étape 14, recommande de croiser les exigences réglementaires lors de la mise en œuvre des traitements des risques et des politiques. Il indique que la cartographie des principales exigences réglementaires avec les contrôles du SMSI constitue un exercice interne utile et « impressionne également les auditeurs/évaluateurs, car elle montre que vous ne gérez pas la sécurité en vase clos, mais avec une compréhension du contexte juridique ».

C’est le niveau de maturité attendu par les autorités compétentes et les clients entreprise.

Constats fréquents d’audit cloud et moyens de les éviter

Dans les travaux de préparation à l’audit cloud, les constats récurrents sont prévisibles :

1. Le registre des services cloud existe, mais des outils SaaS manquent.
2. La localisation des données n’est pas enregistrée ou est copiée depuis des pages marketing au lieu d’éléments contractuels.
3. MFA est imposée aux employés, mais pas à tous les comptes d’administration ou comptes d’accès d’urgence.
4. Les journaux cloud sont activés, mais ne sont pas revus, conservés ou reliés à la réponse aux incidents.
5. Les rapports SOC fournisseurs sont archivés, mais non évalués.
6. Des clauses contractuelles existent pour les nouveaux fournisseurs, mais pas pour les services critiques historiques.
7. Les notifications de sous-traitants ultérieurs sont reçues par courriel, mais ne font pas l’objet d’une appréciation des risques.
8. Les tâches de sauvegarde s’exécutent correctement, mais les tests de reprise ne sont pas étayés par des éléments probants.
9. La responsabilité partagée est comprise par les ingénieurs, mais non documentée pour les auditeurs.
10. La SoA marque les contrôles cloud comme applicables, mais ne les relie pas aux entrées de risque, aux éléments probants ou aux propriétaires.

Ce sont des problèmes de traçabilité. La solution consiste à relier politique, risque, contrôle, propriétaire, éléments probants et revue.

Le jour de l’audit, Maria ne dépendait plus de captures d’écran dispersées. Elle a ouvert un tableau de bord central présentant le registre des services cloud, les appréciations des risques, les entrées SoA, les éléments probants de configuration de référence, les dossiers de revue fournisseur, la preuve de journalisation et la revue DORA du risque de concentration. Lorsque l’auditeur a demandé comment les risques cloud étaient gouvernés, elle a montré le SMSI. Lorsqu’il a demandé comment les services étaient configurés de manière sécurisée, elle a montré la configuration de référence et les éléments probants CSPM. Lorsqu’il a posé une question sur le risque lié aux prestataires tiers de services TIC, elle a montré la revue contractuelle, la surveillance des fournisseurs et la planification de sortie.

Le résultat n’était pas un environnement parfait. Aucun environnement cloud n’est parfait. La différence tenait au fait que les décisions de risque étaient documentées, les éléments probants étaient défendables et la responsabilité était visible.

Constituez votre dossier probatoire cloud avant que l’auditeur ne le demande

Si votre organisation dépend de SaaS, IaaS ou PaaS, votre prochain audit n’acceptera pas « le fournisseur s’en charge » comme réponse suffisante. Vous devez prouver la responsabilité partagée, la configuration côté client, les clauses fournisseurs, la journalisation, la préparation aux incidents, la résilience et la supervision par la direction.

Commencez par trois actions pratiques cette semaine :

1. Créez ou actualisez votre registre des services cloud à l’aide de la Politique d’utilisation du cloud de Clarysec Cloud Usage Policy ou de la Politique d’utilisation du cloud-sme Cloud Usage Policy-sme.
2. Cartographiez vos cinq principaux services cloud avec les contrôles de l’annexe A d’ISO 27001:2022, NIS2 Article 21, les obligations DORA relatives aux prestataires tiers de services TIC le cas échéant et les exigences GDPR applicables aux sous-traitants.
3. Constituez un dossier centralisé d’éléments probants en appliquant la discipline de conservation et de métadonnées de la Politique d’audit et de surveillance de la conformité Audit and Compliance Monitoring Policy ou de la Politique d’audit et de surveillance de la conformité-sme Audit and Compliance Monitoring Policy-sme.

Utilisez ensuite Zenith Blueprint Zenith Blueprint pour inscrire ces travaux dans la feuille de route d’audit SMSI en 30 étapes, et Zenith Controls Zenith Controls pour valider les cartographies de conformité croisée, les normes ISO de soutien et les attentes méthodologiques d’audit.

Clarysec peut vous aider à transformer des captures d’écran cloud dispersées, des dossiers fournisseurs et des paramètres SaaS en un dossier probatoire prêt pour les autorités compétentes, capable de résister aux audits de certification ISO 27001:2022, aux questions de supervision NIS2, aux revues DORA des prestataires tiers de services TIC et aux exigences d’assurance des clients entreprise.