Deux personnes se serrant la main au-dessus d’un contrat signé, illustrant la conciliation d’intérêts divergents dans le cadre de Dora.

Contractualiser sous Dora : la conciliation d’intérêts divergents

Article rédigé par Evelina DIMITROVA , avocate et collaboratrice senior au cabinet DLA Piper France LLP

Temps de lecture : 10mn| Numérique

Le règlement Dora, en vigueur depuis le 17 janvier 2025, est encore, voire de plus en plus, à l’origine de discussions entre les entités financières et les prestataires de service impactés directement (les prestataires critiques devraient être désignés dans la 2eme moitié de 2025) et indirectement (via les exigences contractuelles de leurs clients).

De nombreux exercices de remédiation sont encore en cours, sans compter la conclusion croissante de nouveaux contrats portant sur des services informatiques par des entités financières. En effet, rien qu’en 2022, les autorités européennes de surveillance (« AES ») ont identifié 15 000 prestataires informatiques fournissant des services à environ 1600 entités financières dans l’Union[1] ce qui montre l’accroissement de l’utilisation de technologies de l’information et de la communication (« TIC ») par le secteur financier et la conclusion de contrats pour les besoins de ces services.

 

Points clés abordés dans l’article

– Le règlement DORA impose un renforcement des contrats entre entités financières et prestataires informatiques.

– Il vise à accroître la résilience opérationnelle du secteur financier, au-delà des seules exigences de cybersécurité.

– Les exigences contractuelles sont nombreuses : clauses obligatoires sur la localisation des données, la sous-traitance, la réversibilité ou encore les droits d’audit.

– Les entités financières souhaitent imposer leurs modèles contractuels pour garantir leur conformité, tandis que les prestataires TIC cherchent à préserver la cohérence de leurs offres standardisées.

– Les discussions portent aussi sur la conformité à la loi, la supervision de la chaîne de sous-traitance, les droits d’audit et les clauses de résiliation, souvent sources de tensions.

– L’article met en lumière la nécessité d’un équilibre contractuel entre les obligations réglementaires et la réalité opérationnelle des prestataires.

– En conclusion, il souligne l’émergence d’offres spécifiques pour le secteur financier, fondées sur le devoir de conseil, la collaboration et le principe de proportionnalité.

 

Propos introductif – contexte d’adoption du règlement

Contexte réglementaire européen : la Décennie Numérique

Le règlement Dora s’inscrit dans le contexte règlementaire de la décennie numérique de la Commission Européenne (la « Décennie Numérique ») qui vise à favoriser une « transformation numérique sécurisée, sûre, durable et centrée sur les citoyens, conformément aux valeurs fondamentales et aux droits fondamentaux de l’UE[2]. Dans sa proposition initiale, la Commission européenne rappelle le contexte de la crise financière de 2008 et les mesures prises pour renforcer la stabilité du secteur financier, déplorant, néanmoins que ces mesures « ne s’attaquent qu’indirectement aux risques informatiques dans certains domaines, dans le cadre des mesures visant à remédier plus largement aux risques opérationnels[3]. Il est bien sûr fait allusion ici à la règlementation mise en place sur la gouvernance et la gestion des risques financiers mais également aux lignes directrices des AES qui prévoyaient déjà un nombre important d’obligations, notamment de contractualisation[4]

Leçons de la crise financière de 2008 et enjeux de stabilité

Adopté le même jour (14 décembre 2022) que la directive Dora[5], la directive NIS II visant la cybersécurité des entités essentielles ou importantes[6] et la directive relative à la résilience des entités critiques[7], le règlement Dora s’inscrit dans une approche holistique de l’Union européenne en matière de cybersécurité : d’une part, une approche horizontale avec NIS II et, depuis octobre 2024, le Cyber Résilience Act concernant la cybersécurité des produits comportant des éléments numériques et, d’autre part, une régulation sectorielle avec le règlement Dora en ce qui concerne le secteur financier constituant une lex specialis pour ce secteur.

Dora et la régulation sectorielle du secteur financier

À ce sujet, le règlement Dora se démarque par une approche encore plus poussée, au-delà de la cybersécurité, celle de la résilience opérationnelle. Ainsi, bien plus que les lignes directrices existantes, le règlement Dora, complété par le corpus de normes techniques de règlementation (« RTS ») et normes techniques d’exécution (« ITS »), prévoit un cadre règlementaire particulièrement prescriptif dans le but de pousser les entités financières à identifier et parer les risques liés aux TICs.

Intérêts divergents : entités financières vs prestataires TIC

Dans ce contexte, deux intérêts divergents apparaissent. D’une part, les entités financières visées par le règlement sont tenues de renforcer de manière massive non seulement la gouvernance liée aux TICs mais également leurs contrats avec leurs fournisseurs. D’autre part, les prestataires informatiques doivent répondre aux exigences réglementaires et contractuelles de leurs clients et les concilier avec leur modèle de fourniture de services souvent standardisé et la loi qui est applicable à leurs activités.

Alors, sommes-nous face des intérêts irréconciliables ou bien devant une opportunité de nouvelles offres contractuelles adaptées au secteur financier ? Pour répondre à cette question, nous nous pencherons sur les différents points de discussion entre entités financières et prestataires de service TIC.

 

 

Documentation contractuelle servant de base à la discussion : un enjeu habituel pour les contrats informatiques

La documentation à utiliser dans le cadre de la contractualisation d’un service TIC n’est ni une problématique nouvelle ni une question spécifique au règlement Dora. Au contraire, il s’agit d’un débat récurrent dans la négociation de contrats informatiques dans lesquels chaque partie insiste pour utiliser sa propre documentation.

Un règlement prescriptif en matière contractuelle

Avant de se plonger dans le débat relatif à la documentation contractuelle source, il est pertinent de rappeler les exigences contractuelles du règlement Dora.

Dans un premier temps, l’article 30(2) applicable à toute prestation de services TIC liste un certain nombre d’éléments fondamentaux à prévoir dans le contrat tels la description de services et si la sous-traitance de fonctions critiques ou importantes est autorisée, la localisation des services et des données, ou encore sur la réversibilité des données pour ne citer que quelques exemples. Pour la plupart, il s’agit d’éléments de bon sens compris dans tout contrat informatique indépendamment du secteur d’activité concerné. Ainsi, le débat autour de ces points est relativement limité, peu importe la documentation contractuelle utilisée.

Dans un deuxième temps, l’article 30(2) ajoute des exigences contractuelles plus détaillées lorsque les services TIC soutiennent des fonctions critiques ou importantes telles que la participation à des tests de pénétration fondés sur la menace (« TLPT »), les notifications d’évolution de la situation du prestataire ou de larges droits d’audit en faveur du client et son régulateur etc.

Ces exigences sont renforcées par les RTS relatives à la politique de contractualisation de services TIC soutenant des fonctions critiques ou importantes[8] (« RTS sur la Contractualisation ») et les RTS dédiées à la sous-traitance de services qui soutiennent des fonctions critiques ou importantes[9](les « RTS Sous-traitance »). En effet, les RTS sur la contractualisation ajoutent aux dispositions de l’article 30(3), des exigences contractuelles en matière de reporting, absence de conflit d’intérêt, notifications d’incidents, audits indépendants, pour n’en citer que quelques-unes. De leur côté, les RTS sous-traitance (traitées plus bas dans l’article) prévoient, elles aussi, des exigences contractuelles à inclure dans le contrat avec le prestataire principal mais aussi à répercuter dans le contrat de sous-traitance.

Un enjeu d’efficacité des discussions

Les attentes des entités financières face à la documentation contractuelle

La question se pose comme d’habitude : quelle documentation contractuelle est la mieux adaptée afin de répondre aux exigences de Dora ? D’une part, les entités financières, clients du service et directement concernées par Dora, soutiennent souvent que leur documentation est mieux adaptée aux exigences règlementaires et reprend la cartographie des obligations directes et indirectes sur le contrat. Par ailleurs, elle reflète le profil de risque de l’entité financière tel qu’il ressort, notamment de sa politique de gestion des risques liés aux TIC, d’autant plus que certaines dispositions du texte ont un impact indirect sur le contrat[10]. Enfin, dans le contexte d’exercices de remédiation importants, les clients peuvent être face à une difficulté s’ils doivent analyser la documentation contractuelle de tous leurs fournisseurs et préfèrent une approche unifiée qui reflète leurs exigences minimales pour contractualiser avec un prestataire de services TIC.

La perspective des prestataires TIC et la réalité opérationnelle

D’autre part, les prestataires informatiques mettent en avant le fait que leur documentation contractuelle reflète le delivery model de leur service et donc est le plus à même de tenir compte de la réalité opérationnelle des exigences contractuelles. Ce raisonnement est d’autant plus mis en avant par les prestataires de service standard (e.g. cloud) dont le service est souvent fourni de la même manière à l’intégralité de leurs clients réglementés ou non et dont la documentation est amenée à évoluer en même temps que le service. Enfin, les prestataires de service TIC, peuvent être réticents à accepter des clauses contractuelles issues de la politique de risques du client ou de son interprétation du règlement et insistent pour se rapprocher au maximum des dispositions obligatoires du règlement afin de limiter leur exposition.

Points de tension : politique de risques vs exigences réglementaires

En fin de compte, la décision de la documentation contractuelle dépend du contexte de négociation des parties et de la clarté et la complétude de la documentation contractuelle qu’elles proposent. Quoi qu’il en soit, il ressort nettement un besoin de mettre en place une documentation contractuelle conforme aux exigences du règlement tant pour les entités financières que pour les prestataires informatiques.

En effet, un document contenant une cartographie des clauses exigées par Dora est généralement bien perçu par les clients comme un signe de maturité et constitue un puissant outil de marketing.

Annexes et documentation complémentaire : optimiser les appels d’offres

Même si les parties conviennent d’utiliser le modèle du client la rédaction d’une annexe dédiée par le prestataire est loin d’être futile : elle pourra servir de grille de lecture de la documentation du client et permettra, en tout état de cause de préciser le détail des engagements du fournisseur en identifiant comment, d’un point de vue opérationnel, ce dernier répond aux exigences règlementaires. Cette approche est d’autant plus pertinente en processus d’appel d’offres dans lequel la conformité règlementaire est souvent un critère de sélection pouvant différencier deux fournisseurs. En d’autres termes, la formulation d’une offre « service financiers » peut être un vrai gain de temps dans le processus de sélection et contractualisation.

 

 

La conformité à la loi : un équilibre difficile à trouver

Des intérêts diamétralement opposés difficiles à concilier

Dans le contexte de la Décennie Numérique et notamment dans celui du règlement Dora, la problématique de la conformité à la loi prend en compte une ampleur plus importante.

Pour les entités financières, la conformité règlementaire du service est fondamentale. En effet, leur conformité à la réglementation applicable au secteur financier est directement liée à la conformité des services telle que reflétée dans le contrat mais également à la réalité opérationnelle. Elles ont donc tendance à exiger dans le contrat le fait que le service fourni sera conforme non seulement à la règlementation applicable aux technologies de l’information mais également à la règlementation bancaire et leurs évolutions sans qu’elles aient besoin de concrétiser des spécifications ou payer pour des ajustements ultérieurs. Cette argumentation est d’autant plus présente lorsqu’un prestataire, notamment de niche, travaille principalement ou en grande partie avec le secteur financier.  Le client s’attend alors à ce que la conformité règlementaire et ses évolutions seront prises en compte dans le business model (p. ex. veille juridique, répartition des conséquences financières d’une évolution sur l’intégralité de la clientèle).

À l’opposé de l’enjeu des clients, les prestataires de service rappelleront, qu’en règle générale ils ne sont pas soumis au règlement Dora et que le client est seul responsable de sa conformité règlementaire. En effet, le règlement Dora ne s’appliquera directement qu’à un nombre limité de prestataires informatiques désignés comme critiques pour le secteur financier dans la deuxième moitié de 2025[11]. Par conséquent, les prestataires insistent pour s’engager uniquement à la loi qui leur est applicable, les spécificités du secteur financier devant être formulées dans les spécifications du client et les ajustements nécessaires devant être supportés financièrement par l’entité financière.

Une solution sur mesure dépendant du contexte de négociation

