Si votre fournisseur ICT critique tombe demain: qu'est-ce qui s'arrête — et pour combien de temps?
En un coup d'œil
La question n'est plus seulement le fournisseur.
La question est de savoir si l'institution peut démontrer la continuité.
Board AskConfirmer si l'institution peut démontrer continuité et capacité d'exit pour les services ICT soutenant des fonctions critiques ou importantes.
Situation
Supposons la situation suivante.
Un fournisseur tiers ICT critique devient indisponible. Il soutient une plateforme, un service de données, un environnement cloud, un moteur de workflow, une couche de reporting ou un processus assisté par IA utilisé par l'institution. En quelques heures, la question n'est plus de savoir si le fournisseur a une obligation contractuelle de restaurer le service.
La question est de savoir ce qui s'arrête à l'intérieur de la banque.
Quelles fonctions critiques ou importantes sont affectées? Quelles chaînes client, risque, opérationnelles ou décisionnelles dépendent du fournisseur? Quel est le temps de récupération testé? Le service peut-il être substitué, quitté ou restauré dans la tolérance de l'institution?
La question n'est plus seulement le fournisseur.
La question est de savoir si l'institution peut démontrer la continuité.
Management Summary
DORA fait du risque tiers ICT une discipline board-level et fondée sur l'evidence. Les entités financières restent responsables de leur conformité même lorsque les services ICT sont fournis par des tiers; DORA exige également une gestion du risque tiers ICT, un Register of Information et des stratégies d'exit pour les services ICT soutenant des fonctions critiques ou importantes.
Les Autorités européennes de surveillance ont publié le 18 novembre 2025 la première liste de 19 fournisseurs tiers ICT critiques désignés sous DORA. Le processus de désignation s'est appuyé sur les données des Registers of Information et sur une évaluation de criticité couvrant l'importance systémique, le soutien à des fonctions critiques ou importantes et la substituabilité.
Une réponse forte n'est pas "we have an exit policy". Une réponse forte montre quels services s'arrêtent, quel recovery objective s'applique, où les dépendances convergent, quel exit path a été testé et qui peut décider de restreindre, substituer, sortir ou poursuivre l'arrangement.
Management Report Panel
Calibration de la qualité de réponse
Le RAG status calibre la qualité de la réponse. Il ne juge pas l'institution.
Qui doit répondre
- Procurement peut détenir le contrat.
- Technology peut détenir la plateforme.
- Le business détient l'impact.
- Le board doit voir la chaîne.
Preuves que le conseil devrait demander
- 01Register of Information
- 02Critical Function Mapping
- 03Provider Criticality Classification
- 04Concentration Risk Assessment
- 05Fourth-Party Dependency Map
- 06RTO / RPO / MTPD View
- 07Tested Exit Strategy
- 08Contractual Exit and Transition Evidence
- 09Incident and Recovery Exercise Log
- 10Board Resilience Dashboard
Signaux d'alerte
- “We have an exit policy.”
- “The provider is directly overseen under DORA.”
- “This is handled by Procurement.”
- “The provider has strong SLAs.”
- “We use multiple providers.”
- “The service is not client-facing.”
- “The exit plan is documented.”
- “We could exit if necessary.”
Aucune de ces déclarations n'est nécessairement fausse. Elles ne constituent simplement pas une evidence suffisante pour une board-level reliance.
Chemin vers le vert
- Dépendances visibles
- Criticité classifiée
- Concentration comprise
- Recovery mesuré
- Exit activé
- Risque résiduel gouverné
GREEN is not a contract status.
GREEN is a tested continuity status.
Prochaine question suggérée
Quelle fonction critique ou importante créerait la plus grande disruption si son fournisseur ICT tombait demain — et pouvons-nous démontrer le recovery path testé?
Base de sources sélectionnée
- Regulation (EU) 2022/2554, Digital Operational Resilience Act, especially Articles 28, 29 and 30.
- European Supervisory Authorities, designation of critical ICT third-party providers under DORA, 18 November 2025.
- ESMA, official list of designated CTPPs under Article 31(9) of DORA.
- ECB Banking Supervision, Supervisory Priorities 2026–28.
- ESAs, Guide on DORA oversight activities, JC 2025 29.
- BCBS, Principles for Operational Resilience, 2021.
- FSB, Enhancing Third-Party Risk Management and Oversight, 2023.
- NIST Cybersecurity Framework 2.0.
- ISO 22301 Business Continuity Management.
Commentaire d'expert — 7 min de lecture
La résilience des tiers ICT est souvent discutée à travers contrats, registres d'outsourcing et provider oversight. Ces éléments comptent. Mais ils ne répondent pas à la question la plus pratique du board.
Qu'est-ce qui s'arrête — et pour combien de temps?
Cette question est volontairement opérationnelle. Elle traduit DORA du texte réglementaire vers la réalité managériale board-level. Un fournisseur ICT critique peut soutenir un environnement cloud, un moteur de workflow, une couche de reporting, une capacité cybersecurity, un service de données, un flux de market data, une plateforme documentaire ou un processus assisté par IA. Le fournisseur peut ne pas être visible pour les clients. La dépendance peut néanmoins être critique.
DORA rend le point de responsabilité explicite. Les entités financières utilisant des services ICT restent responsables du respect de leurs obligations, et le risque tiers ICT doit être géré dans le cadre du dispositif de gestion du risque ICT. DORA exige également que les entités financières maintiennent et mettent à jour un Register of Information couvrant tous les arrangements contractuels relatifs à l'utilisation de services ICT fournis par des prestataires tiers ICT.
Visibilité
Cela fait de la visibilité la première discipline.
Un board ne peut pas exercer d'oversight sur une dépendance qu'il ne voit pas. Une banque ne peut pas gouverner une chaîne de providers qu'elle n'a pas mappée. Et elle ne peut pas répondre à "combien de temps" sans objectif de recovery testé, relié à une fonction critique ou importante spécifique.
Concentration
La deuxième discipline est la concentration.
DORA exige que les entités financières prennent en compte le risque de concentration lorsqu'elles concluent des arrangements pour des services ICT soutenant des fonctions critiques ou importantes. Cela inclut la question de savoir si un fournisseur n'est pas facilement substituable ou si plusieurs arrangements créent des dépendances envers le même fournisseur ou des fournisseurs étroitement liés.
Cela compte parce que la diversification peut être trompeuse.
Deux fournisseurs peuvent paraître indépendants au niveau contractuel, mais converger sur les couches cloud, data centre, réseau, identité, DNS, logiciel, subcontracting ou support opérationnel. Une réponse board-grade ne s'arrête donc pas à "we have more than one provider". Elle demande si les modes de défaillance sont réellement indépendants.
Capacité d'exit
La troisième discipline est la capacité d'exit.
DORA exige des stratégies d'exit pour les services ICT soutenant des fonctions critiques ou importantes; ces plans d'exit doivent être complets, documentés, suffisamment testés et périodiquement revus. DORA exige également des arrangements contractuels écrits allouant droits et obligations, y compris des dispositions relatives à l'accès, au recovery, à la restitution des données, à la résiliation et à l'exit.
C'est ici que les réponses faibles semblent souvent plausibles.
Et l'oversight direct d'un fournisseur critique ne remplace pas le third-party risk management propre de l'institution. Les ECB Supervisory Priorities 2026–28 indiquent que les exigences liées à DORA, notamment le risque tiers ICT et l'incident response management, doivent être mises en œuvre de manière cohérente et rapide; elles indiquent également que le DORA oversight framework pour les critical third-party providers complète, mais ne remplace pas, un sound third-party risk management.
La question pratique du board n'est donc pas de savoir si le provider est solide.
Elle est de savoir si l'institution est résiliente à la défaillance du provider.
Cela exige une structure de réponse différente. Le board devrait voir une dependency map, une vue de criticité, une concentration assessment, un recovery objective, un exit path testé, une evidence contractuelle et un dashboard du risque résiduel. Il devrait également voir où la substitution n'est pas réaliste. Dans ces cas, la résilience doit venir des continuity arrangements, contingency planning, protections contractuelles, monitoring et acceptation formelle du risque résiduel.
Le but n'est pas d'éliminer chaque dépendance.
Ce serait irréaliste.
Le but est de savoir quelles dépendances comptent, ce qui casse lorsqu'elles échouent, combien de temps dure la récupération, qui détient la réponse et quelle evidence soutient la réponse.
Un provider supervisé n'est pas la même chose qu'une institution résiliente.
La résilience commence lorsque le board peut poser la question — et recevoir une réponse mappée, testée et gouvernable.