Business Continuity DORA: BIA, RTO, RPO, test e resilienza dei servizi ICT

Risposta rapida

La Business Continuity in ottica DORA non è un documento da aggiornare ogni anno, ma un sistema vivo che collega funzioni aziendali, servizi ICT, fornitori, RTO, RPO, scenari di crisi, test e remediation. La domanda centrale è semplice: se un sistema o un fornitore ICT si interrompe, l’organizzazione sa quali servizi finanziari vengono impattati, entro quando ripristinarli e quali evidenze dimostrano che il piano funziona?

Perché questo tema è importante

DORA nasce dalla consapevolezza che il settore finanziario è fortemente dipendente dalla tecnologia. Un’interruzione ICT non è più solo un problema tecnico: può bloccare servizi, generare reclami, compromettere obblighi contrattuali, danneggiare fiducia e creare impatti sistemici. Per questo la continuità deve essere collegata alla mappa reale dei servizi e non restare separata dall’ICT risk management.

BIA, RTO e RPO sono utili solo se collegati a sistemi e fornitori. Un RTO definito su carta non vale molto se il piano di ripristino non è testato, se il fornitore non garantisce livelli coerenti o se l’organizzazione non sa quali processi dipendono da quel componente.

Quadro normativo e fonti ufficiali

DORA include requisiti di ICT risk management, testing della resilienza digitale, gestione degli incidenti e rischio da terze parti ICT. Le fonti ESA descrivono il digital operational resilience testing come pilastro del framework. In questa prospettiva, la Business Continuity deve dialogare con test tecnici, incidenti, fornitori e governance, perché resilienza digitale significa capacità di continuare o ripristinare servizi critici in caso di disruption ICT.

Le fonti ufficiali da mantenere come riferimento sono il testo del Regolamento (UE) 2022/2554 su EUR-Lex, le pagine delle Autorità europee di vigilanza e le comunicazioni operative nazionali. Per l’Italia, le pagine di Banca d’Italia su incident reporting e Register of Information sono particolarmente importanti per gli intermediari di competenza.

Cosa significa per l’azienda

Per l’azienda, l’integrazione tra Business Continuity e DORA richiede una mappa precisa: funzione aziendale, servizio finanziario, applicativo, infrastruttura, fornitore, dipendenza, RTO, RPO, piano, test e risultato. Solo così il management può capire se le promesse di continuità sono sostenute da misure reali.

La Business Continuity deve inoltre produrre evidenze: piani approvati, risultati dei test, lesson learned, azioni correttive, verifiche sui fornitori, esercitazioni, aggiornamenti post-incidente. Senza evidenze, il piano resta una dichiarazione d’intenti.

Cosa deve fare concretamente l’organizzazione

1. Eseguire o aggiornare la BIA sulle funzioni critiche o importanti.
2. Collegare ogni funzione a servizi ICT, applicazioni, infrastrutture e fornitori.
3. Definire RTO e RPO coerenti con impatto operativo e capacità tecnica reale.
4. Verificare piani di continuità, disaster recovery, comunicazione di crisi ed exit strategy.
5. Programmare test periodici, inclusi scenari su provider, cloud, connettività, dati e applicazioni.
6. Registrare risultati, deviazioni, lesson learned e remediation.
7. Integrare incidenti reali e near miss nel ciclo di miglioramento della continuità.

Tabella operativa di lettura

| Area | Domanda operativa | Evidenza utile | Modulo GAPOFF collegato | |---|---|---|---| | Perimetro | Quali servizi, entità e funzioni sono coinvolti? | Mappa perimetro, owner, servizi ICT e funzioni supportate | DORA Compliance | | Fornitori ICT | Quali provider supportano processi critici o importanti? | Contratti, questionari, classificazione criticità, ROI | Vendor Risk Management | | Incidenti | Come viene gestito e documentato un evento ICT? | Timeline, classificazione, decisioni, report, post-mortem | Incident & Breach Ops | | Continuità | Il servizio può essere ripristinato entro obiettivi definiti? | BIA, RTO/RPO, test, lesson learned, remediation | Business Continuity | | Evidenze | Cosa si può mostrare ad audit, clienti o management? | Evidence pack, audit trail, policy, report periodici | Trust Center |