La question de la conformité à la loi n’a pas de solution unique, ni prédominante : il s’agit essentiellement d’une question technique ainsi que financière. Les approches contractuelles adoptées sont aussi diverses que les offres elles-mêmes et dépendent de la nature du service (standard ou « personnalisé »), les secteurs d’activité dans lesquels intervient le prestataire (service fourni de manière standard ou service spécifique délivré pour le secteur financier), l’impact des évolutions règlementaires (adaptation d’un service existant ou mise en place d’un service nouveau) et du pouvoir de négociation de chaque partie.

Il ne faut pas oublier, par ailleurs, que certaines règlementations applicables aux prestataires informatiques peuvent donner des réponses à certaines exigences du client. À  titre d’exemple, les contraintes sur les prestataires de service cloud en matière de réversibilité imposées par le Data Act peuvent répondre aux demandes des clients de sécuriser et fluidifier les stratégies de sortie en application de Dora. En particulier, le projet clauses contractuelles types relatives à la sécurité et la continuité d’activité en cours d’élaboration dans le contexte du Data Act[12] ne saurait qu’être apprécié par les entités financières qui cherchent à protéger la résilience opérationnelle.

En tout état de cause, les clauses de conformité à la loi deviennent de plus en plus centrales (et détaillées) et il convient d’y consacrer le temps nécessaire afin de s’assurer de la prise en compte des évolutions règlementaires et ses impacts financiers, notamment dans le contexte de contrats à longue durée.

 

La chaîne de sous-traitance : un enjeu majeur dans la résilience opérationnelle

Des exigences règlementaires détaillées sur la supervision de la chaîne de sous-traitance

Plus encore que les lignes directrices existantes des AES, le règlement Dora accorde une grande importance à la sous-traitance et aux risques qu’elle peut créer, notamment avec les RTS sur la sous-traitance de services soutenant des fonctions critiques ou importantes.

Cette approche n’est pas surprenante dans la mesure où, qu’on parle de cybersécurité ou de résilience opérationnelle, les attaques externes concernent de plus en plus la chaîne d’approvisionnement qui représente une porte d’entrée souvent plus facile et surtout plus variée.

Ainsi, bien que les RTS sous-traitance aient été allégées en matière de supervision de la chaîne de sous-traitance avec la suppression de l’ancien article 5, de fortes exigences en matière d’analyse de risque et supervision subsistent. En effet, l’obligation d’identifier tous les sous-traitants impliqués subsiste au titre de l’article 3(1)(b) des RTS sur la sous-traitance mais également l’article 3(2)(b) des ITS sur le registre d’information[13].

Par ailleurs, avant même de contractualiser avec un prestataire de services, l’entité financière devra opérer une analyse de risques poussée tenant compte de la longueur et complexité de la chaîne de sous-traitance ainsi que de nombreux autres critères tels que la localisation des sous-traitants, la possibilité pour le prestataire principal de les identifier et les superviser etc. Tout cela avant même de signer le contrat qui doit comporter des engagements de suivi de la prestation mais également de répercussion dans le contrat avec le sous-traitant d’un certain nombre d’éléments tels les droits d’audit, les obligations de suivi et de déclaration du sous-traitant, les exigences en matière de plan d’urgence, les normes de sécurité[14].

Des engagements de “back-to-back” parfois difficiles à obtenir

Des exigences contractuelles complexes pour les entités financières

Au regard des contraintes règlementaires dont les paragraphes ci-dessus ne sont qu’un résumé, les entités financières sont amenées à détailler leurs accords contractuels relatifs à des services TIC et à exiger de leurs prestataires un nombre important d’informations et engagements au regard de leurs sous-traitants.

Cartographie de la chaîne de sous-traitance : une étape clé pour les prestataires

Pour les prestataires de services, cela suppose dans un premier temps de réaliser une cartographie de la chaîne de sous-traitance dans son intégralité. Cette cartographie pose rarement un problème dans le cadre de prestations de services « sur mesure » (e.g. maintenance, externalisation etc.) dans lesquelles le prestataire principal dispose d’une maîtrise importante des compétences externes dont il a besoin, et donc de la chaîne de sous-traitance relativement réduite ou du moins souvent constituée de ses filiales.

Les défis des services TIC standards

Au contraire, ce travail est plus difficile dans le contexte de service TIC standards (e.g. IaaS, PaaS, SaaS) qui ont comme caractéristique une chaîne de sous-traitance plus complexe, souvent elle-même reposant sur des services standard fournis de manière agnostique. Dans ce contexte, il est plus difficile d’imposer des exigences contractuelles spécifiques au sous-traitant qui, parfois, peut être loin du client final. Le prestataire principal se retrouve alors souvent « entre deux » sans avoir la possibilité d’absorber l’intégralité du risque lié aux exigences contractuelles des clients.

Une documentation contractuelle à deux niveaux

C’est ainsi que commence à apparaître une documentation à deux niveaux, notamment dans des contrats portant sur des services standards proposés aux services financiers : un premier niveau comporte les obligations contractuelles assumées par le prestataire principal et un deuxième niveau prévoit les obligations contractuelles applicables aux sous-traitants (notamment hébergeurs) dans une logique de back-to-back inversé. Les mécanismes d’opposition et résiliation du contrat en cas de désaccord de l’entité financière sont également utilisés. Il convient alors que l’entité financière vérifie que tous les niveaux répondent aux exigences contractuelles et qu’elle s’assure de disposer d’un service alternatif en cas de désaccord sur la chaîne de sous-traitance l’obligeant à résilier le service.

 

Certifications et droits d’audit : un équilibre difficile à trouver pour les prestations standards

Des droits d’audit illimités, rien de nouveau pour le secteur financier

La demande des entités financières d’avoir un droit de regard sur leurs prestataires informatiques n’est pas née avec le règlement Dora. Elle était bien présente dans les lignes directrices des AES et ne surprend guerre. À  titre d’exemple, les lignes directrices de l’EBA, prévoyaient déjà la possibilité pour la fonction d’audit interne de la banque de revoir la fonction externalisée sur la base d’une analyse de risque[15].

Conformément au principe de proportionnalité, dans son article 30(3) et dans l’article 8 des RTS sur la contractualisation, Dora maintient une logique similaire selon laquelle les droits d’audit illimités s’appliquent uniquement sur les services qui soutiennent des fonctions critiques ou importantes. Le règlement précise que l’entité financière ou le régulateur doit être en mesure de collecter des copies de documents pertinents s’ils sont essentiels aux activités du prestataire. Ces droits d’audit visent à sécuriser la possibilité pour l’entité financière de superviser effectivement les prestations et doivent être lus en parallèle des obligations de reporting du prestataire.

Les certifications : une solution incomplète

La nouveauté du règlement Dora est d’interdire l’utilisation exclusive des certifications et plans d’audit internes de leurs prestataires[16]. Cette approche pose rarement de difficulté dans le contexte de prestations de services « personnalisées » (e.g. contrats d’externalisation). En effet, dans la mesure où l’article 30(3)(e)(iv) permet de définir une fréquence, portée et procédure d’audit, les garde-fous habituels restent applicables.

Les défis des services standardisés

Le sujet est tout autre pour les services fortement standardisés qui reposent généralement sur des mécanismes de supervision mutualisés (e.g. supervision de la disponibilité via une console) et des rapports d’audit de tiers (p. ex. SOC II, ISO 27 001 etc.). Pour ces prestataires, dévier de cette approche pose une difficulté majeure dans la mesure où des droits d’audit exigent la mobilisation forte de leur personnel, notamment dans le contexte de TLPT, et peuvent mettre à risque les données de leurs autres clients utilisant des infrastructures mutualisées. Par ailleurs ils peuvent rencontrer des difficultés à répercuter des droits d’audit permissifs avec leurs sous-traitants.

Les niveaux d’assurance alternatifs

La principale solution à cette problématique apparaît à l’article 30(3)(e)(ii) du règlement qui permet de convenir d’autres niveaux d’assurance alternatifs lorsque les droits des autres clients du prestataire sont affectés. Ces niveaux d’assurance alternatifs sont précisés à l’article 8(2) des RTS sur la contractualisation qui permet aux entités financières de s’appuyer, outre sur leur propre audit interne, sur des audits groupés.

Deux types d’audits groupés sont alors possibles et ressortent du projet de RTS relatif aux TLPT[17] : les tests groupés (« pooled test ») à l’occasion desquels le prestataire contractualise avec l’auditeur et qui ne sont possibles que si l’entité financière a vérifié leur complétude, pertinence et mise à jour et les tests joints (« joint test ») qui sont des tests, autres que les tests groupés qui impliquent plusieurs entités financières (p. ex. tests réalisés par plusieurs entités financières du même groupe).

