Regolamento DORA e business continuity

Per molte organizzazioni finanziarie il punto critico non è capire se il regolamento DORA e business continuity siano collegati, ma quanto quel collegamento sia già stato tradotto in assetti operativi verificabili. Quando un incidente ICT interrompe servizi essenziali, la differenza non la fa il documento di policy, ma la capacità di mantenere processi, decisioni e tempi di ripristino entro soglie compatibili con obblighi regolatori, clienti e mercato.

DORA non sostituisce la business continuity. La rende però più esigente, più misurabile e molto più integrata con la gestione del rischio ICT, con la supply chain tecnologica e con la capacità di risposta agli incidenti. Per questo il tema non riguarda solo compliance, IT o cyber security. Coinvolge governance, operations, funzioni di controllo, procurement, crisis management e terze parti critiche.

Regolamento DORA e business continuity: il punto di contatto reale

Il Regolamento UE 2022/2554 sulla resilienza operativa digitale impone alle entità finanziarie un impianto strutturato per prevenire, resistere, rispondere e recuperare da incidenti ICT. Labusiness continuityentra in gioco nel momento in cui la resilienza digitale smette di essere una questione tecnica e diventa capacità di continuità del servizio.

Questo passaggio è decisivo. Un piano di continuità costruito solo su scenari tradizionali – indisponibilità sede, guasto infrastrutturale locale, assenza di personale chiave – non è sufficiente se non include la compromissione di piattaforme core, la perdita di integrità dei dati, l’indisponibilità di fornitori cloud o il blocco prolungato di servizi esternalizzati. DORA chiede un approccio che tenga insieme continuità operativa e dipendenze digitali, con logiche di severità, impatto e tolleranza all’interruzione molto più stringenti.

In termini pratici, la business continuity diventa uno dei meccanismi con cui l’organizzazione dimostra di poter sostenere le funzioni critiche anche in presenza di eventi ICT gravi. Ma per essere credibile deve essere coordinata con incident response, disaster recovery, crisis communication e third-party risk management.

Cosa cambia davvero per i programmi di continuità

L’errore più frequente è trattare DORA come un nuovo layer documentale sopra un programma esistente. Funziona raramente. Dove i framework di continuità sono maturi, DORA accelera l’integrazione e alza il livello di evidenza. Dove invece la continuità è stata gestita come adempimento periodico, il regolamento espone rapidamente lacune di governance e di test.

Il primo cambiamento riguarda il perimetro. Non basta più identificare processi critici in modo generico. Occorre collegare business services, risorse ICT, applicazioni, flussi informativi, ruoli decisionali e fornitori terzi in una catena di dipendenze tracciabile. Se un servizio essenziale dipende da un singolo provider o da una piattaforma non ridondata, la vulnerabilità non è teorica. È un elemento di rischio operativo che deve essere compreso, governato e, se necessario, mitigato.

Il secondo cambiamento riguarda le soglie. RTO e RPO non possono essere valori storici mai rimessi in discussione. Devono riflettere l’effettiva tolleranza all’interruzione del servizio, gli impatti regolatori e reputazionali, e la concreta capacità di recovery. In molte organizzazioni il divario emerge proprio qui: obiettivi di ripristino formalmente approvati, ma non sostenuti da architetture, procedure e ruoli adeguati.

Il terzo cambiamento riguarda la prova. DORA spinge verso una resilienza dimostrabile. Questo significa esercitazioni più aderenti agli scenari reali, verifica delle dipendenze esterne, simulazioni di escalation, validazione dei tempi decisionali e controllo sull’efficacia delle comunicazioni in crisi. Un piano che esiste ma non regge in esercitazione non produce resilienza. Produce una falsa percezione di controllo.

Governance, ruoli e accountability

Uno degli aspetti più rilevanti del regolamento è la responsabilizzazione del management body. La resilienza operativa digitale non può essere delegata integralmente alle funzioni tecniche. Questo ha un impatto diretto anche sui programmi di business continuity.

Quando le responsabilità sono distribuite in modo ambiguo, i tempi di risposta si allungano e le decisioni critiche si bloccano. Serve quindi una governance chiara: chi decide il passaggio in modalità crisi, chi autorizza workaround e soluzioni degradate, chi valuta il ritorno alla normalità, chi interagisce con autorità, clienti e stakeholder strategici. La business continuity, in questo contesto, non è solocontinuità del processo. È capacità di comando e controllo.

Va poi evitata una sovrapposizione improduttiva tra funzioni. Information security, IT operations, operational risk, compliance e business continuity devono mantenere competenze distinte, ma lavorare su un modello coerente. Se ogni funzione valuta criticità, impatti e priorità con metriche diverse, il sistema perde efficacia proprio quando dovrebbe accelerare.

