Gouvernance des régions cloud pour GDPR, NIS2 et DORA

À 08 h 17, un mardi matin, Maria, RSSI d’une fintech européenne en forte croissance, reçoit le message que tout client cloud réglementé finit par redouter.

L’équipe achats transmet un bref avis fournisseur :

« Notre fournisseur d’analytique cloud transfère la télémétrie des clients de l’UE vers une nouvelle région pour des motifs de performance. Il indique qu’il n’y a pas d’impact sur la sécurité. Pouvons-nous approuver ? »

Avant que Maria puisse répondre, une deuxième notification arrive du fournisseur principal de services cloud. Dans 90 jours, le fournisseur va « optimiser son modèle d’assistance mondial » en acheminant les tickets d’assistance de niveau 2 via un nouveau sous-traitant ultérieur. Une revue rapide montre que ce sous-traitant ultérieur est établi dans un pays ne bénéficiant pas d’une décision d’adéquation au titre de GDPR.

À 09 h 00, les fonctions juridique, protection des données, résilience, achats, ingénierie cloud et conformité financière ont rejoint le fil. Le délégué à la protection des données (DPO) demande si une analyse d’impact relative au transfert est nécessaire. Le responsable de la résilience demande si la nouvelle région affecte le plan de reprise d’un service critique. Le responsable de la conformité financière demande si le fournisseur figure dans le registre DORA des tiers TIC. L’équipe cloud vérifie le plan de données de production et comprend que le sujet dépasse l’analytique. Les sauvegardes, journaux opérationnels, tickets d’assistance, exports de lac de données, accès d’urgence et accès des sous-traitants peuvent tous entrer dans le périmètre.

C’est le véritable problème de gouvernance cloud en 2026.

La plupart des organisations disposent d’une politique cloud. Beaucoup tiennent un registre des fournisseurs. Certaines disposent d’une évaluation des transferts au titre de GDPR. Plus rares sont celles qui peuvent répondre, éléments de preuve à l’appui, à la question d’audit la plus exigeante :

Où résident exactement les données réglementées et les traitements TIC critiques, qui peut y accéder et depuis quel lieu, que se passe-t-il lors d’un basculement, et quel contrôle contractuel empêche le fournisseur de modifier la réponse sans approbation ?

C’est cela, la gouvernance des régions cloud. Ce n’est pas une simple case juridique à cocher. C’est un système de contrôle vivant couvrant ISO/IEC 27001:2022, les contrôles cloud et fournisseurs d’ISO/IEC 27002:2022, la responsabilité au titre de GDPR, la résilience des services au titre de NIS2 et la supervision des tiers TIC au titre de DORA.

La localisation des données est désormais un contrôle opérationnel

Pendant des années, « hébergement exclusivement dans l’UE » a été traité comme une clause d’un accord de traitement des données. Cela ne suffit plus. Un programme moderne de localisation des données cloud et de gouvernance des régions doit couvrir au minimum six couches opérationnelles :

1. Les régions principales de stockage et de calcul en production.
2. Les régions de sauvegarde, d’archivage et de reprise après sinistre.
3. Les emplacements des données de journalisation, de surveillance, de SIEM et d’observabilité.
4. Les accès d’assistance, y compris l’administration à distance et les accès d’urgence.
5. Les sous-traitants ultérieurs et sous-traitants, y compris les services managés et les composants de place de marché.
6. Les chemins de transfert de données entre environnements, interfaces de programmation (API), plateformes d’analytique et outils d’assistance client.

GDPR rend ce sujet incontournable, car les données à caractère personnel peuvent inclure des identifiants en ligne, des adresses IP, des identifiants de comptes clients, des enregistrements utilisateurs, des identifiants d’équipements, des métadonnées opérationnelles et des enregistrements d’assistance. Le traitement est également défini largement : stockage, accès, utilisation, divulgation, effacement et destruction. « Nous envoyons seulement des journaux » n’est pas une exception sûre si ces journaux contiennent des identifiants.

L’Article 5 de GDPR inclut également le principe de responsabilité. Les responsables du traitement doivent non seulement respecter les principes de licéité, de loyauté, de transparence, de limitation des finalités, de minimisation des données, de limitation de la conservation, d’intégrité et de confidentialité. Ils doivent aussi être en mesure de démontrer cette conformité. La gouvernance des régions cloud est l’un des moyens de rendre cette démonstration concrète.

NIS2 étend le sujet de la protection des données à la résilience. Au titre de l’Article 21, les entités essentielles et importantes doivent mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées pour gérer les risques pesant sur les réseaux et systèmes d’information utilisés pour les opérations ou la fourniture de services. Les mesures listées incluent la sécurité de la chaîne d’approvisionnement, la continuité d’activité, la gestion des sauvegardes, la reprise après sinistre, la gestion de crise, le contrôle d’accès, la gestion des actifs, le chiffrement et l’évaluation de l’efficacité. Si une décision relative à une région cloud affecte la disponibilité ou la reprise d’un service dans le périmètre, ce n’est pas seulement une question de protection des données. C’est une question de résilience.

Pour les entités financières, DORA relève encore le niveau d’exigence. DORA s’applique depuis le 17 janvier 2025 et établit des exigences en matière de gestion des risques liés aux TIC, de notification des incidents, de tests de résilience opérationnelle numérique, de gestion des risques liés aux tiers TIC et d’arrangements contractuels. L’Article 28 exige que les entités financières gèrent le risque lié aux tiers TIC comme une partie intégrante du cadre de gestion des risques liés aux TIC, tiennent des registres des arrangements contractuels, évaluent le risque de concentration et planifient les sorties pour les fonctions critiques ou importantes. L’Article 30 attend une clarté contractuelle sur les lieux de fourniture du service et de traitement des données, les droits d’audit et d’accès, l’assistance en cas d’incident, la sous-traitance, la reprise, la restitution et la transition de sortie.

DORA constitue le régime sectoriel applicable aux entités financières, tandis que NIS2 conserve son importance dans l’ensemble de la chaîne d’approvisionnement, notamment pour les fournisseurs de services cloud, les fournisseurs de centres de données et les prestataires de services managés. Un seul sous-traitant ultérieur non évalué peut donc produire un effet domino sur la résilience financière, la sécurité de la chaîne d’approvisionnement et les obligations de protection des données.

En termes simples, une entreprise réglementée qui ne sait pas gouverner où se produisent ses traitements cloud ne peut pas gouverner de façon crédible son risque lié aux tiers TIC.

Utiliser ISO 27001 comme ancrage du système de management

ISO/IEC 27001:2022 fournit la structure nécessaire pour transformer la confusion sur la localisation en système de management maîtrisé.

Les clauses 4.1 à 4.4 exigent que l’organisation définisse le SMSI dans son contexte, y compris les enjeux internes et externes, les exigences des parties intéressées, les obligations légales, réglementaires et contractuelles, ainsi que les interfaces et dépendances avec d’autres organisations. Pour la gouvernance des régions cloud, le domaine d’application du SMSI doit explicitement inclure les services cloud, le traitement TIC externalisé, les dépendances de services critiques et les flux de données réglementées.

Les clauses 5.1 à 5.3 rendent la direction responsable. La direction doit aligner la politique de sécurité de l’information et les objectifs avec l’orientation stratégique, fournir les ressources, attribuer les responsabilités et veiller à ce que la performance du SMSI fasse l’objet de rapports. C’est à ce niveau que la localisation cloud devient un sujet de direction et de conseil d’administration, en particulier pour les entités NIS2 dont les organes de direction doivent approuver et superviser les mesures de gestion des risques de cybersécurité, ainsi que pour les entités financières DORA dont l’organe de direction est responsable de la gouvernance des risques TIC.

Les clauses 6.1.1 à 6.1.3 fournissent le moteur de gestion des risques. L’organisation a besoin d’un processus d’appréciation des risques répétable, de propriétaires des risques, de critères d’impact et de vraisemblance, d’options de traitement, de contrôles sélectionnés, d’une Déclaration d’applicabilité et d’une acceptation du risque résiduel. Un changement de région cloud ne doit pas être approuvé par un courriel informel. Il doit déclencher une appréciation des risques ou une revue de changement lorsqu’il affecte des données réglementées, des fonctions critiques, des fournisseurs ou des hypothèses de continuité.

La clause 8.1 transforme la planification en maîtrise opérationnelle. Les processus doivent être mis en œuvre, maîtrisés, documentés, modifiés de manière contrôlée et étendus aux produits et services fournis par des tiers qui sont pertinents pour le SMSI. Les clauses 8.2 et 8.3 exigent une réévaluation et un traitement à intervalles planifiés ou lorsque des changements significatifs surviennent. La migration vers une région cloud, la réplication de sauvegardes, une nouvelle plateforme de journalisation ou un changement de sous-traitant ultérieur pour l’assistance sont tous des cas de réévaluation potentiels.

L’ensemble de contrôles ISO/IEC 27002:2022 fournit ensuite la famille de contrôles pratiques. Les contrôles les plus pertinents incluent :

• 5.9 Inventaire des informations et autres actifs associés.
• 5.14 Transfert d’informations.
• 5.15 Contrôle d’accès.
• 5.19 Sécurité de l’information dans les relations avec les fournisseurs.
• 5.20 Prise en compte de la sécurité de l’information dans les accords fournisseurs.
• 5.22 Surveillance, revue et gestion des changements des services fournisseurs.
• 5.23 Sécurité de l’information pour l’utilisation des services cloud.
• 5.29 Sécurité de l’information pendant les perturbations.
• 5.30 Préparation des TIC à la continuité d’activité.
• 5.31 Exigences légales, statutaires, réglementaires et contractuelles.
• 5.34 Vie privée et protection des informations à caractère personnel.
• 5.36 Conformité aux politiques, règles et normes de sécurité de l’information.
• 8.11 Masquage des données.
• 8.12 Prévention des fuites de données.
• 8.13 Sauvegarde des informations.
• 8.15 Journalisation.
• 8.16 Activités de surveillance.
• 8.20 Sécurité des réseaux.
• 8.24 Utilisation de la cryptographie.
• 8.25 Cycle de vie de développement sécurisé.
• 8.27 Principes d’architecture et d’ingénierie sécurisées des systèmes.
• 8.32 Gestion des changements.

Le guide Zenith Controls : le guide de conformité croisée Zenith Controls de Clarysec traite le contrôle ISO/IEC 27002:2022 5.23, Sécurité de l’information pour l’utilisation des services cloud, comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec une capacité opérationnelle dans la sécurité des relations fournisseurs et dans les domaines de sécurité couvrant la gouvernance, l’écosystème et la protection. Le guide relie 5.23 à 5.19 relations fournisseurs, 5.14 transfert d’informations, 5.9 inventaire des actifs, 8.11 et 8.12 masquage des données et prévention des fuites de données, 8.20 sécurité réseau et 8.25 cycle de vie de développement sécurisé.

Une observation clé de Zenith Controls est la suivante :

« Les fournisseurs de services cloud (CSP) agissent comme des fournisseurs critiques ; par conséquent, 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 phrase résume le changement de gouvernance. Un fournisseur cloud n’est pas un fournisseur comme les autres. Il est souvent le lieu où résident les traitements réglementés.

Les pièges cachés de la localisation : sauvegardes, journaux, assistance et sous-traitants ultérieurs

La plupart des défaillances de localisation des données ne commencent pas par la base de données de production. Elles commencent par des systèmes d’assistance qui n’ont jamais été correctement inclus dans la revue des flux de données.

Les sauvegardes en sont l’exemple classique. Une plateforme SaaS peut fonctionner à Francfort ou à Dublin, tandis que les sauvegardes automatiques sont répliquées ailleurs pour des raisons de résilience ou de coût. Si la sauvegarde contient des données à caractère personnel, des enregistrements clients, des journaux d’authentification ou un historique de transactions réglementées, la région de sauvegarde importe. Au titre de l’Article 21 de NIS2, la gestion des sauvegardes et la reprise après sinistre font partie du socle minimal de sécurité. Au titre de DORA, la continuité des fonctions critiques ou importantes et les stratégies de sortie testées exigent de connaître les emplacements de reprise et les dépendances de reprise.

Les journaux sont un autre point faible. Les équipes de sécurité centralisent la télémétrie dans des services SIEM, d’observabilité et de lac de données. Ces journaux peuvent inclure des adresses IP, des identifiants utilisateurs, des actions administrateur, des métadonnées de paiement, des tentatives d’authentification échouées, des identifiants de comptes clients ou des données de trace d’assistance. Si les journaux sont envoyés vers un service mondial de surveillance, l’organisation peut avoir créé un transfert transfrontalier sans s’en rendre compte.

La Politique de journalisation et de surveillance - PME de Clarysec Politique de journalisation et de surveillance - PME traite directement les éléments de preuve fournisseurs :

« Les contrats doivent exiger des fournisseurs qu’ils conservent les journaux pendant au moins 12 mois et qu’ils fournissent un accès sur demande »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.5.1.3. Pour la gouvernance de la localisation des données, la même revue contractuelle doit confirmer où ces journaux sont conservés, qui peut y accéder et si les éléments de preuve issus des journaux sont disponibles lors d’une investigation d’incident ou d’une demande réglementaire.

L’accès d’assistance est plus subtil. Un fournisseur peut héberger les données dans l’UE, tandis que des ingénieurs support situés hors de l’UE peuvent accéder aux environnements clients, aux instantanés de bases de données, aux packages de diagnostic ou aux pièces jointes des tickets. L’acceptabilité dépend des données concernées, du mécanisme de transfert, du rôle, des garanties contractuelles, des contrôles d’accès et de la journalisation. L’architecture peut être régionale, alors que le modèle d’accès humain est mondial.

Les sous-traitants ultérieurs créent le dernier angle mort. Votre fournisseur direct peut s’appuyer sur une infrastructure cloud, des réseaux de diffusion de contenu, des bases de données managées, des plateformes de gestion de tickets, des services d’analytique, des équipes d’assistance offshore ou des fournisseurs de sécurité. L’Article 29 de DORA exige l’évaluation des risques de sous-traitance, des fournisseurs de pays tiers, des contraintes de récupération des données, de la conformité en matière de protection des données et des chaînes de sous-traitance complexes. L’Article 21 de NIS2 impose aux entités de tenir compte des pratiques de cybersécurité des fournisseurs directs et prestataires de services. GDPR exige des sous-traitants qu’ils gèrent les sous-traitants ultérieurs de manière à préserver la capacité du responsable du traitement à se conformer.

La Politique de sécurité des tiers et des fournisseurs - PME de Clarysec Politique de sécurité des tiers et des fournisseurs - PME rend cela opérationnel :

« Lorsque les fournisseurs sont tenus de stocker des données hors site, l’entreprise doit obtenir une assurance concernant la protection des données, la sécurité physique et l’emplacement géographique de stockage (par exemple, hébergement exclusivement dans l’UE lorsque GDPR l’exige). »

Cette citation provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.4. La même politique exige également :

« Restrictions relatives à toute sous-traitance ultérieure sans approbation »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.3.5. Ensemble, ces clauses transforment la localisation en processus de gestion des fournisseurs, et non en préférence d’achat.

Transformer la politique en gouvernance applicable des régions cloud

La gouvernance des régions cloud doit être applicable, révisable et auditable.

Pour les PME, la Politique d’utilisation du cloud - PME Politique d’utilisation du cloud - PME établit le socle minimal :

« Les pratiques de localisation des données et de protection de la vie privée sont conformes aux exigences légales applicables (par exemple, GDPR) »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.2.3. La même politique exige que les enregistrements de gouvernance du cloud incluent :

« Le pays ou la région où les données sont stockées »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.3.4.

Pour les organisations de plus grande taille, la Politique d’utilisation du cloud Politique d’utilisation du cloud est plus explicite sur la mise en application contractuelle :

« Les exigences de localisation des données doivent être rendues contractuellement opposables (par exemple, stockage exclusivement dans l’UE pour les données soumises à GDPR). »

Cette citation provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.6.2. Elle précise également :

« Les transferts transfrontaliers de données doivent être conformes au chapitre V de GDPR et, le cas échéant, à l’Article 28 de DORA. »

Cette citation provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.6.3.

La version entreprise attire également l’attention sur :

« Garanties relatives à la localisation des données et à la propriété des données »

Cette citation provient de la section « Rôles et responsabilités », clause de politique 4.5.1.2.

La Politique de sécurité des tiers et des fournisseurs Politique de sécurité des tiers et des fournisseurs ajoute la couche contractuelle en exigeant :

« Exigences de traitement des données, y compris l’emplacement de stockage, les contrôles d’accès et les clauses de restitution ou de destruction »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.3.2.

Enfin, la Politique de conformité juridique et réglementaire Politique de conformité juridique et réglementaire identifie les changements devant déclencher une revue de conformité, notamment :

« Changements apportés aux mécanismes de transfert de données, aux sous-traitants ultérieurs ou aux flux de données transfrontaliers »

Cette citation provient de la section « Exigences de gouvernance », clause de politique 5.3.1.1.

Ces documents ne doivent pas fonctionner comme des fichiers séparés. Dans un SMSI mature, ils deviennent un modèle opérationnel unique : inventaire cloud, registre des flux de données, registre des fournisseurs, matrice contractuelle, appréciation des risques, revue des transferts, approbation des changements et dossier d’éléments de preuve d’audit.

Construire un registre de gouvernance des régions cloud

Un registre pratique transforme la localisation cloud d’une hypothèse en éléments de preuve. Commencez par un service critique orienté client, en particulier s’il est susceptible d’entrer dans le périmètre de NIS2, de la diligence raisonnable client DORA ou d’un examen au titre de GDPR.

Reliez ensuite le registre à la mise en œuvre.

Dans Zenith Blueprint : feuille de route d’audit en 30 étapes de Clarysec Zenith Blueprint, la phase Contrôles en action, étape 23, se concentre sur les contrôles organisationnels 5.19 à 5.37, notamment les accords fournisseurs et la gouvernance des services cloud. Le Blueprint avertit que les accords fournisseurs doivent couvrir plus que la confidentialité générique :

« Dans de nombreux secteurs, les accords fournisseurs définissent également la propriété des données et la juridiction. Où les données sont-elles traitées ? Qui conserve le contrôle ? Existe-t-il des restrictions de transfert ? Existe-t-il des contrôles propres au cloud, comme la segmentation des données, la propriété des clés ou les limitations géographiques ? Ces éléments ne sont pas seulement juridiques : ce sont des enjeux opérationnels de sécurité, en particulier dans les secteurs réglementés. »

La même phase et la même étape traitent de la gestion des changements fournisseurs :

« La plupart des relations fournisseurs commencent avec de bonnes intentions. Une revue approfondie, des attentes claires, des accords signés (voir 5.20), peut-être même une liste de contrôle de sécurité. Mais que se passe-t-il un an plus tard, lorsque le fournisseur propose de déplacer vos données vers une nouvelle région cloud ? »

C’est le problème du mardi matin de Maria. Le registre donne au RSSI un moyen de répondre avant d’approuver le déplacement.

Le Zenith Blueprint clarifie également la signification de gouvernance du contrôle cloud 5.23 :

« Un compartiment de stockage mal configuré, un tableau de bord exposé publiquement ou des autorisations excessives dans une configuration IAM cloud : ce ne sont pas des défaillances du cloud. Ce sont des défaillances de gouvernance. »

Dans la phase Contrôles en action, étape 22, le Blueprint traite du transfert d’informations et indique :

« Si des données à caractère personnel sont transférées au-delà des frontières, la méthode doit respecter les obligations de protection de la vie privée et les obligations légales, et pas seulement les préférences internes. »

Cette phrase est essentielle pour les équipes cloud. Le chiffrement, les interfaces de programmation (API) sécurisées et la connectivité privée sont nécessaires, mais ils ne remplacent pas la gouvernance juridique et réglementaire des transferts.

Organiser le premier atelier de 90 minutes sur les éléments de preuve

Ne commencez pas par cartographier toute l’entreprise. Commencez par un service critique et organisez un atelier ciblé avec l’ingénierie cloud, les achats, le juridique, la protection des données, la résilience et les opérations de sécurité.

Premièrement, listez chaque composant cloud ou fournisseur qui stocke, traite, transmet, sauvegarde, surveille ou prend en charge le service. Incluez les systèmes secondaires tels que la surveillance de disponibilité, les pièces jointes des tickets, le suivi des erreurs, les outils de partage d’écran pour l’assistance et les exports de diagnostic.

Deuxièmement, marquez chaque catégorie de données. Si l’équipe répond « uniquement des métadonnées », remettez l’hypothèse en question. Les métadonnées peuvent tout de même constituer des données à caractère personnel ou des données confidentielles client.

Troisièmement, vérifiez la région à partir d’éléments de preuve. Utilisez la configuration de la console cloud, les politiques de sauvegarde, les paramètres de l’instance SIEM, les annexes DPA, les listes de sous-traitants ultérieurs, les conditions contractuelles, la documentation d’accès d’assistance et les rapports d’audit CSP. Ne vous appuyez pas uniquement sur des assurances commerciales.

Quatrièmement, consignez les lacunes dans le registre des risques du SMSI. Exemples : « région de réplication des sauvegardes non restreinte contractuellement », « accès d’assistance depuis un pays tiers sans processus d’approbation documenté », « journaux SIEM conservés mondialement », « liste des sous-traitants ultérieurs n’identifiant pas la région d’hébergement », ou « registre DORA ne distinguant pas les dépendances de fonctions critiques ou importantes ».

Cinquièmement, décidez du traitement. Les traitements peuvent inclure une modification contractuelle, un verrouillage de région, une notification client, le chiffrement avec des clés gérées par le client, la tokenisation, la minimisation des journaux, l’approbation d’un nouveau fournisseur, la mise à jour de la stratégie de sortie ou l’acceptation du risque résiduel par le propriétaire du risque.

Sixièmement, conservez les éléments de preuve. Les auditeurs ne demanderont pas seulement ce que vous avez décidé. Ils demanderont comment vous savez que cela a été mis en œuvre.

Mettre en correspondance un même ensemble de preuves avec ISO, GDPR, NIS2, DORA et NIST CSF 2.0

Un programme solide de gouvernance des régions cloud évite de dupliquer les travaux de conformité. Les mêmes éléments de preuve peuvent soutenir plusieurs obligations s’ils sont correctement structurés.

NIST CSF 2.0 est utile comme couche d’intégration. Sa fonction GOVERN s’aligne sur les obligations légales, réglementaires, contractuelles et de protection de la vie privée, l’appétence au risque, la responsabilité, les politiques et la supervision. Sa catégorie GV.SC relative à la chaîne d’approvisionnement correspond bien aux attentes DORA relatives aux tiers TIC, aux exigences NIS2 de chaîne d’approvisionnement et aux contrôles fournisseurs ISO.

COBIT 2019 et une approche d’audit ISACA testent souvent les mêmes faits au regard d’objectifs de gouvernance : propriété, droits de décision, optimisation des risques, performance des fournisseurs, réalisation des bénéfices et assurance. Un auditeur adoptant une approche COBIT ne commencera pas forcément par « quelle région cloud est configurée ? ». Il pourra commencer par « qui a l’autorité pour approuver un changement de région, comment le risque est-il escaladé et comment la direction sait-elle que les fournisseurs cloud restent dans la tolérance ? »

C’est pourquoi le modèle Clarysec capture les propriétaires, les points d’approbation, les éléments de preuve contractuels et les rapports de direction, et pas seulement les paramètres techniques.

Se préparer aux questions de l’auditeur

La gouvernance des régions cloud illustre parfaitement comment différents auditeurs examinent un même contrôle sous des angles différents.

Un auditeur ISO/IEC 27001:2022 commencera par le domaine d’application, les exigences des parties intéressées, l’appréciation des risques et la Déclaration d’applicabilité. Il demandera si les exigences légales, réglementaires et contractuelles sont identifiées, si les contrôles cloud et fournisseurs sont inclus, si les risques ont été évalués, si les contrôles sont mis en œuvre et si les éléments de preuve sont conservés. Il pourra échantillonner un service cloud et demander la revue d’intégration, les clauses contractuelles, la configuration de région, la revue de surveillance et l’approbation de changement.