Conclusion sur les audits

En conclusion, il n’y a pas de solution miracle à la question des droits d’audit des entités financières, la réponse devant être trouvée dans le delivery model du prestataire de services TIC et des assurances qu’il peut offrir à son client. L’on peut imaginer l’émergence de programmes d’audit robustes réalisés à une fréquence déterminée lors desquels plusieurs entités financières pourraient activer leur droit d’audit de manière à regrouper les sollicitations du prestataire et réduire le risque d’impact sur les systèmes de production de ses clients.

 

Les droits de résiliation : un point de discorde majeur

Des droits de sortie étendus imposés par la règlementation

Outre les droits d’audit ou encore la supervision de la chaîne de sous-traitance, un des sujets les plus discutés dans le contexte du règlement Dora relève des droits de résiliation.

En effet, l’article 28(7) exige de prévoir dans les contrats de prestation de services TIC, ce peu importe  leur criticité, les droits de résiliation en cas de manquement à la règlementation, de changements significatifs dans la situation du prestataire, de faiblesses avérées liées à la gestion des risques ou encore l’impossibilité pour une autorité de réaliser la supervision de l’entité financière.

Pour les services soutenant des fonctions critiques ou importantes, ces droits de résiliation sont complétés par les RTS sous-traitance qui prévoient des droits de résiliation si le prestataire de services TIC a mis en œuvre des changements significatifs aux accords de sous-traitance malgré l’objection du client ou avant la période de préavis durant laquelle le client peut s’y opposer, ou encore si le prestataire a eu  recours à de la sous-traitance non-autorisée.

On note ici une volonté du régulateur de renforcer la position des entités financières en mettant à risque le prestataire de services TIC si la résilience opérationnelle n’est pas respectée. Néanmoins, c’est justement cette mise à risque que les prestataires de services TIC souhaitent encadrer.

Un équilibre financier difficile mais indispensable

Même en dehors d’un contexte règlementaire, les droits de résiliation sont souvent l’objet de discussions importantes entre les parties à un contrat informatique. Pour le client, ils représentent un moyen de pression sur le prestataire dans un certain nombre de cas jugés fondamentaux par le client. D’autre part, pour le prestataire, des droits de résiliation permissifs, voire subjectifs, mettent le chiffre d’affaires associé à risque et nuisent à la reconnaissance du revenu.

C’est donc sans surprise que les droits de résiliation, ou plutôt leurs conséquences financières, font l’objet de débats passionnés. À ce sujet, les entités financières auront tendance à soutenir que les cas précités sont une exigence règlementaire et, pour la plupart, constitutifs d’un manquement puisqu’ils font état d’une incapacité du prestaire de maintenir la résilience opérationnelle. D’autre part, les prestataires de services TIC soutiendront que certains cas de résiliation sont le résultat d’une analyse de risques subjective ou sont liés à la règlementation applicable au client (notamment la capacité de l’autorité compétente de superviser l’entité financière) qui n’est pas nécessairement rattachée à un manquement.

Encore une fois, il n’y a pas une solution unique si ce n’est de discuter ouvertement des différents cas de résiliation en fonction du contexte, de la nature de la prestation et des enjeux financiers afin de trouver un équilibre économique acceptable pour les deux parties. Naît alors la nécessité pour les prestataires de services TIC de prendre en compte, dans leur modèle financier et leur matrice de risques, des droits de résiliation spécifiques pour le secteur financier.

 

Conclusion

Des offres spécifiques pour le service financier fondées sur le devoir de conseil, d’alerte, de collaboration et le principe de proportionnalité ?

Comme on a pu le voir tout au long de cet article, le règlement Dora et les différentes normes techniques (ITS / RTS) créent le besoin de mettre en place une documentation contractuelle spécifique pour le secteur financier et, par conséquent, une offre commerciale et opérationnelle adaptée. Il n’y pas de doute que les prestataires qui travaillent régulièrement avec le secteur financier sont amenés à personnaliser leur offre de services pour répondre aux exigences du secteur, quand bien même le service fourni est standard.