Business impact analysise mappatura delle dipendenze ICT

La BIA resta uno strumento centrale, ma sotto DORA deve evolvere. Non è più sufficiente raccogliere dati sui tempi massimi di fermo o sulle attività manuali alternative. Occorre una lettura più profonda delle dipendenze digitali che sostengono i servizi essenziali.

Questo comporta almeno tre attenzioni. La prima riguarda la granularità: un servizio può apparire presidiate da più applicazioni, ma essere di fatto esposto a un singolo punto di fallimento, come un identity provider, un middleware, un data repository o un vendor esterno. La seconda riguarda l’integrità del dato: in alcuni scenari il problema non è l’indisponibilità, ma la non affidabilità dell’informazione. La terza riguarda le interdipendenze tra processi, che in caso di incidente cyber tendono a propagare l’impatto ben oltre il perimetro iniziale.

Una BIA aggiornata in ottica DORA deve quindi mettere in relazione processi critici, servizi importanti, asset ICT, dipendenze esterne e livelli di tolleranza. È un lavoro tecnico e organizzativo insieme. Se svolto superficialmente, compromette l’intera catena di pianificazione.

Testing: il banco di prova del regolamento DORA e business continuity

Sul testing si misura la maturità reale dell’organizzazione. DORA richiede programmi di test proporzionati a dimensione, profilo di rischio e complessità operativa. Per la business continuity questo significa uscire dalla logica del test formale a calendario e passare a una logica di verifica sostanziale.

Una tabletop ben progettata può essere utile per validare ruoli, escalation e comunicazione. Non basta però a dimostrare la capacità di recovery su servizi digitali complessi. Servono anche prove tecniche, failover controllati, esercitazioni cross-funzionali e scenari che includano terze parti, indisponibilità prolungata, corruzione del dato e decisioni in condizioni di informazione incompleta.

C’è poi un elemento spesso trascurato: il test non serve solo a confermare che qualcosa funziona. Serve a trovare dove non funziona. Per questo i risultati devono tradursi in remediation, priorità di investimento e riesame dei piani. Se l’organizzazione esegue test ma non corregge i gap emersi, resta conforme solo in apparenza.

Terze parti ICT e continuità del servizio

DORA dedica grande attenzione ai fornitori terzi ICT, ed è una scelta coerente con la realtà operativa del settore finanziario. Molte interruzioni significative non nascono da un guasto interno, ma da dipendenze esternalizzate scarsamente presidiate.

Per la business continuity questo significa che i piani non possono fermarsi al perimetro aziendale. Devono considerare tempi di risposta dei fornitori, modalità di escalation, accesso alle informazioni durante l’incidente, clausole contrattuali, opzioni di exit e sostenibilità delle alternative. Non sempre esiste una soluzione ridondante economicamente giustificabile. Ma il rischio va almeno compreso e accettato consapevolmente, non scoperto durante la crisi.

È qui che l’approccio metodologico fa la differenza. Un assessment serio delle dipendenze critiche consente di distinguere tra rischio trasferibile, rischio mitigabile e rischio che richiede vera capacità di continuità interna. Continuitaly lavora spesso proprio su questa intersezione tra compliance, preparedness operativa e valutazione concreta delle esposizioni.

Dalla conformità alla resilienza operativa

L’obiettivo non è produrre più documenti. È costruire un sistema che continui a funzionare, anche in modo degradato, quando la componente digitale entra in stress. Questo richiede coerenza tra policy, architetture, ruoli, test e reporting. Richiede anche una certa onestà organizzativa: non tutte le strutture hanno lo stesso livello di maturità, e non tutti i gap si chiudono in tempi brevi.

Per alcune realtà la priorità sarà riallineare la governance e chiarire le accountability. Per altre sarà rivedere BIA e strategie di recovery. Per altre ancora il punto critico sarà la dipendenza da terze parti o la scarsa integrazione tra crisis management e incident response. DORA non impone una soluzione unica. Impone però che il modello scelto sia proporzionato, tracciabile e difendibile.

Quando regolamento DORA e business continuity vengono affrontati come discipline separate, il risultato è una conformità fragile. Quando invece vengono integrati in un programma di resilienza operativa, l’organizzazione migliora la propria capacità di risposta, riduce l’incertezza decisionale e rende più credibile il presidio del rischio verso autorità, clienti e mercato.

Il valore, alla fine, non sta nell’avere un piano in più. Sta nel sapere quali servizi devono restare in piedi, per quanto tempo, con quali risorse e sotto quale governo decisionale quando l’incidente non è più un’ipotesi ma un fatto operativo.

This post is also available in: