The Digital Operational Resilience Act (DORA) è un regolamento dell'Unione Europea che affronta un problema sistemico nella vigilanza finanziaria. Per decenni, la regolamentazione si è concentrata principalmente sull'adeguatezza patrimoniale, non sui sistemi tecnologici che sostengono il settore finanziario. DORA stabilisce un quadro vincolante e comprensivo per garantire che questi sistemi siano resiliente quanto le istituzioni che supportano.
A partire dal 17 January 2025, DORA diventa lo standard applicabile su come le entità finanziarie e i loro fornitori tecnologici critici gestiscono il rischio digitale, gestiscono gli incidenti operativi e dimostrano la loro capacità di resistere alle interruzioni.
Perché DORA è un cambiamento fondamentale nella regolamentazione finanziaria
Storicamente, la principale mitigazione del rischio sistemico erano le riserve di capitale. Man mano che la finanza è diventata inseparabile dalla tecnologia, questo non è più sufficiente. Un guasto critico di sistema, una violazione dei dati o un attacco informatico coordinato possono ora generare instabilità finanziaria su una scala precedentemente associata ai crolli di mercato.
DORA rappresenta un passaggio dall'attenzione sulla solvibilità finanziaria all'ingegneria e alla governance della tecnologia resiliente. Non è un altro elenco di controllo per la conformità. Come quadro giuridico specializzato (lex specialis), eleva la resilienza operativa digitale da una questione funzionale dell'IT a un pilastro centrale della stabilità finanziaria.
Lo scopo del regolamento è sostituire un panorama frammentato di linee guida nazionali con un unico insieme armonizzato di regole per quasi tutti i partecipanti al mercato finanziario dell'UE, inclusi:
- Banche e istituti di credito
- Società di investimento
- Imprese di assicurazione e riassicurazione
- Fornitori di servizi relativi a crypto-asset
- Fornitori critici di servizi ICT da terze parti
Dalle politiche all'ingegneria e alla governance
DORA considera la conformità come una disciplina di ingegneria. Richiede prove verificabili di resilienza, non solo politiche ben documentate. Questo richiede un approccio sistemico in cui le evidenze dell'efficacia dei controlli siano un output naturale di processi governati.
Il settore finanziario sta già investendo ingenti risorse per soddisfare questi requisiti. Secondo i risultati di un sondaggio sui costi di conformità a DORA, 38% delle organizzazioni UE ha speso oltre €1 milione per le preparazioni negli ultimi due anni. Questi investimenti sono destinati a costruire robusti framework di rischio, eseguire test di resilienza avanzati e stabilire un controllo rigoroso sui fornitori terzi.
DORA deve essere compreso nel contesto di altre normative, come la direttiva NIS2. Mentre NIS2 stabilisce una baseline ampia di cybersecurity in diversi settori, DORA impone requisiti molto più specifici e stringenti adattati all'importanza sistemica dell'industria finanziaria.
In definitiva, DORA sposta la resilienza operativa da una funzione di back-office alla responsabilità del consiglio di amministrazione. Richiede una struttura in cui l'evidenza è un sottoprodotto naturale di una sana governance, non un artefatto assemblato per un audit. Questo approccio strutturato è centrale per il moderno enterprise risk management, che ora dipende intrinsecamente dalla resilienza operativa digitale. Comprendere il "perché" dietro il disegno di DORA chiarisce il "come" della sua implementazione.
I cinque pilastri fondamentali di DORA
Il Digital Operational Resilience Act è strutturato attorno a cinque pilastri fondamentali. Questi non sono flussi di lavoro discreti ma discipline interconnesse che insieme formano un quadro completo per la gestione del rischio digitale. Una implementazione efficace richiede la comprensione di come questi pilastri funzionino come un sistema integrato.
A livello strategico, DORA ha tre obiettivi primari: armonizzare gli standard in tutta l'UE, elevare le capacità di resilienza all'interno delle entità finanziarie e stabilizzare il sistema finanziario contro le minacce digitali.
Questi obiettivi sono tradotti in obblighi concreti attraverso i cinque pilastri. Il seguente riassunto descrive il requisito principale di ciascun pilastro e un esempio pratico della sua implementazione.
I cinque pilastri di DORA e requisiti chiave
| Pillar | Core Obligation | Practical Example |
|---|---|---|
| 1. ICT Risk Management | Stabilire e mantenere un framework completo di gestione del rischio ICT con responsabilità chiare definite a livello dell'organo di gestione. | Il consiglio approva formalmente una policy di gestione del rischio che mappa le funzioni critiche di business ai sistemi ICT sottostanti e assegna una proprietà specifica per ciascuna area di rischio. |
| 2. ICT-Related Incident Management | Implementare un processo standardizzato per rilevare, gestire, classificare e segnalare i principali incidenti ICT alle autorità competenti. | Quando si verifica un'interruzione del sistema di elaborazione dei pagamenti, un allarme automatico attiva un piano di risposta predefinito. L'incidente viene classificato in base a criteri come l'impatto sul volume delle transazioni e la durata per determinare se raggiunge la soglia per la segnalazione normativa. |
| 3. Digital Operational Resilience Testing | Condurre un programma di test di resilienza basato sul rischio, inclusi avanzati Threat-Led Penetration Testing (TLPT) per entità designate critiche. | Un red team esterno, utilizzando threat intelligence su avversari reali, tenta di compromettere la piattaforma bancaria core dell'azienda per testare non solo i controlli tecnici di sicurezza ma anche le capacità di rilevamento, risposta e recupero del team operativo. |
| 4. Managing ICT Third-Party Risk | Governare l'intero ciclo di vita delle dipendenze dai fornitori terzi, dalla due diligence e dagli accordi contrattuali alle strategie di uscita, con un focus specifico sui fornitori critici. | Prima di contrattare un nuovo fornitore di servizi cloud, l'azienda esegue una valutazione del rischio e assicura che il contratto includa clausole specifiche che garantiscano diritti di audit e definiscano un piano di uscita testato e praticabile. |
| 5. Information and Intelligence Sharing | Partecipare ad accordi fiduciari per condividere e ricevere cyber threat intelligence e informazioni sulle vulnerabilità con altre entità finanziarie. | Un team di sicurezza riceve un avviso su una nuova variante di malware che prende di mira le istituzioni finanziarie tramite un forum di condivisione di informazioni fidato e implementa proattivamente contromisure prima che l'azienda venga presa di mira. |
Questa tabella illustra come DORA colleghi la governance di alto livello direttamente alle attività operative. Ogni pilastro merita un esame più approfondito.
Pilastro 1: Gestione del rischio ICT
Questa è la base di DORA. Richiede a ogni entità di stabilire, documentare e mantenere un framework di gestione del rischio ICT solido, completo e ben documentato. Non si tratta di un documento di policy statico ma di un sistema vivente di governance e controllo. Il suo scopo è fornire all'organizzazione la capacità di identificare, classificare, proteggere e mitigare i rischi su tutti gli asset di informazione e comunicazione tecnologica. L'organo di gestione — il consiglio di amministrazione — è in ultima istanza responsabile di questo framework e deve garantirne l'integrazione nella strategia di rischio complessiva dell'azienda.
Pilastro 2: Gestione degli incidenti correlati all'ICT
Questo pilastro specifica i requisiti per quando il rischio si materializza. Impone un processo coerente per rilevare, gestire e segnalare gli incidenti correlati all'ICT. DORA è prescrittiva, richiedendo alle aziende di classificare gli incidenti in base a criteri come il numero di utenti interessati, la durata dell'incidente e la sua portata geografica. Un requisito centrale è la segnalazione dei major ICT-related incidents alle autorità competenti utilizzando un template comune. Questo crea un circuito di feedback che consente ai regolatori di ottenere una visione settoriale delle minacce e coordinare una risposta più efficace.
Pilastro 3: Test di resilienza operativa digitale
Questo pilastro riguarda la verifica. Impone un programma di testing proporzionato e basato sul rischio per convalidare che il framework di gestione del rischio ICT sia efficace. Per la maggior parte delle entità, questo include una gamma di attività da valutazioni di vulnerabilità a test più complessi basati su scenari. Per le aziende designate come critiche, DORA richiede Threat-Led Penetration Testing (TLPT) almeno ogni tre anni. Questo non è un penetration test standard; è un'esercitazione guidata dall'intelligence che simula tattiche, tecniche e procedure di attori di minaccia rilevanti e reali per fornire una valutazione obiettiva delle capacità difensive, di rilevamento e di risposta.
Pilastro 4: Gestione del rischio ICT dei terzi
DORA pone un'enfasi significativa sui rischi originati dalla supply chain, in particolare dall'affidamento a fornitori terzi ICT come le piattaforme cloud. Questo pilastro richiede alle entità di eseguire una due diligence completa prima di entrare in nuovi accordi. I contratti devono contenere clausole specifiche che coprano standard di sicurezza, diritti di audit e strategie di uscita praticabili. Introduce inoltre un quadro di supervisione per i Critical Third-Party Providers (CTPPs), che saranno supervisionati direttamente dalle autorità europee. Ciò significa che un'entità finanziaria è responsabile non solo della propria resilienza ma anche di assicurarsi che i suoi fornitori critici soddisfino gli standard di DORA tramite monitoraggio continuo ed evidenze.
Pilastro 5: Condivisione di informazioni e intelligence
L'ultimo pilastro formalizza il principio della difesa collaborativa. Incoraggia le entità finanziarie a stabilire accordi per condividere informazioni e intelligence sulle minacce informatiche. L'obiettivo è costruire una difesa collettiva in cui le aziende possano apprendere dagli incidenti reciproci e rafforzare proattivamente i loro controlli contro le minacce emergenti. Questa condivisione è intesa avvenire all'interno di comunità fidate, rafforzando la resilienza collettiva dell'intero settore finanziario e spostando l'industria da una postura reattiva a una proattiva.
I dati del settore indicano un divario significativo tra i requisiti e la prontezza. Un sondaggio Deloitte dei primi mesi del 2025 ha rilevato che mentre il 48% delle aziende si sentiva preparato per la gestione degli incidenti, solo il 25% era fiducioso nel pilastro fondamentale della gestione del rischio ICT. Le percentuali per i test di resilienza e il rischio dei terzi erano ancora più basse, con solo l'8% che riportava piena conformità. Puoi esplorare i risultati completi del sondaggio DORA di Deloitte per una visione dettagliata della preparazione del settore.
Gestire il rischio ICT dei terzi secondo DORA
Per la maggior parte delle entità finanziarie, i requisiti di DORA per il rischio ICT dei terzi rappresentano la sfida operativa più significativa. Questa non è una funzione di procurement; è una disciplina centrale della strategia di resilienza operativa. Comprendere i principi della third-party risk management nel contesto di DORA è quindi critico.
Il regolamento impone un approccio a ciclo di vita completo per la gestione dei fornitori. La responsabilità inizia prima della firma di un contratto e si estende oltre la sua cessazione. Comporta l'inserimento dei requisiti di resilienza in ogni fase della relazione con i fornitori tecnologici, da un vendor di software a un fornitore di servizi cloud che ospita infrastrutture core.
Si applica il principio di proporzionalità. Il livello di scrutinio applicato a un fornitore deve essere commisurato al rischio che esso rappresenta. Un vendor che fornisce uno strumento interno non critico non richiede lo stesso livello di supervisione di un fornitore cloud che ospita una piattaforma bancaria core.
Requisiti pre-contrattuali e contrattuali
Prima di ingaggiare un nuovo fornitore ICT, DORA impone un processo di due diligence accurato. Questo va oltre i controlli sulla stabilità finanziaria e comprende una valutazione dettagliata della resilienza operativa del fornitore, dei suoi controlli di sicurezza e dei processi di gestione degli incidenti. La domanda centrale è se il fornitore può soddisfare le rigorose esigenze del settore finanziario. Ciò comporta la revisione di certificazioni, report di audit e capacità di risposta agli incidenti. Un efficace due diligence questionnaire è uno strumento essenziale per strutturare questa valutazione.
Una volta completata la due diligence, il contratto diventa lo strumento chiave per far rispettare la resilienza. DORA specifica diverse clausole obbligatorie, tra cui:
- Unrestricted Access and Audit Rights: L'entità finanziaria, i suoi revisori e le autorità competenti devono avere il diritto di ispezionare e auditare le operazioni del fornitore relative al servizio.
- Clear Service Level Descriptions: Gli accordi devono definire obiettivi di performance precisi, in particolare per disponibilità e sicurezza.
- Incident Reporting Obligations: I fornitori devono notificare all'entità finanziaria qualsiasi incidente che possa influire sui servizi forniti.
- Cooperation with Authorities: Il contratto deve obbligare il fornitore a cooperare con le autorità competenti dell'entità finanziaria e con le European Supervisory Authorities (ESAs).
- Defined Exit Strategies: Il contratto deve delineare un processo chiaro per la terminazione dell'accordo e la migrazione di dati e servizi senza causare interruzioni operative.
Supervisione continua e strategie di uscita
Il contratto firmato segna l'inizio della supervisione continua, non la sua conclusione. DORA richiede il monitoraggio continuo dei fornitori, in particolare di quelli che supportano funzioni critiche o importanti. Ciò comporta la verifica delle prestazioni rispetto agli SLA, la rivalutazione dei profili di rischio e l'assicurazione della conformità continua.
Un punto focale è la gestione del rischio di concentrazione — il pericolo sistemico dell'eccessiva dipendenza da un singolo fornitore. Le entità finanziarie devono identificare e gestire i rischi associati a dipendere troppo da un fornitore unico, in particolare quelli designati come Critical Third-Party Providers (CTPPs).
DORA non richiede solo che le entità considerino le strategie di uscita; esige che le sviluppino e le testino per ogni fornitore ICT critico. Questo non è un esercizio teorico. Richiede un piano pratico e documentato per la transizione a un fornitore alternativo o per riportare il servizio internamente senza significative interruzioni delle operazioni.
Questo piano deve coprire la portabilità dei dati, il trasferimento delle conoscenze e le procedure tecniche per una transizione controllata. Per i CTPP, i requisiti sono ancora più stringenti, riflettendo la loro importanza sistemica per il sistema finanziario dell'UE. Questa prospettiva a livello di sistema è un principio fondamentale del quadro del Digital Operational Resilience Act DORA.
Stabilire governance e responsabilità per DORA
Il Digital Operational Resilience Act (DORA) non è un esercizio di carta. Considera la conformità come una disciplina di ingegneria e governance, ponendo la responsabilità ultima al livello più alto dell'organizzazione.
Secondo DORA, il management body — il consiglio di amministrazione o suo equivalente — è direttamente ed esplicitamente responsabile. Deve approvare, supervisionare e riesaminare regolarmente il framework di gestione del rischio ICT dell'organizzazione.
Questo modello di governance top-down è un principio centrale del regolamento. È progettato per integrare la resilienza digitale direttamente nella strategia di rischio e negli obiettivi aziendali dell'organizzazione, spostandola oltre la sola sfera del dipartimento IT. Il ruolo del consiglio non è passivo; ci si aspetta che indirizzi e metta in discussione attivamente la postura di resilienza dell'organizzazione.
Cascading della responsabilità attraverso l'organizzazione
Dal management body, la responsabilità si propaga ai ruoli operativi chiave. CISOs, responsabili IT e officer del rischio sono responsabili dell'implementazione e della gestione del framework approvato dal consiglio. La loro funzione è tradurre le policy ad alto livello in sistemi, processi e controlli efficaci.
Questa struttura richiede una catena di proprietà documentata e ininterrotta. Assegnare un compito non è sufficiente; deve esserci una linea tracciabile di responsabilità per ogni controllo e politica. Questo riflette l'approccio ingegneristico alla governance richiesto da DORA.
Definire la proprietà e garantire la tracciabilità
Il primo passo pratico è stabilire una proprietà univoca. Un metodo efficace per questo è la creazione e la manutenzione di una ownership matrix. Questa non è una semplice lista di nomi ma una mappa di governance che collega responsabilità a individui e comitati.
Una ownership matrix efficace chiarisce:
- Chi possiede il rischio: La persona o il comitato responsabile di una specifica area di rischio.
- Chi possiede il controllo: L'individuo responsabile di garantire che un controllo sia implementato, gestito e che la sua efficacia sia dimostrata.
- Chi esegue il compito: Il team o la persona che esegue il lavoro quotidiano associato a un controllo.
Questa chiarezza elimina ambiguità e lacune di responsabilità. Durante un incidente o un audit, fornisce una risposta definitiva alla domanda: "Chi è responsabile di questo?"
Un altro componente critico è il collegamento diretto delle policy ai controlli tecnici che le applicano. Una policy che esiste solo in un documento non è conforme ai principi di DORA; deve collegarsi a una implementazione reale e verificabile.
La distinzione tra automazione e responsabilità
La conformità moderna si basa su strumenti e automazione per la raccolta delle evidenze, il monitoraggio dei controlli e la generazione di report su scala. Tuttavia, è un errore critico confondere l'automazione con la responsabilità.
Uno strumento può automatizzare la raccolta dei log da un firewall, ma non può essere ritenuto responsabile per il set di regole del firewall stesso. Un sistema può generare un alert, ma una persona deve essere responsabile del piano di risposta all'incidente che ne consegue. La responsabilità ricade sempre su una persona.
Questa distinzione è fondamentale per il modello di governance richiesto dal Digital Operational Resilience Act DORA. Gli strumenti sono strumenti che supportano la supervisione umana; non la sostituiscono. Le evidenze raccolte da questi sistemi sono utili solo quando fanno parte di un processo governato da una chiara responsabilità umana. Per ogni asserzione di conformità, deve esserci una linea tracciabile che rimandi a una policy, a un controllo, a un proprietario e alle prove che ne dimostrano il funzionamento come previsto. Questa è l'essenza di un sistema resiliente e auditabile.
Un framework pratico per l'implementazione e le evidenze
La transizione dal testo normativo alla realtà operativa è una sfida di ingegneria, non amministrativa. La conformità al Digital Operational Resilience Act (DORA) è una disciplina continua, non un progetto una tantum. L'obiettivo non è semplicemente superare un audit ma dimostrare che i sistemi sono verificabilmente resilienti.
Il processo inizia con un gap analysis. Questo comporta mappare ogni requisito di DORA contro i processi, i controlli e le tecnologie esistenti per identificare le carenze specifiche. L'output è una roadmap precisa per la remissione.
Sulla base di questa analisi si sviluppa un piano di remediation. Si tratta di un documento strategico che prioritizza le azioni in base al rischio, assegna responsabilità chiare e stabilisce scadenze realistiche. Serve come blueprint per lo sforzo di implementazione.
La checklist seguente fornisce una struttura di alto livello per questo processo.
Checklist di implementazione DORA
| Phase | Key Action | Primary Responsibility |
|---|---|---|
| Phase 1: Assessment | Eseguire un'analisi dettagliata delle lacune rispetto a tutti gli articoli di DORA. Mappare controlli, policy e sistemi esistenti ai requisiti. | CISO / Risk Management |
| Phase 2: Planning | Sviluppare un piano di remediation basato sul rischio con timeline definite, proprietari e allocazioni di budget. Prioritizzare prima le lacune critiche. | Management Body / Steering Committee |
| Phase 3: Implementation | Eseguire il piano di remediation. Questo include aggiornare le policy, distribuire nuovi strumenti, ri-architettare sistemi e formare il personale. | IT / Security / Operations Teams |
| Phase 4: Evidence | Stabilire un sistema per la raccolta continua e automatizzata delle evidenze collegato a controlli specifici. | Control Owners / GRC Team |
| Phase 5: Testing | Eseguire il programma di Digital Operational Resilience Testing, inclusi Threat-Led Penetration Testing (TLPT) per le entità applicabili. | Red Team / Third-Party Testers |
| Phase 6: Reporting | Implementare e testare i processi per la segnalazione dei major ICT-related incidents alle autorità competenti entro i tempi previsti. | Incident Response Team / Legal |
| Phase 7: Readiness | Condurre simulazioni di audit interne ed esercitazioni tabletop. Preparare pacchetti di audit on-demand per verificare la prontezza per l'ispezione regolatoria. | Internal Audit / Compliance |
Questa checklist offre un percorso strutturato, ma il lavoro sostanziale risiede nella disciplina della gestione delle evidenze.
La disciplina della raccolta delle evidenze
Al cuore di DORA c'è la prova. Ogni asserzione di resilienza e ogni controllo devono essere supportati da evidenze tangibili. Questo trasforma la conformità da una dichiarazione in una realtà dimostrabile.
La chiave è progettare sistemi in cui l'evidenza sia un output naturale dei processi operativi, non un artefatto creato per un audit. Ciò significa raccogliere, gestire e proteggere in modo sistematico le prove per ogni policy, controllo e test. L'evidenza non è solo un documento PDF; può essere un file di log, uno script di configurazione di sistema, un report di penetration test o una richiesta di modifica firmata.
La gestione delle evidenze secondo DORA deve essere trattata con la stessa rigore della contabilità finanziaria. Ogni pezzo di prova dovrebbe essere versionato, la sua integrità protetta tramite crittografia e la sua storia registrata in una traccia di audit immutabile. Questo assicura che quando i regolatori richiedono prove, si possa fornire un record completo, attendibile e tracciabile.
Un sistema progettato per questo scopo permette ai team di collegare le evidenze criptate direttamente a un controllo specifico, creando una catena infrangibile tra un requisito e la sua prova. Questa struttura è ciò che rende la conformità sistematica possibile e sostenibile. Puoi approfondire come gestire le tue audit evidence per soddisfare questi standard più elevati.
Dalla raccolta continua alla readiness per l'audit
Un programma DORA maturo assicura che le evidenze siano sempre aggiornate e disponibili per l'ispezione. Ciò si ottiene incorporando la raccolta continua delle evidenze nei flussi operativi. Per esempio, quando viene modificata una regola di firewall, il sistema dovrebbe acquisire automaticamente il ticket di modifica e il registro di approvazione come evidenza per il controllo di change management rilevante.
Questa postura abilita una potente capacità: generare un pacchetto di audit completo su richiesta. Un sistema ben progettato può compilare istantaneamente tutte le policy rilevanti, le descrizioni dei controlli e le evidenze con timestamp in un pacchetto organizzato, come un file ZIP sicuro o un report PDF dettagliato, completo di log di accesso che mostrano chi ha consultato cosa e quando.
Questo livello di preparazione cambia fondamentalmente la natura di un audit. Cessa di essere un'indagine in cui un auditor cerca informazioni e diventa un processo di verifica in cui l'auditor rivede un corpo di prove pre-preparato, organizzato e verificabile. Questo è lo stato finale: un sistema che non è solo conforme in teoria, ma dimostrabilmente resiliente nella pratica.
Conclusione: la resilienza come disciplina di ingegneria
Il Digital Operational Resilience Act (DORA) non è solo un'altra normativa. Segna un cambiamento fondamentale nel modo in cui il settore finanziario deve affrontare la stabilità, spostando l'attenzione da politiche astratte all'ingegneria di sistemi verificabili e resilienti.
La vera conformità non riguarda la produzione di documentazione per un audit. Riguarda la costruzione di operazioni in cui l'evidenza di resilienza è un output naturale e continuo.
Ciò richiede un cambiamento di mentalità. DORA considera la conformità come una disciplina di ingegneria e governance fondata su tre principi chiave: evidenza, tracciabilità e responsabilità. Ogni controllo deve essere collegato a un requisito specifico, ogni requisito deve avere un proprietario e ogni asserzione deve essere supportata da una prova.
Dal testo legale alla realtà operativa
Per CISOs, responsabili IT e professionisti del rischio, DORA è un mandato chiaro a guidare. Il ruolo è tradurre i requisiti del regolamento nella realtà pratica delle operazioni quotidiane.
Questo significa costruire sistemi e processi che non siano solo robusti ma anche trasparentemente auditabili. L'obiettivo è creare un quadro in cui un audit diventi una semplice verifica di un sistema continuamente dimostrato, non un esercizio dirompente e dell'ultimo minuto.
DORA riguarda, in ultima analisi, la preparazione a una reale interruzione, non solo il superamento di controlli regolatori. L'ingegneria della resilienza è la pratica di garantire che le tue funzioni critiche possano resistere alle minacce del mondo reale, con le prove per dimostrarlo.
L'attenzione deve rimanere su come i sistemi e i processi funzionano effettivamente. Questo comporta la mappatura delle dipendenze tra servizi di business e gli asset ICT da cui dipendono, garantire che la responsabilità sia chiaramente assegnata e verificare che i controlli funzionino come previsto. La responsabilità non può essere delegata a uno strumento; rimane un imperativo umano, supportato da sistemi ben governati.
Adottando questo approccio ingegneristico, le organizzazioni possono andare oltre la conformità normativa per costruire una resilienza operativa duratura che offra reale stabilità. Il Digital Operational Resilience Act (DORA) non è la destinazione; è la blueprint per raggiungerla.
Domande frequenti su DORA
Man mano che DORA passa dalla normativa alla realtà, solleva domande pratiche per i leader IT e compliance. Ecco risposte dirette alle più comuni.
Qual è la scadenza per la conformità a DORA?
La scadenza per la conformità è 17 January 2025. Questa è la data in cui il regolamento diventa pienamente applicabile e applicabile in tutta l'Unione Europea. Il periodo di implementazione di due anni termina a questa data e le autorità competenti nazionali avranno il potere di supervisionare e sanzionare la non conformità da questo giorno in poi.
DORA si applica ai miei fornitori cloud?
Sì, indirettamente e, per alcuni, direttamente. La tua organizzazione è pienamente responsabile di garantire che i suoi fornitori ICT terzi, inclusi i servizi cloud, soddisfino gli standard di DORA. Questo è fatto valere tramite la due diligence obbligatoria e clausole contrattuali specifiche.
Tuttavia, i fornitori designati come Critical Third-Party Providers (CTPPs) dalle European Supervisory Authorities (ESAs) subiranno anche una supervisione diretta. I regolatori avranno il potere di emettere raccomandazioni, imporre sanzioni e, in casi di grave non conformità, richiedere alle entità finanziarie di sospendere o terminare l'uso dei loro servizi.
DORA è solo una versione UE di altre normative sulla cybersecurity?
No. Questo è un fraintendimento comune. Sebbene DORA condivida obiettivi con quadri come la direttiva NIS2, è lex specialis — una legge specializzata per il settore finanziario. I suoi requisiti sono significativamente più prescrittivi rispetto alle normative generali di cybersecurity. Per esempio, DORA impone clausole contrattuali specifiche per gli accordi con terzi e richiede avanzati Threat-Led Penetration Testing (TLPT) per le aziende critiche. Questi obblighi vanno ben oltre i requisiti generali di altri quadri. L'obiettivo di DORA è singolare: la stabilità operativa del sistema finanziario.
Chi è in ultima analisi responsabile della conformità a DORA?
Il management body — il Consiglio di Amministrazione o suo equivalente — è in ultima istanza e in maniera non delegabile responsabile della conformità a DORA.
Mentre i CISOs e i team IT eseguono il lavoro quotidiano, il consiglio detiene la responsabilità ultima per l'intero framework di gestione del rischio ICT. È responsabile della sua approvazione, della sua supervisione e della sua efficacia.
Questo è un principio chiave di DORA, progettato per elevare la resilienza digitale da una funzione IT a un rischio aziendale primario governato al più alto livello dell'organizzazione. Il consiglio deve dirigere, mettere in discussione e allocare risorse attivamente alla postura di resilienza dell'organizzazione.
AuditReady provides an operational evidence toolkit to help your organisation build a robust and verifiable compliance posture for the Digital Operational Resilience Act DORA. Our platform enables you to define ownership, link encrypted evidence directly to controls, and generate audit-ready packs on demand, turning compliance into a systematic and continuous discipline. Discover how we can support your audit readiness at https://audit-ready.eu/?lang=en.