Une autorité de contrôle de la protection des données ou un évaluateur GDPR se concentrera sur les données à caractère personnel. Il demandera quelles données à caractère personnel sont traitées, où elles sont stockées, depuis quels lieux elles sont consultées, quels sous-traitants et sous-traitants ultérieurs interviennent, si les mécanismes de transfert sont documentés, si une analyse d’impact relative au transfert est nécessaire et si des mesures techniques et organisationnelles appropriées sont en place. Les journaux, les données d’assistance et les sauvegardes attirent souvent l’attention, car les organisations les sous-estiment.

Un auditeur NIS2 ou une autorité compétente se concentrera sur les services dans le périmètre. Il examinera la responsabilité de la direction au titre de l’Article 20, les mesures de gestion des risques au titre de l’Article 21, la continuité, la gestion des sauvegardes, la reprise après sinistre, la gestion des incidents, la sécurité de la chaîne d’approvisionnement, le contrôle d’accès, la gestion des actifs et l’évaluation de l’efficacité.

Un superviseur DORA ou une équipe d’audit interne recherchera la gouvernance des risques TIC, la supervision par l’organe de direction, le registre d’informations des arrangements avec les tiers TIC, la cartographie des fonctions critiques ou importantes, le risque de concentration, le risque de sous-traitance, les lieux de traitement des données, les droits d’audit, l’assistance à la notification des incidents, les tests de continuité et les plans de sortie. DORA indique clairement que l’externalisation ne transfère pas la responsabilité.

Zenith Controls aide les responsables de la sécurité à se préparer à ces styles d’audit, car il établit des références croisées entre les relations de contrôles. Pour le contrôle ISO/IEC 27002:2022 5.20, Prise en compte de la sécurité de l’information dans les accords fournisseurs, Zenith Controls le relie à 5.19 relations fournisseurs, 5.14 transfert d’informations, 5.22 surveillance des fournisseurs, 5.11 restitution des actifs et 5.36 conformité aux politiques, règles et normes. Pour le contrôle 5.22, Surveillance, revue et gestion des changements des services fournisseurs, il relie la supervision continue des fournisseurs à 5.29 sécurité pendant les perturbations, 8.8 gestion des vulnérabilités techniques, 5.15 contrôle d’accès, 8.27 principes d’architecture et d’ingénierie sécurisées des systèmes et 5.36 conformité.

Cette vue transverse des contrôles est importante, car un changement de région n’est jamais seulement un changement de région. Il peut modifier le risque fournisseur, le risque de transfert, le risque d’accès, le risque de continuité, les éléments de preuve de réponse aux incidents et la conformité contractuelle.

Utiliser cette liste de contrôle RSSI 2026 avant d’approuver un changement cloud

Utilisez cette liste de contrôle avant d’approuver toute nouvelle région cloud, tout nouveau chemin de traitement transfrontalier, nouvel emplacement de sauvegarde, nouvelle plateforme de journalisation, nouveau modèle d’assistance ou changement de fournisseur TIC critique.

Si la réponse à une question est « nous supposons », le contrôle n’est pas assez mature pour des opérations réglementées.

La feuille de route de remédiation

Le parcours de remédiation est concret lorsqu’il est ancré dans le SMSI.

1. Confirmer que le domaine d’application du SMSI inclut les services cloud, les dépendances TIC critiques et le traitement de données réglementées.
2. Construire le registre de gouvernance des régions cloud pour les services prioritaires.
3. Mettre en correspondance chaque service avec les catégories de données, les régions, les emplacements de sauvegarde, les accès d’assistance et les sous-traitants ultérieurs.
4. Revoir les accords fournisseurs concernant les clauses d’emplacement de stockage, de transfert, d’audit, d’incident, de sous-traitance, de restitution et de destruction.
5. Mettre à jour le registre des risques pour les lacunes, les risques de concentration et les transferts non documentés.
6. Aligner, le cas échéant, le registre DORA des tiers TIC et la cartographie NIS2 des dépendances de service.
7. Valider la mise en application technique, y compris les verrous de région, les politiques de sauvegarde, les paramètres de journalisation, le chiffrement, les contrôles d’accès et la gestion des clés.
8. Préparer un dossier d’éléments de preuve d’audit avec captures d’écran, contrats, enregistrements de risques, approbations, comptes rendus de revue et résultats des tests.
9. Établir un déclencheur de changement pour les nouvelles régions, les sous-traitants ultérieurs, les mécanismes de transfert ou les changements de services fournisseurs critiques.
10. Présenter à la direction les risques de localisation cloud, les exceptions et les décisions d’acceptation du risque résiduel.