Deux éléments complémentaires permettent d’éclairer les discussions contractuelles et de trouver des solutions adaptées aux problématiques contractuelles.

Dans un premier temps, en ce qui concerne le prestataire, on voit l’importance accrue de l’obligation de conseil et d’alerte qui vise à guider le client dans la compréhension de l’offre et de la manière dont la conformité règlementaire peut être atteinte. Le devoir de conseil du fournisseur est primordial dans la phase précontractuelle lors de laquelle le client identifie ses besoins (y compris règlementaires) et évalue si, ou plutôt comment, le fournisseur peut y répondre.

Le deuxième élément permettant de débloquer les discussions contractuelles relève du client et de son obligation de respecter le principe de proportionnalité, pilier transversal du règlement Dora. Ainsi, le client doit appliquer systématiquement une analyse de risque afin d’adopter une approche contractuelle proportionnée en évitant des clauses « balais » vides de sens au regard de la réalité du service.

C’est précisément pour pouvoir appliquer le principe de proportionnalité que les entités financières peuvent bénéficier du conseil du prestataire de services TIC qui, à l’aide d’une approche pédagogique, permet au client d’être proportionné dans ses demandes contractuelles et chercher la solution de conformité non seulement dans des clauses contractuelles mais, également , et c’est le but ultime de Dora, dans la configuration, l’utilisation et l’opération du service.

 

A propos de l’auteure

Evelina Dimitrova est avocat à la Cour et Senior Associate au sein du cabinet DLA Piper France LLP. Elle intervient principalement en droit des nouvelles technologies, de la protection des données personnelles, de la propriété intellectuelle et des contrats informatiques.

Références et sources

  1. ESA 2023 22, 19 09 2023 — ESAs Report on the landscape of third-party providers in the EU, Overview of the high-level exercise : Lire le rapport .
  2. Communiqué de presse accompagnant la déclaration européenne sur les droits et principes numériques : Consulter le communiqué .
  3. Proposition de règlement du Parlement européen et du Conseil sur la résilience opérationnelle numérique du secteur financier et modification de plusieurs règlements (Texte présentant de l'intérêt pour l'EEE) : Consulter le texte .
  4. Lignes directrices de l’EIOPA, ESMA et EBA relatives à l’externalisation auprès de prestataires cloud : Lire les lignes directrices .
  5. Directive (UE) 2022/2556 du Parlement européen et du Conseil sur la résilience opérationnelle numérique du secteur financier : Consulter la directive .
  6. Directive (UE) 2022/2555 sur la cybersécurité (directive SRI 2) : Consulter la directive .
  7. Directive (UE) 2022/2557 sur la résilience des entités critiques : Consulter la directive .
  8. Règlement délégué (UE) 2024/1773 complétant le règlement (UE) 2022/2554 sur les services TIC critiques : Lire le règlement .
  9. Règlement délégué (UE) du 24.3.2025 complétant le règlement (UE) 2022/2554 concernant les services TIC critiques : Lire le règlement .
  10. Article 10 des RTS — outils, méthodes, processus et politiques de gestion des risques des prestataires TIC ; dispositions sur le partage d’information : Consulter le texte .
  11. EBA — Timeline pour la désignation des prestataires critiques de services TIC sous DORA : Consulter l’annonce de l’EBA .
  12. Final report of the Expert Group on B2B data sharing and cloud computing contracts : Lire le rapport .
  13. Règlement d’exécution (UE) 2024/2956 sur les modèles types pour le registre d’informations : Lire le règlement .
  14. RTS Sous-traitance, article 3(d) à (j) : Consulter le texte .
  15. Article 13.3 des lignes directrices de l’EBA en matière d’externalisation : Consulter le texte .
  16. Article 8 des RTS sur la Contractualisation : Consulter le texte .
  17. Draft Regulatory Technical Standards — threat led penetration tests, Article 26(11) of Regulation (EU) 2022/2554, paragraphe 55 à 60 : Lire le draft .

 

Vous avez aimé l’article ? 

N’hésitez pas à le partager et à nous suivre sur nos réseaux sociaux pour en apprendre plus

 

Nous suivre sur LinkedIn
Share
Nous suivre sur YouTube