EU Cloud Code of Conduct
Quand une banque demande à un fournisseur cloud de prouver qu’il traite correctement les données personnelles, celui-ci répond souvent par son adhésion à EU Cloud Code of Conduct. Cette réponse a une portée précise, sans plus, et comprendre cette limite fait gagner des semaines aux achats.
EU Cloud Code of Conduct est un code transnational au titre de l’article 40 du RGPD pour les fournisseurs cloud agissant comme sous-traitants. EU Cloud Code of Conduct a été fondé en février 2017 après des travaux entre la Commission européenne et le secteur cloud, et les autorités de contrôle ont approuvé une version révisée en mai 2021.
Base juridique: article 40 du RGPD et organisme de contrôle
L’article 40 du RGPD permet aux associations d’élaborer des codes appliquant le règlement à un secteur particulier, puis une autorité de contrôle approuve le code. Lorsqu’un code couvre des traitements dans plusieurs États membres, le Comité européen de la protection des données donne un avis et la Commission peut confirmer sa validité générale. Le code fonctionne ensuite avec un organisme de contrôle agréé selon l’article 41 du RGPD; c’est ce qui distingue un code d’une autodéclaration: cet organisme évalue si le service déclaré répond réellement aux exigences et peut suspendre ou exclure un fournisseur.
Pour EU Cloud Code of Conduct, cet organisme est SCOPE Europe, établi à Bruxelles. L’évaluation de SCOPE Europe fonde l’inscription au registre public, et une banque qui consulte une inscription lit le résultat d’un contrôle tiers, non la seule parole du fournisseur.
Ce que le code exige du fournisseur
Le code fixe des exigences d’application de l’article 28 du RGPD et des articles connexes: devoirs du sous-traitant concernant les instructions, sous-traitants ultérieurs, sécurité des traitements, assistance aux droits des personnes, notification des violations, audit et suppression ou restitution en fin de contrat. EU Cloud Code of Conduct couvre toutes les couches de services cloud, donc infrastructure, plateforme et logiciels, avec les mêmes exigences appliquées aux fonctions réelles de chaque couche.
Deux points comptent pour une banque qui examine les détails. Le code exige que le fournisseur indique les pays de traitement, donnant à la banque une base documentée pour analyser les transferts. Il exige aussi que le fournisseur précise les conditions de divulgation des données à une autorité publique, question qu’une clause de résidence seule laisse ouverte. La page sur le cloud souverain bancaire explique comment lire ces éléments au regard du CLOUD Act.
Niveaux d’adhésion et vérification du registre
L’adhésion est déclarée par service, donc un fournisseur peut avoir des inscriptions pour certains services et aucune pour d’autres. La déclaration nomme le service, la version du code utilisée pour l’évaluer et les pays de traitement, et l’organisme de contrôle tient le registre public où l’acheteur la vérifie. Le code définit trois niveaux de conformité, dont la distinction est souvent mal comprise: tous exigent le respect intégral de chaque exigence, et seul le type de preuves soumises à l’organisme de contrôle diffère. Un niveau supérieur signifie donc une documentation renforcée de la même conformité, sans norme plus stricte. SCOPE Europe réalise une évaluation initiale et des réévaluations annuelles, et peut ouvrir une autre évaluation après une plainte, un article de presse, une évolution législative ou de nouvelles orientations d’une autorité de protection des données.
La procédure pratique pour une banque reste courte à suivre. Relevez le nom exact du service au contrat, cherchez-le au registre, ne considérez pas un logo commercial comme preuve, vérifiez l’actualité de l’inscription et confrontez les pays de traitement à votre documentation des transferts. Une inscription pour un autre service du même fournisseur ne prouve rien sur celui acheté.
Ce que l’adhésion ne remplace pas
L’adhésion prouve la conformité RGPD du sous-traitant pour un service nommé. Elle ne prouve pas la résilience opérationnelle, ne fournit pas les clauses contractuelles exigées par DORA pour les accords avec des prestataires TIC et ne réalise pas l’analyse d’impact des transferts due lorsque les données ou leur accès sortent de l’UE. Une banque remplaçant sa documentation DORA par une inscription laisse une lacune que le superviseur trouvera au registre d’informations, traité dans la page DORA en Allemagne.
L’adhésion ne dit rien non plus des obligations de sortie du fournisseur ou de la capacité de la banque à déplacer la charge de travail. Ces éléments relèvent du contrat, et la page sur la résilience opérationnelle numérique en Europe détaille les attentes réglementaires correspondantes.
L’autre code au nom similaire
European Code of Conduct for Data Centre Energy Efficiency est un instrument distinct. Ce dispositif volontaire coordonné par le Centre commun de recherche de la Commission traite de l’électricité et du refroidissement des centres de données, sans lien avec le RGPD ou les obligations des sous-traitants. La participation d’un centre de données n’apporte absolument rien à la question de protection des données. La page sur les centres de données financiers à Francfort traite des règles énergétiques et de refroidissement d’un site allemand.
EU Cloud Code of Conduct est-il une certification?
Non, la distinction entre ces deux instruments est de nature juridique. Un code de conduite selon l’article 40 du RGPD et une certification selon l’article 42 sont deux instruments distincts, avec leurs propres procédures d’approbation. Le code repose sur une déclaration d’adhésion vérifiée par un organisme de contrôle, tandis qu’une certification est délivrée par un organisme certificateur agréé selon des critères approuvés. Les fournisseurs présentent parfois leur adhésion comme une certification dans leurs supports commerciaux; l’acheteur devrait citer l’inscription au registre.
L’adhésion prouve-t-elle l’adéquation à une banque?
L’adhésion à EU Cloud Code of Conduct prouve un volet de l’adéquation du fournisseur. L’évaluation bancaire doit couvrir le risque TIC, la concentration, les tests de résilience, les droits d’audit, la sous-traitance en chaîne, la sortie et les déclarations prudentielles, en plus de la protection des données. L’adhésion règle cette dernière question pour le service nommé et laisse le reste au contrat et à l’évaluation de la banque. Son usage utile est celui d’un élément documenté, cité par son inscription au registre, dans un dossier plus large.
Transferts internationaux: le module après Schrems II
Cette lacune importe surtout aux banques ayant un fournisseur hors UE. Le code approuvé en 2021 n’est pas une garantie de transfert selon l’article 46 du RGPD, donc l’adhésion seule ne légitime pas un transfert vers un pays tiers. Après l’arrêt Schrems II, un module distinct pour ces transferts a été engagé, et une banque comptant dessus doit vérifier son statut avant de s’y fier.
Tant que ce module n’est pas en vigueur, un transfert exige sa propre base juridique et son analyse d’impact, avec clauses contractuelles types et mesures supplémentaires lorsqu’elles s’appliquent. Il faut lire l’inscription comme une preuve sur le traitement, en examinant séparément les transferts, distinction également faite par la page cloud souverain entre résidence et juridiction.
Valeur de l’adhésion en cas de problème
L’article 83(2)(j) du RGPD oblige l’autorité de contrôle à tenir compte de l’adhésion à un code approuvé lorsqu’elle fixe une amende administrative, et le Comité européen de la protection des données indique qu’elle peut être un facteur atténuant. Cette adhésion ne modifie pas les paliers d’amende et ne constitue pas une défense, donc une banque ne devrait pas la présenter ainsi.
Elle aide en revanche à constituer le dossier du responsable du traitement. Celui-ci doit montrer qu’il a choisi un sous-traitant offrant des garanties suffisantes, et une inscription évaluée par un organisme agréé documente ce choix, avec plus de valeur à la sélection qu’après un incident.
Origines du code et autre code cloud
Les travaux ont commencé en 2012 dans la stratégie cloud de la Commission européenne, d’abord sous la directive sur la protection des données, et ont été évalués par le groupe de travail Article 29 en janvier 2015. La Commission a transmis le projet au secteur en 2017, quand Alibaba Cloud, Fabasoft, IBM, Oracle, Salesforce et SAP ont créé l’assemblée générale et désigné SCOPE Europe comme organisme de contrôle. L’autorité belge de protection des données a approuvé le code le 20 mai 2021, après un avis positif du Comité européen de la protection des données. Le code est dirigé par une assemblée générale, un comité directeur et un secrétariat, avec cinq sections: champ d’application, protection des données, exigences de sécurité, contrôle et conformité, et gouvernance interne.
Un second code existe pour ce même secteur d’activité cloud. Le CISPE Data Protection Code of Conduct a été approuvé le 3 juin 2021 et constitue un instrument distinct avec son propre organisme de contrôle; un fournisseur peut donc adhérer à l’un, à l’autre ou à aucun. Une banque comparant deux fournisseurs devrait identifier le code de chaque inscription avant de considérer leurs affirmations comme équivalentes.
Conformité cloud et Finance Loop
Finance Loop inscrit la conformité cloud au programme de son parcours Infrastructure numérique & souveraineté, où responsables achats et risques TIC bancaires rencontrent les fournisseurs qu’ils évaluent. Finance Loop organise ces sessions à Francfort, ville réunissant les superviseurs et une grande part de la capacité d’hébergement européenne.
Finance Loop est un réseau professionnel qui favorise l’usage institutionnel des technologies émergentes en finance, comme l’IA, la tokenisation, les stablecoins et la DeFi. Finance Loop aide ses membres à développer leurs compétences et leurs réseaux personnels dans ces domaines: Investissement & actifs numériques, Paiements & monnaie numérique, Infrastructure numérique & souveraineté et Risque & conformité.