Les banques et les évolutions technologiques entretiennent des relations étroites et anciennes. La première vague technologique s’est produite avec l’achèvement du premier câble télégraphique transatlantique en 1866, posant les prémices d’une finance internationale. La seconde vague d’innovations a sans doute été l’apparition, à Londres le 27 juin 1967, du premier guichet automatique bancaire, à l’initiative de la Barclays[1]. Les années 1980 verront l’apparition des microfiches pour la conservation des copies chèques qui donnera lieu à un texte de loi sur les copies fidèles et durables (actuel article 1379 Code civil), mais aussi celle des automates bancaires, lesquels posent les fondements d’une banque sans guichet.
La troisième vague technologique s’est manifestée avec la dépendance accrue des banques aux TIC[2], l’apparition de nouveaux usages[3] et de nouveaux acteurs[4], dont les FinTechs, concurrents des banques. La crise financière de 2008, et la défiance qu’elle a suscitée à l’égard de ces dernières, a joué un rôle de catalyseur de ces dernières évolutions.
Il n’est pas impensable que nous assistions aujourd’hui au déferlement d’une quatrième vague, fruit de circonstances exceptionnelles venant accroître, de manière profonde, l’attrait déjà sensible pour le cloud computing[5]. En effet, l’un des nombreux effets de la crise sanitaire sans précédent que nous traversons est le renforcement d’un phénomène éminemment prégnant, dès avant l’apparition du Covid-19, à savoir une hypersensibilité des activités économiques, notamment bancaires, à des prestataires qui, peu à peu, tendent à devenir des concurrents directs[6].
Dans un rapport du Conseil de stabilité financière du 9 décembre 2019[7], est ainsi soulevée la question de la concurrence exercée par les BigTechs et des impacts sur la viabilité des modèles d’entreprise des opérateurs historiques (p. 23). On remarquera ici que le risque identifié n’est pas tant celui de la concurrence directe exercée par des acteurs ayant comme cœur de métier le domaine bancaire, mais la dépendance à des prestataires techniques devenus indispensables au développement des activités financières.
Ce constat a récemment suscité un important activisme réglementaire laissant envisager, dans les mois qui viennent, un train de mesures conséquent. S’il n’est pas habituel de commenter aussi précocement des réformes, leur enchaînement, l’ampleur des impacts pratiques qu’elles induisent et l’extrême sensibilité de la cybersécurité, nous portent à en tracer les contours à grands traits (I.), avant de relever quelques questions particulièrement sensibles en lien avec le projet de règlement DORA (II.).
I. La cybersécurité : présentation de la foire aux bonnes idées
Sous couvert de renforcer la cyber-résilience, on assiste à une floraison de textes à l’articulation incertaine, prônant peu ou prou les mêmes concepts dont notamment celui de la centralisation des informations et de l’uniformisation des pratiques, la difficulté étant de déterminer l’épicentre de cet ensemble.
Cet activisme réglementaire est à la mesure de ce que représentent les cyber-risques. Ainsi que le souligne le rapport du Comité Européen du risque systémique (CERS) du 19 février 2020 sur le cyber-risque systémique[8], ce dernier se distingue des autres risques par la vitesse et l’ampleur de sa propagation, ainsi que par les intentions très diverses des auteurs, au nombre desquels peuvent se trouver des États[9]. Ce rapport souligne également qu’un cyberincident peut devenir une crise systémique lorsque la confiance dans le système financier s’en trouve érodée (p. 2).
1. Une nouvelle politique européenne de cybersécurité
Le premier « code de bonnes pratiques » abordant la question du numérique en tant qu’élément clé d’un politique d’entreprise date de 1994[10], autant dire la préhistoire. Microsoft, doyenne des GAFAM, avait 19 ans alors qu’Amazon venait seulement d’apparaître, Google ne naissant quant à elle que quatre ans plus tard et Facebook dix ans après. Les réflexions sur ce sujet se sont récemment intensifiées, dans le secteur bancaire en tous les cas, avec l’apparition de craintes liées à une dépendance élevée aux prestations liées aux technologies de l’information et de la communication et sous la pression des attaques aussi diverses que nombreuses visant notamment les banques.
Dans ce contexte tendu, le 16 décembre 2020, la Commission et le Conseil ont conjointement présenté[11] la nouvelle stratégie de cybersécurité centrée sur trois principes, la résilience, la souveraineté technologique et le leadership mondial en matière cybersécurité. Au titre du plan d’action annoncé à cette occasion, sont notamment proposés une révision du EU Cyber Defence Policy Framework du 19 novembre 2018[12] afin de renforcer la coordination entre acteurs européens, mais aussi un renforcement des capacités industrielles et technologiques de l’UE en matière de cybersécurité via des fonds européens. Ce même jour étaient également annoncés deux nouveaux textes.
Tout d’abord, la refonte[13] de la Directive NIS[14], mais également une proposition de directive relative à la résilience des entités critiques (Critical Entities Resilience – CER)[15]. Ces deux projets de directives ayant été précédés du projet de règlement Digital Operational Resilience Act, ci-après DORA.
2. Le Règlement sur la résilience opérationnelle digitale (DORA)…
En prélude à l’annonce d’une nouvelle politique européenne de cybersécurité, avait été publié le projet de règlement DORA[16] du 24 septembre 2020[17]. Ce texte devrait devenir une réalité à l’horizon 2022, à supposer toutefois qu’il traverse rapidement le processus législatif européen et soit adopté sans modifications importantes. Il entrerait alors en vigueur le 21e jour suivant celui de sa publication au Journal officiel de l’Union européenne et devrait, a priori, être applicable 12 mois après la date d’entrée en vigueur, soit un délai extrêmement bref au regard de l’ampleur prévisible des travaux de mise en œuvre[18]. À ce titre, on ne peut que lui souhaiter un meilleur parcours législatif que le projet de règlement « e privacy », censé être adopté mi-2016 et qui est toujours en débats au niveau des trilogues européens.
À la différence des directives NIS II et « Critical Entities Resilience » (CER), le projet de règlement DORA est une norme sectorielle concernant la résilience opérationnelle[19] numérique du secteur financier au sens large du terme[20], la notion d’« entités financières » listées à l’article 2 du Règlement réunissant sous une même dénomination des entités soumises à des degrés de supervision et d’encadrement variables. Le périmètre du texte, pour étendu qu’il soit, soulève néanmoins des questions. Quid des infrastructures de paiement[21] et des futures structures que nécessitera l’émergence des crypto-actifs ? En bonne logique, DORA devrait s’appliquer aux « facilités » sous-jacente aux activités visées à l’article 2.
Les effets de ce dernier se manifesteront principalement dans les cinq domaines suivants. Tout d’abord, la gestion des risques liés aux (TIC), dont la mise en place d’un cadre de gestion des risques informatiques, l’accent étant mis sur une gouvernance placée sous l’égide de l’organe de direction (article 4). Le second est celui de la rationalisation, notamment des notifications d’incidents, lesquelles sont issues de textes divers imposant des délais et des destinataires différents selon les domaines[22] (articles 15 à 20). Le troisième concerne la conduite de programmes complets et « proportionnés » de tests de résilience opérationnelle numérique, conduits à intervalles réguliers, afin de vérifier l’état de préparation aux risques et d’identifier les éventuelles lacunes (article 21 à 24).
Le quatrième domaine concerne la gestion des risques liés aux relations avec les tiers prestataires de services informatiques, notamment en ce qui concerne l’externalisation de fonctions critiques[23]. DORA est, dans ce domaine très prescriptif[24] et exige, à titre d’exemple, une information des autorités compétentes des projets de contrats portant sur des fonctions critiques, à l’imitation de ce que prévoit le nouvel article 232 de l’arrêté contrôle interne pour l’externalisation des prestations essentielles. Par ailleurs, apparaît une une obligation de ne conclure d’accord qu’avec des tiers prestataires de services informatiques qui respectent des normes élevées, adéquates et actualisées en matière de sécurité de l’information (articles 25 à 39). Le dernier domaine est celui du partage d’informations et de renseignements entre établissements s’agissant des menaces et vulnérabilités cyber (article 40). DORA a par ailleurs pour épicentre la prévention des risques liés aux TIC[25], laquelle s’exprime au travers de trois grands thèmes.
2.1. Une supervision renforcée
Le premier de ces thèmes concerne la supervision des tiers « fournisseurs TIC critiques » (Critical Third Party Provider – CTPP)[26], en ce compris les fournisseurs de cloud (Cloud Services Provider – CSP). Cette supervision serait assurée par l’une des trois autorités européennes de surveillance (AES), lesquelles détiendraient divers pouvoirs (article 31), allant de la demande d’informations, au prononcé de sanctions (articles 45 à 48), en passant par des audits sur et hors site. Une astreinte d’un montant de 1 % du chiffre d’affaires mondial quotidien moyen du prestataire au cours de l’exercice précédent pourrait être prononcée en cas de réticences. Cette supervision comprendra la création d’un « comité mixte » agissant au nom des Autorités Européennes de Supervision, comité qui aura notamment la charge de désigner les tiers prestataires critiques de services informatiques (article 28-6), ainsi que l’autorité de supervision habilitée à les contrôler (EBA, l’EIOPA ou ESMA). La seconde instance créée par DORA est le « forum de supervision » qui préparera « les projets de positions communes et d’actes communs du comité mixte » dans le domaine des risques liés aux tiers prestataires de services informatiques dans les différents secteurs financiers (article 29).
La supervision exercée par les AES suscite une interrogation pour des prestataires qui fournissent leurs services, certes dans le domaine financier, mais également dans d’autres secteurs d’activité. Un équilibre devra être trouvé entre le degré d’exigences des AES, leur coût et la capacité à les imposer aux prestataires. Toute cette construction suppose, bien évidemment, que les AES aient les moyens humains et financiers de leurs ambitions et que les prestataires concernés fassent preuve d’une bonne volonté qui sera sans doute indexée sur la réalité des sanctions auxquelles ils s’exposeront. L’exemple du RGPD nous enseigne que si la politique répressive n’a pas nécessairement eu un impact radical sur le comportement des GAFAM[27], du moins ce texte a-t-il fait émerger certains standards comportementaux. Souhaitons que ce même soft power s’exprime également ici.
2.2. Le brouhaha réglementaire de la gestion des cyber-risques
Le second thème pose globalement la question de l’harmonisation des règles de gestion des cyber-risques, en ce compris la déclaration des incidents et leur centralisation. Plus précisément, sera concernée la détermination de normes européennes relatives à des tests de résilience opérationnelle informatique unifiée, en ce compris les tests d’intrusion[28]. La question que pose ce chantier est notamment celle du niveau d’uniformisation, dans la mesure où les références dans ce sujet sont nombreuses. On mentionnera pour mémoire le standard TIBER-EU[29] relatif aux modalités de réalisation des tests de pénétration fondés sur la menace[30]. Ce dernier côtoie des recommandations et standards divers. À titre d’exemple, on citera notamment les travaux du Comité de Bâle « Principles for the sound management of operational risk » (PSMOR) du 6 août 2020[31] dont le principe 7 énonce un certain nombre de recommandations afin que les banques garantissent des TIC résilientes, y compris dans le domaine de la cybersécurité[32]. Le Financial Stability Board s’est également exprimé au travers d’un discussion paper intitulé « Regulatory and supervisory Issues Relating to Outsourcing and Third-Party Relationships » du 9 novembre 2020[33].
Enfin, pour mémoire, viennent d’être mises en œuvre deux orientations de l’ABE sur l’externalisation[34] et sur le management du risque et de la sécurité des TIC[35] à propos desquels il est sans doute prématuré de dresser un bilan définitif. Une pause réglementaire dans ce domaine serait d’autant plus nécessaire que DORA ne manquera pas de susciter, à son tour, son lot de normes techniques diverses[36], accroissant ainsi le volume d’un indigeste millefeuille normatif. Il est temps que la connaissance des règles, dans ce domaine au moins, cesse d’être un jeu de pistes favorisant les interprétations et le morcellement des pratiques. Le recours à un règlement devrait être une garantie à ce sujet, sous réserve d’un recours modéré aux « discrétions nationales ».
2.3. Le contrôle exercé sur les prestataires
Le troisième thème a pour objet l’encadrement des relations avec les prestataires de services. À ce titre, sont évoquées des clauses contractuelles types avec les prestataires de cloud[37] et la responsabilité dans le suivi de la relation avec ces derniers. S’inscrivant dans la droite ligne de la construction réalisée par le RGPD via son article 28 imposant le contenu minimum des clauses devant figurer dans les contrats avec les sous-traitants de traitement de données personnelles, cette question est indissociable de celle de la dépendance accrue du secteur bancaire aux services fournis par une poignée de grands prestataires en position dominante dans leur domaine d’activité. Un groupe d’experts, le ROFIEG, dans un rapport de décembre 2019[38], a résumé la relation entre les prestataires de cloud et leurs clients en soulignant deux phénomènes.
D’une part, la structure oligopolistique du marché du cloud, dominé « par une poignée d’acteurs »[39] entraînant une « profonde interconnexion entre une poignée de fournisseurs de services essentiels et l’ensemble du système financier » pouvant créer « des points de défaillance uniques ». D’autre part, cette structure oligopolistique du marché se double d’une dépendance technologique vis-à-vis de prestataires de services pouvant inverser la relation de pouvoir traditionnelle entre le donneur d’ordre et son prestataire, lequel est un acteur hors du périmètre de la réglementation financière.
Dans un rapport annuel sur les résultats du questionnaire sur les risques informatiques du SREP (Supervisory Review and Evaluation Process) du 24 juillet 2020, la BCE souligne cette dépendance au travers de chiffres dont notamment le fait que près de 50 % des institutions ont déclaré avoir dépensé au moins la moitié de la valeur totale de leur contrat d’externalisation informatique pour un seul fournisseur externe. Dans de telles conditions, vouloir rééquilibrer des relations contractuelles s’inscrivant dans un contexte de forte asymétrie économique et technologique, avec des prestataires devenant peu à peu des concurrents, notamment dans le domaine des paiements, semble être une nécessité. Pour autant, il convient d’être prudent dans les solutions, le rééquilibrage attendu ne pourra être le seul fruit d’une accentuation de la pression règlementaire sur les clients de ces prestataires.
3. …accompagné de la proposition de la directive NIS II…
En 2013, la cybersécurité a été prise en compte au niveau européen avec un projet de directive[40] devenu la directive 2016/1148 concernant des mesures destinées à assurer un niveau élevé commun de sécurité des réseaux et des systèmes d’information dans l’Union (directive SRI ou directive NIS - Network Information Security) adoptée le 6 juillet 2016. Cette directive a été transposée par le titre Ier de la loi 2018-133 du 26 février 2018 portant « diverses dispositions d’adaptation de la législation au droit de l’UE » dans le domaine de la sécurité. L’article 5 de ce texte détermine notamment ce que sont les opérateurs de services essentiels (OSE) au fonctionnement de la société ou de l’économie, « et dont la continuité pourraient être gravement affectée par des incidents touchant les réseaux et systèmes d’information nécessaires à la fourniture desdits services ».
Pour mémoire, un rapport de la Commission d’octobre 2019[41] alertait sur le manque de cohérence dans la définition des critères, des seuils et du choix des OSE dans les différents États membres, était notamment souligné qu’en moyenne, entre 20 et 10 897 acteurs avaient été désignés OSE dans les différents États membres.
NIS II a pour objet de refondre leur dispositif d’origine, d’application trop hétérogène. Tout d’abord, le champ d’application de la directive serait étendu par ajout de nouveaux secteurs, les États pouvant identifier des entités de petites tailles, mais présentant un risque élevé en matière de cybersécurité. Disparaîtrait la distinction entre les opérateurs de services essentiels (OSE) et les fournisseurs de services numériques (FSN), les entités seraient désormais classées dans des catégories selon leur importance et soumises à des régimes différents. Émergeraient ainsi les « entités essentielles » énumérées à l’annexe I (dix catégories dont les banques et les infrastructures des marchés financiers) et les « entités importantes » objets d’une annexe II regroupant six catégories d’activités.
Par ailleurs, NIS II renforcerait les exigences de sécurité imposées aux entreprises, notamment dans le traitement de la sécurité des chaînes d’approvisionnement et des relations avec les fournisseurs, et rationalisationnerait les obligations de déclaration. Enfin, seraient introduites des mesures de surveillance plus strictes pour les autorités nationales et une harmonisation des régimes de sanctions entre États membres.
La question qui se pose est bien entendu celle de l’articulation de NIS II et DORA, les deux textes s’intéressant au domaine bancaire. Le projet de règlement DORA, en tant que « lex specialis » dédié au secteur bancaire, devrait être le texte de référence dans ce domaine, remplaçant ainsi les règles nationales transposant la directive NIS. Toutefois, compte tenu de potentiels conflits de lois positifs, une harmonisation semble nécessaire. On imagine difficilement que dans des domaines aussi sensibles que la gestion des risques, ou bien encore la notification des incidents, il puisse y avoir, pour un même secteur d’activité, des injonctions divergentes. La doctrine du « same risk, same rules » devrait conduire à l’émergence de standards homogènes sur l’ensemble du territoire européen, uniformément applicables à tous les acteurs dans un même secteur d’activité, mais aussi à tous les secteurs de l’écosystème concerné par ces nouveaux textes.
En l’état, on mentionnera, à titre d’exemple, deux points de frottements potentiels avec DORA. Le considérant 86 de NIS II mentionne un « point d’entrée unique » pour les notifications pour toutes les notifications requises « en vertu de la présente directive ainsi que d’autres textes législatifs de l’Union », y compris par voie de conséquence le RGPD. Or, l’article 15 de DORA veut établir un processus de gestion des incidents liés aux TIC afin de détecter, gérer et assurer leur notification. Souhaitons que les deux volontés se rejoignent sans s’additionner.
Le considérant 46 de NIS II souhaite, afin de mieux traiter les principaux risques de la chaîne d’approvisionnement et aider les entités à gérer de manière appropriée les risques de cybersécurité, qu’un groupe de coopération, auquel participent les autorités nationales compétentes, en lien avec la Commission et l’ENISA, procèdent à des « évaluations sectorielles coordonnées des risques de la chaîne d’approvisionnement ». Comment ces évaluations sectorielles pourraient, dans le domaine financier, se mettre en place en marge de la gouvernance évoquée par DORA[42] ?
Comme souvent dans de telles matières, il est piquant de constater que DORA et NIS II, sous couvert de convergence, encouragent in fine une fragmentation des dispositifs de prévention et de traitement des cyber-risques. Cette harmonisation sera sans doute l’un des thèmes importants de la suite des travaux législatifs.
Pour faire bonne mesure, il convient de souligner un point de contact avec la loi de programmation militaire. L’article 2 dernier, paragraphe de NIS II, exige que les États membres établissent une liste des entités identifiées sensibles et la communique à la Commission européenne. Quand bien même admettrait-on que DORA soit « le texte leader » pour le secteur financier, il n’en demeurerait pas moins une question de coordination avec la législation française. Pour mémoire, la loi relative à la programmation militaire pour les années 2014 à 2019[43] a introduit un mécanisme de préservation des intérêts vitaux de la nation mettant en relief la protection des activités d’importance vitale et de ceux qui s’y livrent, les opérateurs d’importance vitale (OIV). Les activités d’importance vitale pour la Nation sont réparties en 12 secteurs (finances, transports, énergie, santé, recherche, etc.).
Se pose la question de l’articulation de tout ceci avec le dispositif français. L’article 6.1 de NIS I[44] était de ce point de vue clair et préservait les règles nationales. Le considérant 6 de NIS II semble aller dans le même sens : « La présente directive n’affecte pas la capacité des États membres à prendre les mesures nécessaires pour assurer la protection des intérêts essentiels de leur sécurité, pour préserver l’ordre et la sécurité publics et pour permettre l’enquête, la détection et la poursuite des infractions pénales », tout en précisant néanmoins « dans le respect du droit de l’Union. »
Enfin, les sanctions prévues par NIS II (article 31) sont aggravées, les États membres veillant à ce que les infractions aux obligations prévues à l’article 18 ou à l’article 20[45] soient passibles d’amendes administratives de montant substantiel[46], l’article 32 prévoyant l’articulation de ces sanctions avec celles prononcées au titre du RGPD dans le cas de violations de données à caractère personnel.
4. …et de la proposition de directive Critical Entities Resilience (CER)
Ce projet tend à réviser la Directive 2008/114 du 8 décembre 2008 sur les infrastructures critiques européennes (ICE)[47] et prend en compte l’interconnexion croissante entre les infrastructures, les réseaux et les opérateurs de services essentiels et adopte une approche consistant « à ne plus protéger des actifs spécifiques mais à renforcer la résilience des entités critiques qui les exploitent »[48].
Par ailleurs, ce projet devrait favoriser une convergence de vues avec le projet NIS 2. Les autorités compétentes désignées en vertu de la directive CER et celles désignées en vertu de la proposition de directive NIS 2 devraient ainsi prendre des mesures complémentaires et échanger des informations concernant la résilience (cyber ou non), et veiller à ce que les entités particulièrement critiques dans des secteurs considérés comme « essentiels » par NIS 2 soient soumises à des obligations plus générales de renforcement de la résilience en général.
Cette directive CER étendrait le champ d’application de la directive ICE. Dix secteurs seraient couverts (dont les services bancaires et les marchés financiers). Les États devraient en outre identifier les entités critiques, au travers de critères communs sur la base d’une évaluation nationale des risques et adopter une stratégie nationale pour garantir la résilience de ces entités critiques et procéder régulièrement à des évaluations des risques (articles 3 à 9). Il n’est pas évident que cela soit suffisant pour assurer une totale uniformité des pratiques au niveau européen.
Ce texte prévoit un recensement d’un sous-ensemble plus restreint d’entités critiques qui seraient soumises à des obligations destinées à renforcer leur résilience face aux risques non liés aux cyberespaces, y compris l’adoption de mesures techniques et organisationnelles et la notification des incidents. La cohérence dans l’identification des entités critiques au travers de NIS 2 et ICE 2 est visée à l’article 5, lequel prévoit que les autorités compétentes chargées de la mise en œuvre de la directive ICE 2 notifient aux autorités compétentes chargées de la mise en œuvre de la directive NIS 2 l’identification des entités critiques.
S’agissant de la France, ceci devrait préserver la désignation des opérateurs d’importance vitale au travers de la loi de programmation militaire évoquée ci-dessus, question qui semble réglée, en apparence, dans le projet de Règlement DORA[49].
À cet égard, l’article 1-2 du projet de directive CER dispose qu’il ne s’appliquerait pas aux domaines couverts par NIS 2, dont notamment le secteur bancaire et financier[50]. Toutefois, l’article 7 précise que, s’agissant des banques et des infrastructures de marchés et informatiques, les États membres, au plus tard trois ans et trois mois après l’entrée en vigueur de la directive, devront désigner les entités considérées comme critiques. Des dispositions sectorielles du droit de l’Union devront exiger que ces entités critiques adoptent des mesures au moins équivalentes aux obligations prévues dans la directive CER. Encore une fois, une question d’articulation se pose avec acuité. Si la cohérence de ces projets de directives semble, sous bénéfice d’un inventaire ultérieur, assurée, quid s’agissant de l’articulation avec DORA, texte à périmètre particulier ? Notamment, l’article 6 du projet de directive CER habilite également la Commission, après consultation du groupe « Résilience des entités critiques », à adopter les lignes directrices pertinentes. Une coordination dans l’édiction de ces lignes directrices et celles issues de DORA est une nécessité.
À cet égard, nous nous attarderons sur quelques questions soulevées par ce dernier texte.
II. Quelques questions sensibles en relation avec DORA
1. La résilience opérationnelle
Sous un angle réglementaire, la notion de cyber-résilience donne lieu à des définitions diverses. Le 10 avril 2019, le « joint commitee » réunissant les Autorités Européennes de Surveillance, dans un avis commun[51], aborde la notion de résilience opérationnelle en tant qu’exigence relative à la gouvernance. Au travers de ce concept, sont notamment évoquées l’interconnectivité, l’interdépendance et la dépendance à l’égard de la technologie dans le secteur financier.
En décembre 2019, le Conseil de stabilité financière définissait la cyber-résilience[52] comme la capacité d’une organisation à continuer de remplir sa mission en anticipant et en s’adaptant aux cybermenaces et aux autres changements de l’environnement et en résistant, en contenant et en se remettant rapidement des cyberincidents. Quelques mois plus tard, en août 2020, le Comité de Bâle donnait à son tour une définition[53], tandis que l’article 3 du Règlement DORA évoque également la « résilience opérationnelle numérique »[54]. Ce sujet de la résilience numérique est par ailleurs inscrit au programme de travail 2021 de l’EBA[55]. Une fois de plus, ce fourmillement réglementaire est source d’insécurité et n’est pas compatible avec la mise en place des politiques et procédures attendues des établissements.
2. Quel régime pour les prestataires internes ?
L’une des questions sensibles est le périmètre des exigences que porte DORA en matière de surveillance et de supervisions des prestataires. Faute de précision dans le texte des articles 3.15[56] et 28[57] du projet de règlement, aucune distinction n’est faite entre les « tiers prestataires de services informatiques », que ces derniers soient ou non des prestataires internes à l’entité, telle que notamment une filiale dédiée. Cette absence de distinction est conforme à la position adoptée par l’EBA dans ses orientations sur la gestion des risques liés aux TIC et à la sécurité[58].
Ces dernières visent en effet (§ 8) les « fournisseurs » sans plus de précision, tandis qu’elles évoquent les « prestataires de services d’externalisation, entités du groupe ou fournisseurs tiers ». On peut toutefois s’interroger sur la mesure dans laquelle s’appliquera le principe de proportionnalité visé à l’article 25-2 de DORA, lequel doit permettre une modulation des exigences en fonction de la taille et de la nature des activités de l’entreprise considérée.
Dans cette perspective, l’intensité du contrôle exercé sur un prestataire interne, mais aussi celui de la supervision applicable, devrait tenir compte de divers paramètres tels que, le niveau d’encadrement réglementaire applicable, tant au prestataire lui-même, qu’à l’entité à laquelle il est rattaché. De même, devraient être pris en compte l’ampleur, la complexité et l’importance des relations de dépendance, mais aussi les risques induits par l’utilisation des services objets de la prestation. Cette approche par les risques devrait pouvoir aboutir, si ce n’est à une exclusion de ces prestataires intra groupe du dispositif DORA, du moins à une modulation des exigences de ce texte.
3. Le contrat est-il un accessoire de la politique de gestion des risques ?
3.1. L’ostracisme contractuel
On s’attardera tout d’abord sur le contenu de l’article 28-9 de DORA, lequel dispose : « Les entités financières ne font pas appel à un tiers prestataire de services informatiques établi dans un pays tiers qui serait désigné comme critique en vertu du paragraphe 1, point a)[59], s’il était établi dans l’Union. » Deux remarques s’imposent. En l’état, ce texte semble instaurer un pilotage des relations contractuelles indexé sur l’origine géographique des prestataires. Une telle entrave à l’accès à un marché pose sans doute des questions, en termes de concurrence notamment. Par ailleurs, n’est-il pas irréaliste de vouloir « boycotter » des prestataires critiques en raison de leur appartenance à une aire géographique lorsque, par exemple, les principaux prestataires de cloud sont américains ?
On s’interrogera sur les raisons du recours à la notion « d’établissement » laquelle, outre le fait qu’elle est beaucoup trop vague, traduit par ailleurs un attachement anachronique à une « territorialisation » des data. L’idée sous-jacente est-elle que la situation géographique est un antidote à l’emprise extraterritoriale de certains textes, dont notamment le Clarifying Lawful Overseas Use of Data Act (CLOUD Act) ? Ce serait oublier que cette logique se heurte, notamment, à la doctrine du gouvernement américain qui s’attache à l’accessibilité des données depuis les États-Unis. Au cours de la procédure opposant Microsoft à l’État américain, laquelle devait conduire au CLOUD Act, ce dernier a souligné : « Microsoft’s U.S. based employees could make that disclosure without leaving their desks[60]. »
3.2. Une inutile fragilisation du lien contractuel ?
Une autre disposition laisse songeur, celle relative à la stratégie de sortie d’un contrat de sous-traitance. En effet, l’article 25-9 prévoit la prise en compte de « toute perturbation [sic] de l’activité due à une fourniture inappropriée ou défaillante de services ou un risque matériel » le tout sans « porter atteinte à la continuité et à la qualité de leur prestation de services aux clients ». À cette vision radicale évoquant la remise en cause d’un contrat en raison de « toute perturbation », on préférera l’approche plus mesurée des orientations de l’EBA sur l’externalisation[61]. Certes l’instrumentalisation des relations contractuelles n’est pas une nouveauté, mais du moins avait-elle jusqu’ici pour objet la préservation de cette relation.
Ainsi, pour le Single Resolution Board[62] : « les prestataires de services ne peuvent pas résilier, suspendre ou modifier les conditions de prestation de services pour des raisons de résolution/restructuration, à condition que les obligations substantielles du contrat continuent à être exécutées ». De même, l’article L.613-50-4 du CMF [63] précise-t-il que la mise en œuvre d’une mesure de résolution de l’établissement ne peut pas être à elle seule une cause de résiliation, suspension, modification ou compensation d’un contrat si les « obligations essentielles » de ce contrat continuent à être exécutées par l’établissement visé par la mesure (notamment les obligations de paiement, de livraison, et la fourniture d’une garantie).
3.3. La sous-traitance vers des prestataires étrangers : quelle évaluation des prestataires ?
Avant de conclure un contrat avec un sous-traitant, l’article 26 de DORA prévoit une évaluation des avantages et risques dans le cas d’un sous-traitant établi dans un pays tiers. Dans un tel cas de figure, doivent notamment être pris en compte, le respect de la protection des données et l’application effective de la loi. On ne reprendra pas ici les débats qui ont fait suite à l’invalidation du Privacy Shield par l’arrêt de la CJUE Schrems II[64] et la litanie des questions que posent désormais les transferts de données vers les États-Unis. S’il n’est pas question de faire peser un quelconque risque sur la protection des données, un rappel de la nécessité d’une approche par les risques semble nécessaire (de quels types de données personnelles parle-t-on, de quel type de protection…).
Quant à la question de l’application « effective » de la loi, cette formulation soulève un certain nombre de questions, dont notamment les modalités de contrôle d’un tel respect. On soulignera que les orientations de l’ABE du 25 février 2019 relatives à l’externalisation prévoient à ce sujet, au § 79, une obligation d’obtention d’engagements écrits du sous-traitant de se conformer « à toutes les lois, exigences réglementaires et obligations contractuelles applicables ». On peut estimer qu’une déclaration de ce type est de faible portée, tout comme on peut estimer également que l’exigence d’un audit de conformité réglementaire par les clients de prestataires tels que les GAFAM est, dans la pratique, « hors sol ». Une telle exigence fait écho aux « recommandations » du CEPD relatives à l’invalidation du Privacy Shield[65] et au fait qu’il incombe au responsable de traitement et au sous-traitant d’évaluer si le niveau de protection requis par le droit communautaire est respecté dans le pays tiers concerné.
4. La formation de la direction générale : une nouvelle marotte réglementaire ?
L’article 4-4 du projet de règlement DORA dispose que « Les membres de l’organe de direction suivent régulièrement une formation spécifique afin d’acquérir et de maintenir à jour des connaissances et des compétences suffisantes pour comprendre et évaluer les risques informatiques et leur incidence sur les opérations de l’entité financière ». Cette demande est récurrente. Ainsi les orientations de l’ABE sur l’octroi et le suivi des prêts du 29 mai 2020[66] prévoient que le « management body[67] » doit avoir une compréhension suffisante de l’utilisation de l’innovation technologique, de ses limites et de son impact sur les procédures d’octroi de crédits.
La BCE, dans son rapport annuel sur les résultats du questionnaire sur les risques informatiques du SREP[68], aborde également la question de l’adéquation collective des conseils d’administration en ce qui concerne leur expertise informatique. Ce sujet apparaissant également dans le domaine de l’assurance[69]. Il conviendra donc que les établissements mettent en place un programme de sensibilisation ad hoc adapté aux réalités opérationnelles.
Il serait irréaliste de vouloir conclure face à un tel chantier législatif. Du moins peut-on en tirer trois constats. D’une part, celui d’une prise de conscience qui peut paraître, du moins à ce stade, brouillonne, mais qui est bien réelle et tente de prendre en considération les différentes dimensions du cyber-risque par rapport aux autres risques opérationnels. Attention toutefois à l’indigestion normative des destinataires de ces mesures.
Le second constat est, qu’en l’état, il n’est pas certain que ces mesures, dont notamment le projet de règlement DORA, apprécient de manière exacte toutes les conséquences de l’asymétrie flagrante qui règne dans les relations entre les établissements et certains de leurs grands prestataires. Étrange calcul que de penser qu’il soit suffisant d’alourdir les sujétions, en termes d’obligations de surveillance pesant sur les donneurs d’ordre, pour qu’aussitôt s’efface une réalité économique souvent bien peu compatible avec l’accomplissement de telles obligations. On peut douter que cette instrumentalisation du lien contractuel soit opérante.
[1] . Le premier retrait a été fait pour un montant de 10 livres sterling. Le brevet de la carte a carte à puce est quant à lui déposé le 25 mars 1974.
[2] . Technologies de l’Information de la Communication.
[3] . Exposant les banques à de nouvelles dépendances. La fourniture de services financiers sur smartphones suscite une dépendance technologique vis-à-vis des systèmes d’exploitation iOS et Android, tout comme les chatbots bancaires dépendent assez largement de messageries exploitées par un petit nombre de grandes entreprises de technologie (bigtech).
[4] . Dont l’apparition des néo-banques, toujours en recherche de rentabilité.
[5] . « Mode de traitement des données d’un client, dont l’exploitation s’effectue par l’internet , sous la forme de services fournis par un prestataire – Note : Linformatique en nuage est une forme particulière de gérance de l’informatique, dans laquelle l’emplacement et le fonctionnement du nuage ne sont pas portés à la connaissance des clients » : « Vocabulaire de l’informatique et de l’internet », JO n° 0129 du 6 juin 2010, p. 10453. Pour une approche plus technique : norme UIT Y. 3500 : « modèle permettant d’offrir un accès via le réseau à un ensemble modulable et élastique de ressources physiques ou virtuelles mutualisables, approvisionnées et administrées à la demande et en libre-service ».
[6] . Dans le domaine des paiements, cf. le registre de l’ABE contenant des informations sur les établissements de paiement et de monnaie électronique agréés ou enregistrés dans l’UE et les pays de l’EEE : https://www.eba.europa.eu/risk-analysis-and-data/register-payment-electronic-money-institutions-under-PSD2.
[7] . BigTech in finance - Market developments and potential financial stability implications.
[8] . « Systemic cyber risk », février 2020 accessible sur le site de l’ESRB (Europan Systemic Risk Board).
[9] . Cf § 3.1 Conceptual systemic cyber risk model.
[10] . Rapport sud-africain, King Report on Corporate Governance.
[11] . JOIN (2020) 18 final.
[12] . https://data.consilium.europa.eu/doc/document/ST-14413-2018-INIT/en/pdf.
[13] . COM(2020) 823 final accompagné de ses annexes I à III.
[14] . Directive 2016/1148 « Network and Information System Security » (NIS) du 6 juillet 2016 ayant pour principale objectif d’assurer un niveau de sécurité élevé et commun pour les réseaux et les systèmes d’information de l’Union européenne. Texte transposée en France par la loi n° 2018-133 du 26 février 2018 portant diverses dispositions d’adaptation au droit de l’Union européenne dans le domaine de la sécurité, et publié au JORF du 27 février 2018.
[15] . Critical Entities Resilience - 2020/0365 (COD).
[16] . Digital Operational Resilience Act - Règlement sur la résilience opérationnelle numérique du secteur financier.
[17] . COM(2020) 595 final.
[18] . Ce délai est actuellement objets de débats au niveau européen. Les articles 23 sur la mise en place et conduite de tests de résilience opérationnelle numérique et 24 relatifs aux exigences à l’égard des testeurs seront applicables 36 mois après la date d’entrée en vigueur.
[19] . Nous verrons ci-après les définitions de cette notion.
[20] . Etablissements de crédit, entreprises d’investissement, établissements de paiement, de monnaie électronique, prestataires de services sur actifs numériques, sociétés de gestion, entreprises d’assurance et de réassurance, etc.
[21] . Sont notamment visés les dépositaires centraux, les plateformes de négociations, référentiels de titrisations, mais pas les infrastructures de paiement STET, GIE CB...
[22] . Le considérant 55 vise une déclaration initiale dans les 24 heures. Pour DORA (art. 17 à 20) une première notification, sans délai, au plus tard à la fin du jour ouvrable, v/s art. 33-1 du RGPD : notification « dans les meilleurs délais » et, si possible, 72 heures au plus tard après la prise de connaissance de l’évènement. Art. 96-1 DSP II : « sans retard injustifié ».
[23] . Cf. notamment les orientations de l’ABE du 25 février 2019 relatives à l’externalisation (EBA/GL/2019/02) et les lignes directrices de l’ESMA du 18 décembre 2020, relatives à l’externalisation vers des prestataires de services de cloud (ESMA50-157-2403).
[24] . Cf. infra, « 3. Le contrat est-il un accessoire de la politique de gestion des risques ? ».
[25] . Article 3-4 du Règlement DORA : « “risque informatique” : toute circonstance raisonnablement identifiable liée à l’utilisation des réseaux et des systèmes d’information, – y compris un dysfonctionnement, un dépassement de capacité, une défaillance, une perturbation, une altération, une mauvaise utilisation, une perte ou tout autre type d’événement, malveillant ou non – qui, si elle se concrétise, peut compromettre la sécurité des réseaux et des systèmes d’information, de tout outil ou processus dépendant de la technologie, du fonctionnement et de l’exécution des processus ou de la fourniture de services, compromettant ainsi l’intégrité ou la disponibilité des données, des logiciels ou de tout autre composante des services et infrastructures informatiques, ou entraînant une violation de la confidentialité, un dommage à l’infrastructure informatique physique ou d’autres effets préjudiciables. »
[26] . Articles 3-18 et 28 du Règlement DORA : Désignent les fournisseurs de services TIC tiers qui sont essentiels pour les entités financières (impact systémique sur la stabilité, la continuité ou la qualité de la fourniture de services financiers si défaillance, le caractère ou l’importance systémique des entités financières qui dépendent du fournisseur, la dépendance, la substituabilité, l’absence d’alternatives réelles, même partielles, en raison du nombre limité de fournisseurs, les difficultés de migration partielle ou totale…).
[27] . Google, Amazon, Facebook, Apple et Microsoft.
[28] . TLPT ou « threat-led penetration testing ».
[29] . The European framework for threat intelligence-based ethical red-teaming : https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
[30] . Cf. DORA article 24 « Exigences applicables aux testeurs ».
[31] . https://www.bis.org/bcbs/publ/d508.htm.
[32] . Programmes de protection, de détection, d’intervention et de rétablissement régulièrement testés, intégrant une connaissance appropriée de la situation, une transmission des informations pertinentes aux utilisateurs en temps utile.
[33] . https://www.fsb.org/2020/11/fsb-consults-on-regulatory-and-supervisory-issues-relating-to-outsourcing-and-third-party-relationships/.
[34] . EBA/GL/2019/02 du 25 février 2019 « entrées en vigueur » le 30 septembre 2019.
[35] . EBA/GL/2019/04 « entrées en vigueur » le 30 juin 2020.
[36] . Sont attendues une dizaine de normes techniques réglementaires, deux normes techniques d’application, et un nombre indéterminé de lignes directrices et rapports récurrents.
[37] . Dans le prolongement des orientations de l’EBA 2019/02 sur l’outsourcing. Cf. sur ce sujet, hors-série banque et droit février 2020 sur le cloud computing, p. 17. S. Lambert, « La mutation de l’appréhension réglementaire du cloud utilisé dans le secteur bancaire français : du cadre de l’externalisation vers une surveillance directe dans l’Union ? ».
[38] . Expert Group on Regulatory Obstacles to Financial Innovation (ROFIEG) : 30 recommendations on regulation, innovation and finance (spéc. p. 11, Recommendation 5 – Outsourcing guidelines and certification/licensing) : https://ec.europa.eu/info/sites/info/files/business_economy_euro/banking_and_finance/documents/191113-report-expert-group-regulatory-obstacles-financial-innovation_en.pdf.
[39] . Cf. Joint Advice of the European Supervisory Authorities to the European Commission on the need for legislative improvements relating to the ICT risk management requirements in the EU financial sector (2019).
[40] . Document COM(2013) 48 final du 7 février 2013.
[41] . Rapport COM(2019) 546 final du 28 octobre 2019.
[42] . Cf. supra, « 2.1. Une supervision renforcée ».
[43] . Loi n° 2013-1168 du 18 décembre 2013 qui s’inscrivait dans la continuité de la directive 2008/114/CE prévoyant un mécanisme d’identification et de désignation des infrastructures critiques européennes (ICE) « dont l’arrêt ou la destruction aurait un impact considérable sur deux Etats membres au moins ». La loi de programmation militaire n° 2018-607 du 13 juillet 2018 relative à la programmation militaire pour les années 2019 à 2025 n’a pas remis en cause ce dispositif.
[44] . « La présente directive est sans préjudice des mesures prises par les États membres pour préserver leurs fonctions étatiques essentielles, en particulier dans le but de préserver la sécurité nationale, notamment les mesures visant à protéger les informations dont la divulgation est considérée par les États membres comme contraire aux intérêts essentiels de leur sécurité, et de maintenir l’ordre public, en particulier pour permettre la détection des infractions pénales ainsi que les enquêtes et les poursuites en la matière. »
[45] . Article 18, « Mesures de gestion des risques en matière de cybersécurité », et article 20, « Obligations en matière de rapports ».
[46] . 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial total de l’entreprise, le chiffre le plus élevé étant retenu.
[47] . Cette directive concernait uniquement les secteurs de l’énergie et des transports.
[48] . Exposé des motifs.
[49] . En ce qui concerne DORA, l’article 1er, paragraphe 3, précise : « Le présent règlement est sans préjudice de toute action visant à sauvegarder les fonctions essentielles de l’État dans les activités concernant la sécurité publique, la défense, la sécurité nationale et les activités de l’État dans les domaines du droit pénal. » Idem, considérant bis : « Le présent règlement devrait être sans préjudice de la possibilité de prendre les mesures nécessaires pour assurer la protection des intérêts essentiels de la sécurité et de la défense nationales, pour sauvegarder l’ordre et la sécurité publics et pour permettre la recherche, la détection et la poursuite d’infractions pénales. »
[50] . En effet, l’annexe de la proposition de directive NIS II (COM(2020) 829 final) ANNEX) vise, au nombre des « Entités essentielles » (annexe I), notamment les établissements de crédit et entreprises d’investissement, les infrastructures de marchés, les infrastructures numérique dont les cloud providers (les activités d’assurance ne sont pas mentionnées).
[51] . Avis à la Commission européenne sur la nécessité d’améliorer la législation relative aux exigences en matière de gestion des risques liés aux TIC dans le secteur financier de l’UE – 10 avril 2019 – ESAs publish Joint Advice on Information and Communication Technology risk management and cybersecurity (europa.eu)
[52] . Guidelines on ICT and Security Risk Management (EBA/GL/2019/04), décembre 2019. Dans le monde de l’assurance, ces dernières ont été reprises, le 12 octobre 2020, par l’EIOPA dans ses lignes directrices sur la sécurité et la gouvernance des technologies de l’information et de la communication : https://www.eiopa.europa.eu/sites/default/files/publications/eiopa_guidelines/eiopa-bos-20-600-guidelines-ict-security-and-governance.pdf.
[53] . Cette résilience étant vue comme la « capacité d’une banque à mener à bien des opérations critiques en cas de perturbation. Cette capacité permet à une banque d’identifier et de se protéger contre les menaces et les défaillances potentielles, réagir et s’adapter, ainsi que se remettre et tirer des enseignements des événements perturbateurs afin de minimiser leur impact sur l’exécution des opérations critiques par la perturbation. Compte tenu de sa résilience opérationnelle, une banque devrait prendre en considération son appétit pour le risque global, la capacité de risque et le profil de risque. » Traduction par l’auteur « risque et le profil de risque ». Traduction par l’auteur, « BCBS consultative Principles for operational resilience », août 2020.
[54] . « Capacité d’une entité financière à développer, garantir et réévaluer son intégrité opérationnelle d’un point de vue technologique en assurant directement, ou indirectement par le recours aux services de tiers prestataires de services informatiques, l’intégralité des capacités liées à l’informatique nécessaires pour garantir la sécurité des réseaux et des systèmes d’information qu’elle utilise, et qui sous-tendent la fourniture continue de services financiers et leur qualité. »
[55] . EBA work programme 2021 – EBA/REP/2020/26, spéc. p. 23.
[56] . Lequel vise notamment la fourniture de services numériques et de données, y compris les fournisseurs de services d’informatique en nuage, de logiciels, de services d’analyse de données, de centres de données, hors les fournisseurs de composants matériels.
[57] . Critères de criticité.
[58] . EBA/GL/2019/04.
[59] . Lequel vise les tiers prestataires de services informatiques qui sont critiques pour les entités financières.
[60] . https://www.wsj.com/articles/supreme-court-to-hear-microsoft-case-on-emails-customer-data-stored-overseas-1519641001
[61] . EBA/GL/2019/02 § 105 : « Les établissements devraient prendre des mesures appropriées s’ils constatent des lacunes dans l’exercice de la fonction externalisée. »
[62] . Expectations for banks 2019 – Single resolutionboard : https://srb.europa.eu/sites/srbsite/files/srb_expectations_for_banks_2019.pdf
[63] . Issu de l’article 68 (3)(a) de BRRD.
[64] . CJUE, Arrêt dans l’affaire C-311/18, Data Protection Commissioner c/ Maximillian Schrems et Facebook Ireland (arrêt Schrems II). E. Jouffin « Le transfert des données vers les États-Unis – La protection de la vie privée est-elle dans une impasse ? », Banque et Droit, hors-série « Cloud computing », février 2021, spéc. p. 26.
[65] . Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data.
[66] . EBA/GL/2020/06.
[67] . Article 3, point 7, de la directive CRD IV : le management body « désigne le ou les organes d’une institution, qui sont nommés conformément au droit national, qui sont habilités à définir la stratégie, les objectifs et l’orientation générale de l’institution, et qui supervisent et contrôlent la prise de décisions de gestion, et comprennent les personnes qui dirigent effectivement les activités de l’institution ».
[68] . https://www.bankingsupervision.europa.eu/ecb/pub/html/ssm.aroutcomesrepitriskquestionnaire202007~9ed9aaa17d.en.html.
[69] . ACPR, Instruction n° 2020-I-09 du 8 juillet 2020.