Esempio pratico

Una SGR indica nel piano di continuità un RTO di quattro ore per il portale investitori. Durante la BIA emerge che il portale dipende da provider cloud, identity provider esterno e sistema documentale. Il test mostra che il ripristino tecnico del portale è possibile, ma l’identity provider non ha un piano di fallback coerente. La remediation DORA non riguarda solo il piano interno: occorre aggiornare il contratto, verificare SLA, predisporre procedura alternativa e ripetere il test.

Errori comuni da evitare

• Tenere separati BIA, asset inventory e vendor management.
• Definire RTO/RPO non verificati con test reali.
• Non includere fornitori ICT negli scenari di continuità.
• Trattare il piano di continuità come documento statico.
• Non aprire remediation dopo test falliti o parziali.
• Non collegare incidenti reali al miglioramento dei piani.

Come GAPOFF aiuta

GAPOFF consente di collegare il modulo Business Continuity al perimetro DORA. La BIA può essere associata a servizi, asset e fornitori; i test possono generare evidenze e remediation; gli incidenti possono aggiornare il rischio residuo; Vendor Risk Management consente di verificare se contratti e SLA supportano gli obiettivi di continuità. Questo approccio rende la continuità misurabile e collegata alla resilienza digitale richiesta da DORA.

Checklist operativa

• BIA aggiornata
• Servizi ICT collegati alle funzioni
• RTO e RPO approvati
• Piani di continuità versionati
• Fornitori inclusi negli scenari
• Test programmati ed eseguiti
• Risultati e lesson learned registrati
• Remediation post-test assegnate

FAQ

DORA richiede una Business Impact Analysis?

DORA richiede una gestione strutturata del rischio ICT e della resilienza operativa digitale. La BIA è uno strumento operativo essenziale per collegare funzioni, impatti e obiettivi di ripristino.

Che relazione c’è tra RTO, RPO e fornitori ICT?

RTO e RPO devono essere coerenti con le capacità tecniche interne ed esterne. Se un fornitore non garantisce tempi compatibili, il piano deve prevedere misure correttive o alternative.

I test di Business Continuity devono essere documentati?

Sì. Senza documentazione di scenario, risultati, deviazioni e remediation, il test non produce un’evidenza utile in ottica audit-ready.

Un incidente reale può sostituire un test?

Può fornire evidenze utili, ma non dovrebbe sostituire completamente una pianificazione di test coerente. L’incidente deve alimentare lesson learned e remediation.

Fonti ufficiali e riferimenti

• EUR-Lex - Regolamento (UE) 2022/2554 DORA
• EIOPA - Digital Operational Resilience Act
• EBA - Digital Operational Resilience Act
• EBA - ITS sul Register of Information
• Banca d'Italia - Comunicazione di gravi incidenti ICT e minacce significative
• Banca d'Italia - Trasmissioni annuali Register of Information dal 2026

Disclaimer legale

Questo contenuto ha finalità informative e di orientamento generale. Non costituisce consulenza legale, tecnica, fiscale o organizzativa personalizzata. Per determinare obblighi, responsabilità e misure applicabili al caso concreto, è necessario svolgere una valutazione specifica con professionisti qualificati e fonti ufficiali aggiornate.

FAQ

DORA richiede una Business Impact Analysis?

DORA richiede una gestione strutturata del rischio ICT e della resilienza operativa digitale. La BIA è uno strumento operativo essenziale per collegare funzioni, impatti e obiettivi di ripristino.

Che relazione c’è tra RTO, RPO e fornitori ICT?

RTO e RPO devono essere coerenti con le capacità tecniche interne ed esterne. Se un fornitore non garantisce tempi compatibili, il piano deve prevedere misure correttive o alternative.

I test di Business Continuity devono essere documentati?

Sì. Senza documentazione di scenario, risultati, deviazioni e remediation, il test non produce un’evidenza utile in ottica audit-ready.

Un incidente reale può sostituire un test?

Può fornire evidenze utili, ma non dovrebbe sostituire completamente una pianificazione di test coerente. L’incidente deve alimentare lesson learned e remediation.