Éléments probants liés à la certification cloud EUCS pour les audits 2026
La lumière du vidéoprojecteur de la salle du conseil d’administration éclairait le visage d’Amelia tandis qu’elle fixait une diapositive intitulée « Horizon conformité 2026 ». En tant que RSSI d’une fintech en forte croissance, elle avait trois acronymes à l’écran et, derrière eux, un même problème opérationnel récurrent : NIS2, DORA et GDPR renvoyaient tous aux mêmes plateformes cloud.
L’auditeur DORA demandait des éléments probants de gestion des risques liés aux ICT tiers pour les services cloud hébergeant les applications de paiement. L’autorité compétente NIS2 avait classé l’entreprise comme entité importante et demandait comment la sécurité de la chaîne d’approvisionnement était gouvernée. Le délégué à la protection des données préparait une revue GDPR centrée sur la sécurité des sous-traitants, la localisation des données et la préparation aux violations. Le service Achats a ensuite transmis un court courriel d’un fournisseur d’analytique cloud :
« Nous préparons notre certification EUCS. Cela peut-il remplacer votre revue de sécurité fournisseur ? »
Pour un RSSI, un responsable conformité ou un fondateur déjà sous tension, la réponse tentante est oui. Une certification européenne de cybersécurité cloud ressemble exactement au type d’élément probant capable de réduire les questionnaires, de rassurer les auditeurs et de satisfaire les clients.
La bonne réponse est plus précise : la certification cloud EUCS peut devenir un élément probant puissant d’assurance relative aux fournisseurs cloud, mais uniquement lorsqu’elle est cartographiée dans votre propre appréciation des risques ISO/IEC 27001:2022, votre Déclaration d’applicabilité, votre registre des fournisseurs, votre registre des services cloud, vos contrôles contractuels, vos procédures de réponse aux incidents et vos enregistrements de responsabilité GDPR.
Cette distinction est essentielle. NIS2 fait de la sécurité de la chaîne d’approvisionnement et de la résilience des infrastructures numériques un sujet de supervision. DORA maintient la responsabilité des entités financières en matière de risque lié aux ICT tiers, même lorsque les services cloud sont externalisés. GDPR exige des responsables du traitement et des sous-traitants qu’ils démontrent un traitement responsable, licite et sécurisé. ISO/IEC 27001:2022 impose un système de management fondé sur les risques, défini dans un périmètre, qui tient compte des dépendances légales, réglementaires, contractuelles et vis-à-vis de tiers.
EUCS ne supprime pas ces obligations. Il fournit un élément probant structuré à évaluer, normaliser, challenger et réutiliser.
L’approche de Clarysec est simple : traiter EUCS comme une donnée d’entrée à forte valeur pour l’assurance fournisseur, et non comme un raccourci de conformité. Dans Zenith Controls : le guide de conformité croisée, le groupe de contrôles relatif à l’assurance cloud commence par la mesure ISO/IEC 27002:2022 5.23, Sécurité de l’information pour l’utilisation des services cloud, et l’articule avec 5.20, Traitement de la sécurité de l’information dans les accords fournisseurs, et 5.22, Surveillance, revue et gestion des changements des services fournisseurs. Ces trois contrôles constituent l’ossature d’une revue défendable des éléments probants EUCS.
Pourquoi l’assurance cloud devient difficile sous NIS2, DORA et GDPR
En 2026, l’assurance cloud n’est plus un simple processus d’achat. C’est un sujet de conseil d’administration, de régulateur et d’audit.
La directive NIS2, directive (UE) 2022/2555, étend les obligations de cybersécurité des entités essentielles et importantes. Son champ d’application couvre de nombreux secteurs fortement dépendants du cloud computing, et son paysage d’infrastructures numériques inclut les fournisseurs de cloud computing, les prestataires de services de centres de données, les réseaux de diffusion de contenu, les prestataires de services de confiance, les fournisseurs de services DNS et les registres de noms de domaine de premier niveau. Les prestataires de services managés et les prestataires de services de sécurité managés sont également concernés.
Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, la gestion des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, le contrôle d’accès, la gestion des actifs et l’authentification. Article 23 établit des attentes de signalement des incidents par étapes, y compris une alerte précoce dans les 24 heures et une notification d’incident dans les 72 heures, sous réserve de la directive et de sa transposition nationale. Article 24 permet aux États membres, dans certaines circonstances, d’exiger l’utilisation de produits, services ou processus ICT certifiés dans le cadre de schémas européens de certification de cybersécurité. Article 25 encourage l’utilisation des normes européennes et internationales pertinentes.
DORA, règlement (UE) 2022/2554, est encore plus direct pour les entités financières. Depuis le 17 janvier 2025, il impose aux organisations financières de gérer le risque ICT, de signaler les incidents majeurs liés aux ICT, de tester la résilience opérationnelle numérique et de gouverner le risque lié aux ICT tiers. Pour les entités entrant dans son champ d’application, DORA constitue l’acte juridique sectoriel de l’Union pour les obligations de cybersécurité correspondantes qui recoupent les règles nationales issues de NIS2.
DORA ne permet pas d’externaliser la responsabilité. Articles 28 à 30 exigent des entités financières qu’elles réalisent des diligences préalables, évaluent le risque de concentration, tiennent des registres des accords contractuels, incluent des garanties contractuelles obligatoires, préservent les droits d’audit et d’accès, sécurisent l’assistance en cas d’incident, coopèrent avec les autorités compétentes et maintiennent des stratégies de sortie pour les services ICT soutenant des fonctions critiques ou importantes.
GDPR, règlement (UE) 2016/679, ajoute la couche de responsabilité et de protection des données. Article 5 impose aux responsables du traitement de respecter les principes de protection des données et d’être en mesure de démontrer leur conformité. Article 28 encadre les relations avec les sous-traitants et exige des garanties suffisantes de leur part. Article 32 impose des mesures techniques et organisationnelles appropriées pour assurer la sécurité du traitement.
Il en résulte un problème de convergence. Un même fournisseur cloud peut être un tiers ICT critique au sens de DORA, un fournisseur direct dans une chaîne d’approvisionnement NIS2 et un sous-traitant ou sous-traitant ultérieur au titre du GDPR. Si l’assurance est gérée au moyen de questionnaires, de PDF de certification et de dossiers contractuels déconnectés, chaque audit devient un exercice de reconstitution.
EUCS peut réduire ce désordre, mais seulement lorsqu’il est intégré dans un modèle d’éléments probants gouverné.
Ce qu’EUCS peut prouver, et ce qu’il ne peut pas prouver
Le schéma européen de certification de cybersécurité pour les services cloud, communément appelé EUCS, est conçu pour fournir un mécanisme européen d’assurance cloud dans le cadre plus large de certification de cybersécurité de l’UE. Sa valeur pratique ne réside pas dans le label seul. Elle réside dans le périmètre du certificat sous-jacent, le niveau d’assurance, les services évalués, les régions, les entités juridiques, les limites de l’évaluation, la période de validité et le modèle de surveillance.
La bonne question d’assurance cloud n’est pas simplement : « Ce fournisseur dispose-t-il d’EUCS ? » Elle est :
- Quels services cloud exacts sont couverts ?
- Quelles régions, localisations de données et entités juridiques sont couvertes ?
- Quel niveau d’assurance s’applique ?
- Quelle méthode d’évaluation a été utilisée ?
- Quelles hypothèses de responsabilité partagée restent à la charge du client ?
- Quels éléments probants peuvent être communiqués aux clients, aux autorités de régulation et aux auditeurs ?
- Quel est l’effet du certificat sur les droits d’audit, la notification des incidents, la transparence des sous-traitants et la planification de sortie ?
Un certificat cloud couvre rarement votre configuration. Si votre organisation désactive l’authentification multifacteur, expose du stockage, accorde des privilèges d’administration excessifs, omet de journaliser les accès à privilèges ou configure mal les régions, la certification du fournisseur ne sauvera pas votre audit.
C’est pourquoi EUCS doit figurer dans une matrice d’éléments probants, et non être placé sur un piédestal. Il peut étayer l’assurance côté fournisseur, mais votre organisation doit toujours prouver ses propres contrôles de gouvernance, de configuration, contractuels et de surveillance.
Le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs l’explique clairement dans la phase de Gestion des risques, étape 13, planification du traitement des risques et Déclaration d’applicabilité :
La SoA est effectivement un document de liaison : elle relie votre appréciation et votre traitement des risques aux contrôles effectivement en place. En la complétant, vous vérifiez également si vous avez omis certains contrôles.
C’est le bon modèle mental pour EUCS. Le certificat est un élément probant fournisseur. Votre Déclaration d’applicabilité explique pourquoi les contrôles associés sont applicables, comment votre organisation a mis en œuvre sa part de la responsabilité partagée, quels éléments probants fournisseurs ont été acceptés et quels risques résiduels subsistent.
L’ossature ISO 27001 des éléments probants EUCS
ISO/IEC 27001:2022 donne à EUCS un emplacement dans le système. Ses clauses exigent que les organisations comprennent les enjeux internes et externes, identifient les parties intéressées et les exigences, définissent le domaine d’application du SMSI, attribuent les responsabilités de direction, apprécient les risques, sélectionnent les contrôles, tiennent à jour une Déclaration d’applicabilité et s’inscrivent dans l’amélioration continue.
Pour l’assurance cloud, EUCS doit être intégré au minimum dans six livrables justificatifs du SMSI.
| Livrable justificatif SMSI | Utilisation attendue d’EUCS | Question de l’auditeur |
|---|---|---|
| Domaine d’application du SMSI | Identifier les services cloud, les régions, les entités juridiques, les données client et les dépendances externalisées | Le SMSI inclut-il les dépendances cloud significatives et les services externalisés ? |
| Registre des risques | Enregistrer les risques de défaillance fournisseur, mauvaise configuration, localisation des données, sous-traitance et signalement des incidents | Les risques cloud sont-ils appréciés au regard de l’impact métier et de la responsabilité partagée ? |
| Diligences préalables fournisseurs | Utiliser EUCS comme élément probant, puis vérifier le périmètre, le niveau d’assurance, la validité et les écarts | Le certificat couvre-t-il exactement le service utilisé ? |
| Déclaration d’applicabilité | Relier les contrôles cloud, fournisseurs, accès, journalisation, incidents et continuité aux risques et réglementations | La sélection des contrôles est-elle justifiée et traçable ? |
| Registre des services cloud | Enregistrer le fournisseur, la finalité, les types de données, les localisations, les accès et les détails contractuels | L’organisation peut-elle identifier tous les services cloud approuvés ? |
| Dossier contractuel et d’audit | Conserver la certification, les accords, les droits d’audit, les conditions de notification, les clauses relatives aux sous-traitants et les dispositions de sortie | L’organisation peut-elle démontrer des obligations fournisseurs opposables ? |
La bibliothèque de politiques de Clarysec transforme ces exigences en discipline opérationnelle.
La Politique d’utilisation du cloud - PME, section Exigences de gouvernance, clause 5.2, fixe un référentiel minimal pour les services cloud approuvés :
Les services cloud approuvés doivent respecter les critères de référence suivants : 5.2.1 Le fournisseur maintient une solide réputation en matière de disponibilité et de sécurité 5.2.2 L’authentification multifacteur (MFA) est prise en charge et peut être activée 5.2.3 Les pratiques de localisation des données et de protection de la vie privée respectent les exigences légales applicables (par exemple, GDPR) 5.2.4 Le service fournit des contrôles d’accès sécurisés, une journalisation et des capacités de protection des données
Un certificat EUCS peut étayer 5.2.1 ainsi que certains éléments de 5.2.3 et 5.2.4. Il ne prouve pas que l’authentification multifacteur est activée dans votre tenant, que la journalisation est configurée, que la localisation des données est appliquée ou que les accès administratifs ont été revus.
Pour les organisations plus grandes, la Politique d’utilisation du cloud Entreprise, section Exigences de gouvernance, clause 5.2, élève le niveau d’exigence :
Toute utilisation du cloud doit faire l’objet de diligences préalables fondées sur les risques avant activation, incluant l’évaluation du fournisseur, la validation de la conformité juridique et les revues de validation des contrôles.
Cette phrase résume la position de politique que toute revue EUCS doit appliquer : évaluation du fournisseur, validation de la conformité juridique et validation des contrôles, et non acceptation aveugle.
Cartographier EUCS avec ISO 27001, NIS2, DORA et GDPR
EUCS devient utilisable en audit lorsque les faits du certificat sont cartographiés avec les obligations. Un RSSI doit construire une matrice d’assurance cloud de conformité croisée qui transforme les éléments probants du fournisseur en éléments probants de contrôle réutilisables.
| Élément probant EUCS | Pertinence ISO 27001 et ISO 27002 | Pertinence NIS2 | Pertinence DORA | Pertinence GDPR |
|---|---|---|---|---|
| Périmètre du certificat et services couverts | Soutient l’appréciation du risque fournisseur et les contrôles 5.19, 5.20, 5.22 et 5.23 | Soutient la sécurité de la chaîne d’approvisionnement et les éléments probants de certification | Soutient les diligences préalables sur les fournisseurs ICT et l’exactitude du registre | Soutient l’évaluation des sous-traitants et sous-traitants ultérieurs |
| Niveau d’assurance et méthode d’évaluation | Soutient la validation des contrôles et la justification de la SoA | Démontre la proportionnalité au risque et à la criticité du service | Soutient l’évaluation des fonctions critiques ou importantes | Soutient la responsabilité pour les données à caractère personnel hébergées |
| Éléments probants de localisation des données et de juridiction | Soutient la cartographie des exigences légales, réglementaires et contractuelles | Soutient la continuité de service et l’analyse des risques liés à la chaîne d’approvisionnement | Soutient l’évaluation du risque de concentration et de sous-traitance | Soutient l’analyse de la localisation des données et des risques de transfert |
| Engagements de notification des incidents | Soutient la planification des incidents et les contrôles des accords fournisseurs | Soutient la préparation au signalement des incidents significatifs | Soutient les dépendances de notification des incidents ICT majeurs | Soutient la préparation à la réponse aux violations de données à caractère personnel |
| Éléments probants relatifs aux sous-traitants et à la chaîne d’approvisionnement | Soutient la surveillance des fournisseurs et la gestion des changements | Soutient l’évaluation des vulnérabilités propres aux fournisseurs | Soutient l’analyse de la chaîne de sous-traitance et du risque de concentration | Soutient la responsabilité de la chaîne de sous-traitants |
| Éléments probants de sortie et de restitution des données | Soutient la continuité, la résiliation et le traitement sécurisé des données | Soutient la résilience tous risques et la continuité | Soutient les stratégies de sortie testées pour les services ICT critiques | Soutient les éléments probants de suppression, de conservation et de limitation du traitement |
Ce tableau ne sert pas uniquement à la documentation de conformité. Il constitue le pont entre l’assurance du fournisseur et la responsabilité de votre organisation.
NIS2 demande si votre entité a pris des mesures appropriées et proportionnées. DORA demande si votre entité financière gouverne le risque lié aux ICT tiers au moyen de diligences préalables, de contrats, de surveillance et de planification de sortie. GDPR demande si le traitement des données à caractère personnel est licite, sécurisé et démontrable. ISO/IEC 27001:2022 demande si tout cela est intégré dans un système de management fondé sur les risques.
Exemple pratique : revue EUCS d’un fournisseur d’analytique cloud
Revenons à la fintech d’Amelia, Northstar Pay. L’entreprise souhaite intégrer une plateforme d’analytique cloud pour la détection de la fraude et le reporting des transactions. Le fournisseur présente un certificat EUCS et affirme qu’il devrait suffire à satisfaire la revue de sécurité.
Clarysec structurerait la revue des éléments probants en six étapes.
Étape 1 : Mettre à jour le registre des services cloud
La Politique d’utilisation du cloud - PME, section Exigences de gouvernance, clause 5.3, exige un registre consignant le nom du service cloud, sa finalité, le propriétaire responsable, les types de données, le pays ou la région, les autorisations d’accès, les comptes administrateur, les détails contractuels, les dates de renouvellement et les contacts de support.
Pour les entreprises, la Politique d’utilisation du cloud, section Exigences de gouvernance, clause 5.1, commence par la propriété :
L’organisation doit tenir un registre centralisé des services cloud, placé sous la responsabilité du RSSI, contenant :
Northstar Pay enregistre le service avant approbation, et non après la mise en production.
| Champ du registre | Exemple d’entrée |
|---|---|
| Service cloud | Plateforme d’analytique du fournisseur |
| Finalité métier | Analyse de la fraude et reporting des tendances transactionnelles |
| Propriétaire de l’application | Responsable des plateformes de données |
| Types de données | Identifiants clients, métadonnées de transaction, événements analytiques pseudonymisés |
| Localisation des données | Région UE uniquement, avec restriction contractuelle |
| Accès | SSO, MFA, comptes administrateur nominatifs, rôles à moindre privilège |
| Éléments probants | Certificat EUCS, certificat ISO 27001, livre blanc sécurité, accord de traitement des données, contrat, liste des sous-traitants ultérieurs |
| Date de revue | Revue annuelle et revue en cas de changement matériel du service |
Étape 2 : Valider le périmètre du certificat
L’équipe vérifie si le certificat EUCS couvre le service analytique exact, le modèle de déploiement, la région et l’entité juridique que Northstar Pay utilisera. Si le certificat couvre des services d’infrastructure mais exclut le module analytique, sa valeur probante est limitée.
C’est à ce stade que de nombreux audits échouent. Le fournisseur indique être « certifié », mais le client ne peut pas démontrer que le certificat s’applique au service traitant les données réglementées.
Étape 3 : Cartographier EUCS avec le traitement des risques et la SoA
En utilisant Zenith Blueprint, étape 13, Northstar Pay cartographie le certificat dans le registre des risques et la Déclaration d’applicabilité.
| Scénario de risque | Valeur probante d’EUCS | Contrôle côté client toujours requis |
|---|---|---|
| Accès non autorisé aux données analytiques | Soutient l’assurance de sécurité de l’infrastructure du fournisseur | Appliquer le SSO, la MFA, le RBAC, la revue des administrateurs et la journalisation |
| Données stockées hors région approuvée | Peut étayer les contrôles de localisation du fournisseur | Stockage UE uniquement contractualisé, configuration du tenant et vérification périodique |
| Retard de notification des incidents par le fournisseur | Peut étayer l’assurance relative au processus de gestion des incidents | Délais contractuels de notification, contacts d’escalade et procédure de réponse aux incidents |
| Changement de sous-traitant affectant le risque | Peut étayer la gouvernance de la chaîne d’approvisionnement | Droits d’approbation contractuels, surveillance des sous-traitants ultérieurs et réévaluation |
| Interruption cloud affectant le reporting | Peut étayer les contrôles de disponibilité | Plan de continuité d’activité, analyse RTO et RPO, stratégie de sauvegarde ou d’export |
La SoA enregistre ensuite les contrôles ISO/IEC 27002:2022 5.20, 5.22 et 5.23 comme applicables, car l’organisation utilise des services cloud pour des traitements réglementés et des workflows analytiques importants.
Étape 4 : Confirmer les clauses contractuelles et les droits d’audit
La Politique de sécurité des tiers et des fournisseurs - PME, section Exigences de gouvernance, clause 5.3, exige des clauses contractuelles obligatoires :
Les contrats doivent inclure des clauses obligatoires couvrant : 5.3.1 Confidentialité et non-divulgation 5.3.2 Obligations de sécurité de l’information 5.3.3 Délais de notification des violations de données (par exemple, dans un délai de 24 à 72 heures) 5.3.4 Droits d’audit ou disponibilité des éléments probants de conformité 5.3.5 Restrictions relatives à toute sous-traitance supplémentaire sans approbation 5.3.6 Conditions de résiliation, incluant la restitution sécurisée ou la destruction sécurisée des données
Les éléments probants EUCS et les droits contractuels répondent à des objectifs différents. Le certificat soutient l’assurance. Le contrat crée l’opposabilité.
La Politique de sécurité des tiers et des fournisseurs Entreprise, section Exigences de mise en œuvre de la politique, clause 6.1.2.2, inclut explicitement :
Revue des rapports d’audit (par exemple, SOC 2, ISO 27001, ISAE 3402)
EUCS appartient à cette famille d’éléments probants, aux côtés d’autres rapports d’assurance. Il ne doit pas remplacer la revue contractuelle, les droits d’audit, l’assistance en cas d’incident ou les clauses de stratégie de sortie exigées par DORA.
Étape 5 : Appliquer la localisation des données pour les données réglementées
La Politique d’utilisation du cloud, section Exigences de mise en œuvre de la politique, clause 6.6.2, stipule :
Les exigences de localisation des données doivent être appliquées contractuellement (par exemple, stockage uniquement dans l’UE pour les données réglementées par le GDPR).
Pour la responsabilité GDPR, un certificat décrivant les contrôles régionaux est utile. Cela ne suffit toujours pas. Northstar Pay a besoin de l’accord de traitement des données, d’une formulation contractuelle imposant le stockage uniquement dans l’UE, d’éléments probants de configuration du tenant et d’une méthode de surveillance des changements.
Si la plateforme analytique permet aux administrateurs de sélectionner les régions, le dossier d’audit doit inclure des captures d’écran de configuration, des paramètres exportés ou d’autres enregistrements démontrant la région UE approuvée.
Étape 6 : Planifier les revues annuelles et déclenchées par événement
La Politique de sécurité des tiers et des fournisseurs - PME, section Exigences de mise en œuvre de la politique, clause 6.3.1, exige une revue annuelle des fournisseurs critiques ou à haut risque afin de vérifier les méthodes d’accès sécurisées, les certifications de sécurité valides ou les éléments probants de contrôle mis à jour, l’historique des incidents et la conformité contractuelle.
La revue doit également être déclenchée lorsque le fournisseur modifie ses sous-traitants, régions, services, architecture d’identité, modèle de chiffrement, historique d’incidents ou statut de certification. Les éléments probants d’assurance vieillissent, et le risque fournisseur n’est pas statique.
Le pack d’éléments probants EUCS de Clarysec
Un pack d’assurance EUCS mature contient davantage que le PDF du certificat. Clarysec structure les éléments probants en sept sections.
| Section d’éléments probants | Contenu | Pourquoi c’est important |
|---|---|---|
| 1. Approbation cloud | Justification métier, propriétaire, notation du risque, décision d’approbation | Démontre une acquisition et une utilisation contrôlées des services cloud |
| 2. Assurance fournisseur | Certificat EUCS, autres certifications, présentation de sécurité, modèle de responsabilité partagée | Démontre les éléments probants de sécurité fournisseur et le périmètre |
| 3. Juridique et protection des données | Accord de traitement des données, conditions de localisation des données, liste des sous-traitants ultérieurs, cartographie du traitement licite | Soutient la responsabilité GDPR et les exigences contractuelles |
| 4. Configuration technique | MFA, SSO, RBAC, chiffrement, journalisation, sauvegarde, restrictions réseau | Prouve la part client de la responsabilité partagée |
| 5. Contrat fournisseur | Obligations de sécurité, droits d’accès aux éléments probants d’audit, notification des incidents, sous-traitance, résiliation | Soutient la gouvernance fournisseur ISO, NIS2 et DORA |
| 6. Incidents et résilience | Circuit d’escalade fournisseur, intégration à la procédure de réponse, RTO et RPO, enregistrements de test | Soutient le signalement NIS2 et la résilience opérationnelle DORA |
| 7. Surveillance et revue | Revue annuelle, validité du certificat, incidents, changements de service, exceptions | Soutient la surveillance continue des fournisseurs et l’amélioration continue |
La Politique de conformité juridique et réglementaire, section Exigences de mise en œuvre de la politique, clause 6.2.1, formalise le principe opérationnel :
Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, contrôles et propriétaires précis au sein du système de management de la sécurité de l’information (SMSI).
C’est ce qui distingue la collecte de certificats de la construction d’un modèle opérationnel de conformité défendable.
Éléments probants d’incident et de résilience : là où EUCS ne suffit pas
NIS2 et DORA font tous deux de la préparation aux incidents et à la résilience un test sérieux de la gouvernance cloud.
Le certificat EUCS d’un fournisseur cloud peut montrer que le fournisseur dispose de contrôles de gestion des incidents. Votre organisation doit toujours savoir qui reçoit les notifications, comment les alertes sont triées, comment les éléments de preuve sont conservés, comment l’impact sur les données à caractère personnel est évalué et qui communique avec les autorités de régulation, les clients et la direction interne.
Pour NIS2, les conditions de notification du fournisseur doivent soutenir les obligations d’alerte précoce et de notification des incidents. Pour DORA, les incidents cloud doivent alimenter les processus de classification, d’escalade, de reporting et de communication client relatifs aux incidents ICT. Pour GDPR, le workflow de violation doit permettre d’évaluer si une violation de données à caractère personnel s’est produite et si une notification à l’autorité de contrôle ou aux personnes concernées est requise.
NIST CSF 2.0 est utile ici comme langage d’intégration. Ses fonctions GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER aident les organisations à traduire les obligations légales et les contrôles techniques en résultats opérationnels. Ses résultats relatifs à la chaîne d’approvisionnement exigent que les fournisseurs soient connus, priorisés, gouvernés contractuellement, surveillés, inclus dans la planification des incidents et gérés lors de la résiliation. Ses résultats de réponse et de rétablissement couvrent le triage, l’escalade, la coordination avec les tiers, la notification aux parties prenantes, l’exécution du rétablissement et la vérification de la restauration.
Le certificat va dans le dossier. La procédure de réponse prouve la préparation.
Comment les auditeurs testeront les éléments probants EUCS
Les auditeurs abordent l’assurance cloud sous des angles différents. Un modèle d’éléments probants de conformité croisée évite de reconstruire les mêmes faits à chaque revue.
| Angle d’audit | Point d’attention de l’auditeur | Éléments probants attendus |
|---|---|---|
| Auditeur ISO 27001 | Domaine d’application du SMSI, appréciation des risques, SoA, contrôles fournisseurs, gouvernance cloud, amélioration continue | Registre des services cloud, registre des risques, SoA, évaluation fournisseur, contrat, enregistrements de configuration, éléments probants de revue |
| Superviseur ou évaluateur NIS2 | Approbation par la direction, mesures Article 21, sécurité de la chaîne d’approvisionnement, préparation au signalement des incidents | Reporting au conseil d’administration, analyse du risque fournisseur, procédure de réponse aux incidents, éléments probants de continuité d’activité, workflow de notification |
| Auditeur DORA | Registre des tiers ICT, évaluation des fonctions critiques ou importantes, contrats, droits d’audit, plans de sortie, tests de résilience | Registre des contrats ICT, diligences préalables, analyse du risque de concentration, clauses contractuelles Article 30, enregistrements de test, stratégie de sortie |
| Réviseur GDPR | Responsabilité, finalité du traitement, catégories de données, localisation des données, sécurité, préparation aux violations | Données d’entrée RoPA, accord de traitement des données, conditions de localisation des données, contrôles d’accès, workflow d’évaluation des violations, éléments probants sous-traitant |
| Évaluateur NIST CSF | Profils actuel et cible, gouvernance, gestion des risques liés à la chaîne d’approvisionnement, surveillance, réponse et rétablissement | Analyse d’écart de profil, enregistrements du cycle de vie fournisseur, rapports de surveillance, exercices de réponse aux incidents, validation de la restauration |
| Auditeur COBIT 2019 ou ISACA | Objectifs de gouvernance, responsabilité de la direction, supervision des prestataires de services, optimisation des risques, surveillance de la conformité | Comptes rendus de gouvernance, propriété des contrôles, indicateurs de performance, enregistrements de supervision des tiers, tableau de bord de conformité |
Zenith Blueprint, phase Contrôles en action, étape 23, rappelle que les contrôles cloud sont fortement examinés :
Ce contrôle fait souvent l’objet d’un examen approfondi. Les auditeurs demanderont :
✓ « Quels services cloud utilisez-vous ? » ✓ « Qui les a approuvés ? » ✓ « Comment vous assurez-vous que les données sont protégées ? »
Ces questions sont au cœur de l’assurance EUCS. Un certificat peut aider à répondre sur la manière dont la protection côté fournisseur est étayée par des éléments probants, mais il ne peut pas répondre à la question des services utilisés ni de leur approbation si votre registre des services cloud et votre workflow d’approbation ne sont pas à jour.
Erreurs courantes à éviter dans l’assurance EUCS
La première erreur consiste à traiter EUCS comme un laissez-passer universel. C’est un élément probant périmétré. Si le certificat ne couvre pas le service acheté, la région, le modèle de déploiement ou l’entité juridique, sa valeur d’assurance peut être limitée.
La deuxième erreur consiste à confondre les contrôles du fournisseur et ceux du client. La certification du fournisseur ne prouve pas la MFA du tenant, le RBAC, la journalisation, les paramètres de chiffrement, les sauvegardes, les revues d’accès administratifs ni la surveillance.
La troisième erreur consiste à négliger les exigences contractuelles de DORA. Les entités financières ont besoin de droits et obligations écrits, notamment des descriptions de services, localisations de données, exigences de sécurité de l’information, droits d’accès et d’audit, niveaux de service, assistance en cas d’incident, coopération avec les autorités, droits de résiliation et stratégies de sortie pour les fonctions critiques ou importantes.
La quatrième erreur consiste à ignorer les éléments probants GDPR. Les clauses de localisation des données, la transparence des sous-traitants ultérieurs, la gestion des violations, le traitement licite et les enregistrements de responsabilité restent nécessaires. EUCS peut étayer les éléments probants de sécurité Article 32, mais il ne définit pas votre base légale, votre finalité de traitement ni vos règles de conservation.
La cinquième erreur consiste à ne pas surveiller le statut du certificat. Si la certification expire, si le périmètre change, si des constats de surveillance apparaissent ou si le fournisseur modifie son architecture, votre revue du risque fournisseur doit intégrer ce changement.
Liste de contrôle pratique de revue EUCS 2026
Utilisez cette liste de contrôle avant d’accepter EUCS comme élément probant d’assurance relative à un fournisseur cloud :
- Confirmer le schéma de certification, le niveau d’assurance, le titulaire du certificat et la période de validité.
- Confirmer les services exacts, régions, modèles de déploiement et entités juridiques inclus dans le périmètre.
- Comparer le périmètre du certificat à l’entrée correspondante dans votre registre des services cloud.
- Cartographier les éléments probants avec les contrôles ISO/IEC 27002:2022 5.20, 5.22 et 5.23.
- Mettre à jour le registre des risques et la SoA avec les éléments probants du certificat et le risque résiduel.
- Valider les contrôles côté client, en particulier l’identité, la MFA, la journalisation, le chiffrement, les sauvegardes et les accès administrateur.
- Confirmer les clauses relatives à la localisation des données, aux sous-traitants ultérieurs, à la notification des violations, aux éléments probants d’audit et à la résiliation.
- Relier les circuits de notification des incidents aux délais NIS2, DORA et GDPR.
- Revoir le risque de concentration et la stratégie de sortie pour les services critiques ou importants.
- Planifier une revue annuelle et une réévaluation déclenchée par événement.
Faire fonctionner les éléments probants EUCS dans votre SMSI
La certification cloud EUCS peut améliorer de manière significative l’assurance relative aux fournisseurs cloud en 2026. Elle peut réduire la fatigue liée aux questionnaires, renforcer les diligences préalables fournisseurs et soutenir les éléments probants ISO 27001, NIS2, DORA et GDPR. Mais elle ne devient défendable que lorsqu’elle est cartographiée dans votre système de gouvernance.
Clarysec aide les organisations à transformer les éléments probants de certification cloud en opérations de conformité compatibles avec les exigences d’audit grâce à Zenith Blueprint, Zenith Controls, Politique d’utilisation du cloud, Politique d’utilisation du cloud - PME, Politique de sécurité des tiers et des fournisseurs - PME, Politique de sécurité des tiers et des fournisseurs et Politique de conformité juridique et réglementaire.
Si votre feuille de route 2026 inclut EUCS, la préparation NIS2, le risque lié aux ICT tiers au titre de DORA, les traitements cloud sous GDPR ou la certification ISO/IEC 27001:2022, commencez par une action concrète : constituer votre registre des services cloud, y joindre les éléments probants d’assurance fournisseur et cartographier chaque service cloud critique avec les risques, contrats, contrôles et propriétaires. C’est là que l’assurance cloud devient défendable.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
