Business Continuity Testing e Resilienza Operativa secondo DORA

Il Digital Operational Resilience Act (DORA) introduce un nuovo approccio alla sicurezza informatica, spostando il focus dalla sola protezione del perimetro alla capacità di continuare le operazioni anche in presenza di incidenti. Il business continuity testing DORA è così trasformato in un processo di validazione strutturato che coinvolge governance, processi e fornitori terzi. Il Regolamento Delegato (UE) 2024/1774 descrive i criteri secondo cui i test devono garantire la conformità dei sistemi di ripristino agli standard regolamentari.

Continuità e resilienza in DORA

DORA impone alle entità finanziarie di integrare una politica di continuità operativa ICT nel proprio quadro di gestione dei rischi. Il business continuity testing secondo DORA verifica sia la validità dei piani di risposta sia la possibilità reale di sostenere la vitalità del business fino al ripristino delle operazioni critiche.

Come definire scenari di interruzione

I test di business continuity devono basarsi su scenari di interruzione severi ma plausibili, come stabilito dalla normativa:

• Attacchi informatici diretti e corruzione dei dati.
• Indisponibilità di personale chiave o di sedi fisiche (uffici e data center).
• Guasti sostanziali degli asset ICT o dell’infrastruttura di comunicazione.
• Insolvenza o fallimento di fornitori ICT critici.
• Eventi esterni estremi, ad esempio disastri naturali, pandemie o interruzioni prolungate della rete elettrica.

Test di ripristino, failover, backup e comunicazione

• Backup e restore: Le procedure di recupero dei dati devono essere testate almeno annualmente.
• Switchover tecnologici: È necessario testare il failover verso sistemi ridondanti o siti secondari, dimostrando la capacità di funzionare in tale modalità prima del ritorno alla normalità.
• Crisis communication: I test devono mettere alla prova i piani di comunicazione di crisi, verificando la prontezza dei flussi informativi verso stakeholder e autorità.
• Infrastrutture critiche: Per CCP e CSD, il test include obbligatoriamente un sito secondario con rischio geografico distinto.

RTO/RPO: come leggerli correttamente

La normativa distingue chiaramente tra i requisiti di ripristino:

• Recovery Time Objective (RTO): Per funzioni critiche di CCP, CSD e sedi di negoziazione, è imposto un RTO massimo di 2 ore. Per le altre entità, l’RTO viene determinato dalla Business Impact Analysis (BIA).
• Recovery Point Objective (RPO): Rappresenta la massima perdita di dati tollerabile; per le sedi di negoziazione, deve essere prossimo allo zero.
• Registrazione: Ogni funzione che supporta processi critici deve avere RTO e RPO registrati dettagliatamente nel Register of Information.

Dipendenze da fornitori e servizi condivisi

DORA evidenzia il ruolo della catena di approvvigionamento nella resilienza operativa. Il testing di continuità deve includere i servizi erogati da terze parti ICT, con l’obbligo contrattuale della partecipazione dei fornitori ai test di sicurezza e resilienza. È inoltre richiesta la valutazione di rischi politici o di giurisdizione, qualora il fornitore gestisca dati in paesi terzi.

FAQ

• DORA impone sempre test annuali di continuità? I piani di continuità operativa ICT devono essere testati almeno una volta all’anno o a seguito di cambiamenti significativi nell’infrastruttura.
• Esiste un RTO unico per tutte le entità? Solo le infrastrutture di mercato (CCP, CSD, Trading Venues) devono rispettare il limite delle 2 ore. Per le altre entità, l’RTO viene stabilito internamente tramite la BIA, con una giustificazione commisurata al rischio.
• Come dimostrare che il piano è realistico? Serve documentare i risultati dei test, analizzare le carenze e presentare un report all’organo di gestione con le azioni correttive adottate.

Valida la tua resilienza: richiedi il disegno di un programma di business continuity testing conforme a DORA per assicurarti che i tuoi RTO e RPO siano realistici e verificati.