Ce n’est pas une conformité théorique. C’est la différence entre un environnement cloud capable de résister à l’examen d’un audit et un environnement qui dépend d’assurances verbales.

L’analyse de rentabilité : souveraineté, résilience et confiance

Les dirigeants considèrent parfois la gouvernance de la localisation des données comme une contrainte pour l’agilité cloud. En pratique, une gouvernance mature des régions améliore l’agilité, car les équipes connaissent les règles avant d’acheter, de construire ou de migrer.

Une équipe produit peut lancer plus vite lorsque les régions approuvées sont claires. Les achats peuvent négocier plus vite lorsque les clauses obligatoires sont déjà définies. Le juridique peut évaluer les transferts plus vite lorsque les flux de données sont documentés. Les opérations de sécurité peuvent investiguer plus vite lorsque les emplacements des journaux et les droits d’accès sont connus. Le conseil d’administration peut prendre des décisions de risque plus vite lorsque le risque de concentration, l’impact sur la continuité et l’acceptation du risque résiduel sont visibles.

Pour les clients, en particulier les clients réglementés, cela devient un signal de confiance. Un fournisseur SaaS capable d’expliquer où les données résident, comment les sauvegardes sont gouvernées, comment l’accès d’assistance est contrôlé, comment les sous-traitants ultérieurs sont approuvés et comment les changements de région sont revus surpassera un fournisseur qui se contente d’affirmer « nous utilisons un grand fournisseur cloud ».

En 2026, cette distinction compte. NIS2 a porté la gouvernance de la cybersécurité au niveau des entités essentielles et importantes dans toute l’UE. DORA a fait de la supervision des tiers TIC une discipline formelle du secteur financier. La responsabilité au titre de GDPR demeure centrale. ISO/IEC 27001:2022 fournit le système de management qui tient l’ensemble.

Prochaines étapes avec Clarysec

Si votre organisation ne peut pas répondre précisément à la question de savoir où résident les données réglementées et les traitements TIC critiques dans la production, les sauvegardes, les journaux, les accès d’assistance et les sous-traitants, le moment est venu de combler l’écart.

Clarysec peut vous aider à constituer un dossier d’éléments de preuve pour la gouvernance des régions cloud au moyen de :

• Zenith Blueprint : feuille de route d’audit en 30 étapes Zenith Blueprint pour une mise en œuvre ISO par phases et la préparation à l’audit.
• Zenith Controls : le guide de conformité croisée Zenith Controls pour mettre en correspondance les contrôles cloud et fournisseurs d’ISO/IEC 27002:2022 avec les éléments de preuve opérationnels et les attentes transverses des référentiels.
• Politique d’utilisation du cloud Politique d’utilisation du cloud et Politique d’utilisation du cloud - PME Politique d’utilisation du cloud - PME pour les exigences de localisation des données cloud.
• Politique de sécurité des tiers et des fournisseurs Politique de sécurité des tiers et des fournisseurs et Politique de sécurité des tiers et des fournisseurs - PME Politique de sécurité des tiers et des fournisseurs - PME pour les contrats fournisseurs, la sous-traitance et l’assurance relative au stockage géographique.
• Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME pour la conservation des journaux et les éléments de preuve des fournisseurs.
• Politique de conformité juridique et réglementaire Politique de conformité juridique et réglementaire pour les déclencheurs de revue de conformité liés aux mécanismes de transfert, aux sous-traitants ultérieurs et aux flux de données transfrontaliers.

Commencez avec un service critique, un fournisseur cloud et un registre. En quelques ateliers, vous pouvez passer des hypothèses aux éléments de preuve, et d’une conformité fragmentée à une résilience cloud gouvernée.

Téléchargez la boîte à outils Clarysec, demandez une démonstration ou réservez une évaluation de la gouvernance des régions cloud afin de transformer vos engagements de localisation cloud en preuves prêtes pour l’audit.