Se il vostro provider ICT critico cade domani: cosa si ferma — e per quanto tempo?
In sintesi
Il punto non è più solo il provider.
Il punto è se l'istituzione può dimostrare continuità.
Board AskConfermare se l'istituzione può dimostrare continuità e capacità di exit per servizi ICT che supportano funzioni critiche o importanti.
Situation
Assumiamo la seguente situazione.
Un provider terzo ICT critico diventa indisponibile. Supporta una piattaforma, un servizio dati, un ambiente cloud, un workflow engine, un layer di reporting o un processo AI-enabled utilizzato dall'istituzione. Nel giro di poche ore, la domanda non è più se il provider abbia un obbligo contrattuale di ripristinare il servizio.
La domanda è cosa si ferma dentro la banca.
Quali funzioni critiche o importanti sono impattate? Quali catene clienti, rischio, operative o decisionali dipendono dal provider? Qual è il tempo di recovery testato? Il servizio può essere sostituito, abbandonato o ripristinato entro la tolleranza dell'istituzione?
Il punto non è più solo il provider.
Il punto è se l'istituzione può dimostrare continuità.
Management Summary
DORA rende il rischio terze parti ICT una disciplina board-level e basata sull'evidence. Le entità finanziarie restano responsabili della compliance anche quando i servizi ICT sono forniti da terzi; DORA richiede inoltre ICT third-party risk management, un Register of Information e strategie di exit per i servizi ICT che supportano funzioni critiche o importanti.
Le Autorità europee di vigilanza hanno pubblicato il 18 novembre 2025 la prima lista di 19 provider terzi ICT critici designati sotto DORA. Il processo di designazione ha utilizzato dati dai Registers of Information e una valutazione di criticità che copre importanza sistemica, supporto a funzioni critiche o importanti e sostituibilità.
Una risposta forte non è "we have an exit policy". Una risposta forte mostra quali servizi si fermano, quale recovery objective si applica, dove convergono le dipendenze, quale exit path è stato testato e chi può decidere di limitare, sostituire, uscire o continuare l'arrangement.
Management Report Panel
Calibrazione della qualità della risposta
Il RAG status calibra la qualità della risposta. Non giudica l'istituzione.
Chi dovrebbe rispondere
- Procurement può detenere il contratto.
- Technology può detenere la piattaforma.
- Il business detiene l'impatto.
- Il board deve vedere la catena.
Prove che il consiglio dovrebbe richiedere
- 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
Segnali di allarme
- “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.”
Nessuna di queste affermazioni è necessariamente falsa. Semplicemente, non costituiscono evidence sufficiente per board-level reliance.
Percorso verso il verde
- Dipendenze visibili
- Criticità classificata
- Concentrazione compresa
- Recovery misurato
- Exit abilitato
- Rischio residuo governato
GREEN is not a contract status.
GREEN is a tested continuity status.
Prossima domanda suggerita
Quale funzione critica o importante creerebbe la maggiore disruption se il suo provider ICT cadesse domani — e possiamo dimostrare il recovery path testato?
Base di fonti selezionata
- 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.
Commento dell'esperto — 7 min di lettura
La resilienza delle terze parti ICT viene spesso discussa attraverso contratti, outsourcing registers e provider oversight. Questi elementi contano. Ma non rispondono alla domanda più pratica del board.
Cosa si ferma — e per quanto tempo?
Questa domanda è volutamente operativa. Traduce DORA dal testo regolamentare alla realtà manageriale board-level. Un provider ICT critico può supportare un ambiente cloud, un workflow engine, un reporting layer, una capacità cybersecurity, un servizio dati, un market-data feed, una piattaforma documentale o un processo AI-enabled. Il provider può non essere visibile ai clienti. La dipendenza può comunque essere critica.
DORA rende esplicito il punto di responsabilità. Le entità finanziarie che utilizzano servizi ICT restano responsabili del rispetto dei propri obblighi, e il rischio terze parti ICT deve essere gestito come parte dell'ICT risk management framework. DORA richiede inoltre che le entità finanziarie mantengano e aggiornino un Register of Information che copra tutti gli arrangements contrattuali sull'uso di servizi ICT forniti da provider terzi ICT.
Visibilità
Questo rende la visibilità la prima disciplina.
Un board non può esercitare oversight su una dipendenza che non vede. Una banca non può governare una catena di provider che non ha mappato. E non può rispondere a "quanto tempo" senza un recovery objective testato collegato a una specifica funzione critica o importante.
Concentrazione
La seconda disciplina è la concentrazione.
DORA richiede alle entità finanziarie di considerare il rischio di concentrazione quando stipulano arrangements per servizi ICT che supportano funzioni critiche o importanti. Questo include se un provider non è facilmente sostituibile o se più arrangements creano dipendenze dallo stesso provider o da provider strettamente collegati.
Questo conta perché la diversificazione può essere fuorviante.
Due provider possono apparire indipendenti a livello contrattuale ma convergere su cloud, data centre, network, identity, DNS, software, subcontracting o operational-support layers. Una risposta board-grade quindi non si ferma a "we have more than one provider". Chiede se i failure modes siano realmente indipendenti.
Capacità di exit
La terza disciplina è la capacità di exit.
DORA richiede strategie di exit per servizi ICT che supportano funzioni critiche o importanti; tali piani di exit devono essere completi, documentati, sufficientemente testati e revisionati periodicamente. DORA richiede inoltre arrangements contrattuali scritti che allocano diritti e obblighi, inclusi provisions rilevanti per accesso, recovery, restituzione dei dati, termination ed exit.
È qui che le risposte deboli spesso sembrano plausibili.
E l'oversight diretto di un provider critico non sostituisce il third-party risk management proprio dell'istituzione. Le ECB Supervisory Priorities 2026–28 affermano che i requisiti legati a DORA, in particolare ICT third-party risk e incident response management, devono essere implementati in modo coerente e rapido; affermano inoltre che il DORA oversight framework per i critical third-party providers completa, ma non sostituisce, un sound third-party risk management.
La domanda pratica del board quindi non è se il provider sia forte.
È se l'istituzione sia resiliente al failure del provider.
Ciò richiede una struttura di risposta diversa. Il board dovrebbe vedere una dependency map, una vista di criticità, una concentration assessment, un recovery objective, un exit path testato, contractual evidence e un dashboard del rischio residuo. Dovrebbe anche vedere dove la substitution non è realistica. In questi casi, la resilienza deve venire da continuity arrangements, contingency planning, protezione contrattuale, monitoring e accettazione formale del residual risk.
L'obiettivo non è eliminare ogni dipendenza.
Sarebbe irrealistico.
L'obiettivo è sapere quali dipendenze contano, cosa si rompe quando falliscono, quanto tempo richiede il recovery, chi owns la risposta e quale evidence sostiene la risposta.
Un provider supervisionato non è la stessa cosa di un'istituzione resiliente.
La resilienza inizia quando il board può porre la domanda — e ricevere una risposta mappata, testata e governabile.