De tous les piliers du règlement DORA, la gestion des risques liés aux prestataires tiers de services ICT est celui qui transforme le plus profondément les pratiques du secteur financier. Le règlement (EU) 2022/2554 consacre ses articles 28 à 44 à ce sujet — un volume qui en dit long sur l'importance que le législateur européen accorde à la maîtrise des dépendances technologiques.
Pour les RSSI et compliance officers, c'est un chantier colossal. Mais c'est aussi une opportunité de mieux comprendre et maîtriser un risque que beaucoup d'institutions avaient, soyons francs, largement sous-estimé.
Pourquoi les risques ICT tiers sont-ils au coeur de DORA ?
Le constat qui a motivé le législateur est sans appel : le secteur financier est devenu profondément dépendant d'un nombre relativement restreint de prestataires technologiques. Quand un grand cloud provider subit une panne, ce ne sont pas une ou deux banques qui sont impactées — c'est potentiellement l'ensemble du système financier.
Cette concentration des risques a été identifiée dès 2019 par le Comité européen du risque systémique (CERS) comme un risque systémique majeur. DORA est la réponse réglementaire à ce constat.
La dépendance aux prestataires ICT n'est pas un risque opérationnel parmi d'autres — c'est un risque systémique qui peut menacer la stabilité financière. C'est pourquoi DORA ne se contente pas de réglementer les entités financières : il supervise directement les prestataires critiques.
Le registre d'informations : cartographier toutes les dépendances ICT
L'article 28(3) de DORA impose à chaque entité financière de tenir un registre d'informations exhaustif de tous les accords contractuels conclus avec des prestataires tiers de services ICT. C'est le point de départ de toute la démarche.
Que doit contenir le registre ?
Le registre doit inclure, pour chaque accord contractuel :
| Information requise | Détail | Référence |
|---|---|---|
| Identification du prestataire | Nom, siège social, identifiant LEI le cas échéant | Art. 28(3) |
| Nature du service | Description du service ICT fourni | RTS Art. 2-4 |
| Fonctions supportées | Fonctions critiques ou importantes soutenues par le service | Art. 28(3)(b) |
| Sous-traitance | Chaîne de sous-traitance identifiée | Art. 29(2) |
| Localisation | Pays de traitement et stockage des données | Art. 28(3)(d) |
| Date et durée | Date de début, durée, conditions de renouvellement | Art. 28(3)(a) |
Le registre doit être mis à jour en continu et fourni à l'autorité compétente sur demande. Il doit également distinguer clairement les accords portant sur des fonctions critiques ou importantes.
Le défi de la chaîne de sous-traitance
Un aspect souvent sous-estimé : DORA exige la transparence sur la chaîne de sous-traitance. Si votre prestataire cloud utilise lui-même des sous-traitants pour certains composants, vous devez le savoir et le documenter.
En pratique, obtenir cette information des grands prestataires technologiques reste un défi. Les hyperscalers ont des chaînes de sous-traitance complexes et ne sont pas toujours enclins à les détailler. C'est l'un des points de friction les plus importants dans les négociations contractuelles post-DORA.
Les clauses contractuelles obligatoires
L'article 30 de DORA définit un socle minimal de clauses contractuelles obligatoires dans tout accord avec un prestataire tiers ICT supportant des fonctions critiques ou importantes :
Clauses applicables à tous les accords (Art. 30(2))
- Description complète du service : périmètre, fonctions, niveaux de service (SLA) avec indicateurs quantitatifs et qualitatifs
- Sécurité des données : exigences de disponibilité, authenticité, intégrité et confidentialité
- Notification d'incidents : obligation pour le prestataire de notifier les incidents ICT impactant les services fournis
- Coopération avec les autorités : le prestataire doit coopérer pleinement avec les autorités compétentes de l'entité financière
- Droits de résiliation : conditions claires de résiliation du contrat
Clauses supplémentaires pour les fonctions critiques (Art. 30(3))
- Droits d'audit et d'inspection illimités, y compris accès physique aux locaux du prestataire
- Stratégies de sortie documentées avec périodes de transition
- Localisation des données et du traitement — y compris en cas de sous-traitance
- Obligations de continuité d'activité du prestataire
- Plans de tests incluant le prestataire dans le périmètre des tests de résilience
La supervision directe des prestataires tiers critiques
C'est l'innovation majeure de DORA : pour la première fois, des acteurs non-financiers seront directement supervisés par les régulateurs financiers européens. Le cadre, défini aux articles 31 à 44, fonctionne ainsi :
Processus de désignation
- Les AES évaluent les prestataires selon les critères de criticité (caractère systémique, dépendance, substituabilité)
- Un prestataire est désigné critique par décision conjointe des AES
- Un "lead overseer" (superviseur principal) est désigné parmi les AES selon le secteur financier principalement desservi
Pouvoirs du superviseur principal
Le superviseur principal dispose de pouvoirs étendus vis-à-vis des prestataires critiques :
- Demandes d'informations : tout document, donnée ou information pertinente
- Inspections générales et sur site : accès aux locaux et systèmes du prestataire
- Recommandations : sur la sécurité, la gouvernance, la gestion des risques, la continuité d'activité
- Astreintes : en cas de non-respect des recommandations (jusqu'à 1% du chiffre d'affaires quotidien)
Qui sera désigné critique ?
Les premiers prestataires susceptibles d'être désignés critiques incluent :
| Type de prestataire | Exemples | Raison de criticité |
|---|---|---|
| Hyperscalers cloud | AWS, Microsoft Azure, Google Cloud | Infrastructure de base pour des milliers d'entités financières |
| Fournisseurs de données financières | Bloomberg, Refinitiv, S&P Global | Données essentielles au fonctionnement des marchés |
| Éditeurs de core banking | Temenos, Finastra, FIS | Systèmes centraux non-substituables à court terme |
| Réseaux de paiement | SWIFT, Visa, Mastercard | Infrastructure critique des paiements |
La gestion du risque de concentration
L'article 29 de DORA aborde un risque spécifique : la concentration excessive sur un nombre restreint de prestataires. Les entités financières doivent :
- Évaluer régulièrement le risque de concentration dans leurs dépendances ICT
- Identifier les prestataires non-substituables ou difficilement remplaçables
- Élaborer des stratégies de diversification lorsque la concentration est jugée excessive
- Documenter ces analyses et les mettre à disposition du superviseur
La réalité du marché rend cet exercice complexe. Pour le cloud public, par exemple, seuls trois acteurs dominent le marché européen. Diversifier signifie souvent adopter une stratégie multi-cloud, avec les coûts et la complexité technique que cela implique.
Stratégies de sortie : anticiper la fin d'une relation
DORA impose l'élaboration de stratégies de sortie pour chaque accord portant sur des fonctions critiques ou importantes. L'objectif : pouvoir quitter un prestataire sans perturbation opérationnelle.
Une stratégie de sortie efficace doit inclure :
- Un plan de migration détaillé avec jalons et responsabilités
- Une période de transition suffisante (généralement 6 à 18 mois selon la complexité)
- Des mécanismes de portabilité des données et des traitements
- Des tests réguliers de la faisabilité de la stratégie de sortie
- L'identification de prestataires alternatifs ou de solutions internes de remplacement
C'est probablement l'exigence la plus difficile à mettre en oeuvre. Beaucoup d'entités financières se sont rendues compte, en élaborant leurs stratégies de sortie, à quel point elles étaient "locked in" avec certains prestataires. Les formats propriétaires, les intégrations profondes et les coûts de migration rendent la sortie théorique bien différente de la sortie réelle.
Impact sur les prestataires ICT eux-mêmes
DORA a un effet de cascade sur tout l'écosystème technologique du secteur financier. Même les prestataires non désignés critiques subissent des exigences accrues de la part de leurs clients financiers :
- Exigences contractuelles renforcées : clauses DORA systématiquement demandées
- Audits plus fréquents : les entités financières exercent davantage leurs droits d'audit
- Transparence accrue : demandes de documentation sur la sécurité, la continuité, la chaîne de sous-traitance
- Notifications d'incidents : obligation de remonter rapidement tout incident
Pour les prestataires de taille moyenne, ces exigences représentent un investissement significatif. Certains ont fait le choix de se "pré-certifier" selon des référentiels reconnus (ISO 27001, SOC 2) pour faciliter les évaluations.
Premiers retours terrain
Depuis l'entrée en application de DORA, plusieurs constats émergent :
- La constitution du registre d'informations s'est révélée être le chantier le plus chronophage — beaucoup d'institutions ont découvert des centaines de contrats ICT non-cartographiés
- Les grands cloud providers ont proposé des amendements contractuels "DORA-compliant", mais les négociations individuelles restent nécessaires pour les fonctions critiques
- La question de la localisation des données a refait surface, certaines autorités nationales poussant pour un traitement au sein de l'UE
- Les stratégies de sortie restent souvent théoriques — les régulateurs sont attendus pour préciser le niveau de détail et de testabilité requis
Pour le cadre global de ces obligations, consultez notre guide complet du règlement DORA. Pour comprendre comment les tests de résilience s'intègrent à la gestion des risques tiers, notre article sur les tests de résilience DORA et TLPT approfondit ce volet.
Questions fréquentes sur les risques ICT tiers
Qu'est-ce que le registre d'informations DORA ?
Le registre d'informations est un inventaire exhaustif de tous les accords contractuels conclus entre une entité financière et ses prestataires tiers de services ICT. Il doit être tenu à jour et mis à disposition de l'autorité compétente sur demande.
Quelles clauses contractuelles DORA impose-t-il ?
DORA impose des clauses incluant : les niveaux de service (SLA), les droits d'audit et d'inspection, les obligations de notification d'incidents, la coopération avec les autorités, les stratégies de sortie, la localisation des données et les exigences de sécurité.
Comment est désigné un prestataire tiers critique ?
Les prestataires critiques sont désignés par les AES sur la base de critères incluant le caractère systémique des services, le degré de dépendance, la substituabilité et le nombre d'entités clientes.
Les grands cloud providers sont-ils concernés ?
Oui, les hyperscalers sont parmi les premiers prestataires susceptibles d'être désignés critiques, les soumettant à un cadre de supervision directe par les AES.
Qu'est-ce qu'une stratégie de sortie DORA ?
Une stratégie de sortie est un plan documenté permettant de mettre fin à un accord contractuel avec un prestataire tiers ICT sans perturbation des activités, sans réduction de la qualité des services et sans manquement réglementaire.