Il tuo certificato ISO 27001 non fa partire i cronometri di DORA
Le entità finanziarie continuano a mappare i controlli ISO 27001 sugli articoli di DORA e a considerare il resto come semplice documentazione. Le vere aggiunte di DORA sono invece obblighi che devono essere eseguiti, secondo specifiche e su un cronometro, cosa che un certificato non è stato progettato per verificare.

Un modo comune per avviare un programma DORA è partire da un foglio di calcolo. Una colonna elenca i requisiti del Regolamento (UE) 2022/2554, un'altra i controlli dell'Annex A della ISO/IEC 27001:2022 che l'azienda ha già implementato nel proprio ISMS certificato, e una terza registra la sovrapposizione. Quando la mappatura è completata, la sovrapposizione è ampia: gestione del rischio ICT, controllo degli accessi, gestione dei fornitori, continuità operativa, gestione degli incidenti. Il resto può sembrare un semplice esercizio di scrittura basato su un certificato esistente.
Questa impostazione è la trappola. Non è sbagliata sulla sovrapposizione, che è reale. È sbagliata su cosa sia il resto. Le parti di DORA che un'azienda certificata ISO 27001 non ha già fatto non sono semplicemente documentazione da scrivere. Diverse di esse sono obblighi che devono essere eseguiti, secondo specifiche e su un cronometro, e un certificato è lo strumento sbagliato per dimostrarli.
Un certificato attesta un sistema definito; una regolamentazione impone obblighi
La ISO/IEC 27001:2022 certifica che un sistema di gestione della sicurezza delle informazioni di un ambito definito soddisfa i requisiti dello standard. La certificazione non è un momento singolo: un organismo di certificazione rilascia il certificato dopo un audit e lo mantiene tipicamente per un ciclo di tre anni di audit di sorveglianza e ricertificazione. Due elementi che lo accompagnano sono rilevanti in questo contesto. L'oggetto certificato è un sistema di gestione, delimitato dalla dichiarazione di ambito, e la domanda di certificazione riguarda la conformità: il sistema di gestione soddisfa i requisiti?
DORA non funziona così. Si applica alle entità finanziarie direttamente dal 17 gennaio 2025 (Regolamento (UE) 2022/2554), e le sue disposizioni non sono un sistema di gestione a cui conformarsi, ma obblighi da eseguire, diversi dei quali sono temporizzati e specificati. Puoi detenere un certificato ISO 27001 valido, in ambito e aggiornato, e violare comunque DORA, perché il certificato risponde a una domanda che DORA non pone. Tre degli obblighi di DORA funzionano su cronometri o secondo specifiche che un certificato non ha mai testato; un quarto sposta l'onere della responsabilità in un ambito che un certificato non verifica mai.
Il registro
L'Articolo 28(3) richiede a un'entità finanziaria di mantenere un registro delle informazioni relative agli accordi contrattuali per l'uso di servizi ICT forniti da fornitori di servizi ICT di terze parti e di segnalare le informazioni su tali accordi alla propria autorità competente almeno una volta all'anno. Il registro è un artefatto strutturato, non un documento libero: il Regolamento di Esecuzione (UE) 2024/2956 della Commissione, pubblicato nella Gazzetta Ufficiale il 2 dicembre 2024, stabilisce i modelli standard e i campi dati. Secondo le disposizioni di segnalazione delle Autorità Europee di Vigilanza, le autorità competenti raccolgono questi registri dalle entità supervisionate e li inviano alle AES, con la prima raccolta prevista nel 2025.
Un'azienda certificata gestisce già i propri fornitori ICT tramite i controlli dell'Annex A come A.5.19 a A.5.23, selezionati attraverso il trattamento del rischio e registrati nella Dichiarazione di Applicabilità. Ciò che questo non produce automaticamente è un registro nello schema prescritto, popolato con i campi dati di DORA, allineato ai contratti effettivi dell'azienda e reso disponibile al supervisore secondo il ciclo di raccolta. Gestire i fornitori e rendere disponibile un artefatto strutturato specifico a un regolatore sono obblighi diversi, e il secondo non è dimostrato dal primo.
Il cronometro degli incidenti
L'Articolo 19 obbliga le entità finanziarie a segnalare gli incidenti ICT rilevanti alle autorità competenti, e lo standard tecnico fissa i timer. Il Regolamento Delegato (UE) 2025/301 della Commissione del 23 ottobre 2024 richiede una notifica iniziale entro quattro ore dalla classificazione dell'incidente come rilevante e, di norma, non oltre 24 ore dal momento in cui l'entità ne è venuta a conoscenza; un rapporto intermedio entro 72 ore da tale notifica iniziale; e un rapporto finale entro un mese dal rapporto intermedio (o dall'ultimo rapporto intermedio aggiornato). Se un incidente sia "rilevante" o meno viene deciso dai criteri di classificazione del Regolamento Delegato (UE) 2024/1772 della Commissione.
Il punto di riferimento merita di essere letto due volte. Il cronometro di quattro ore di DORA parte dal momento in cui un incidente viene classificato come rilevante, il che rende la classificazione accurata e tempestiva parte dell'obbligo piuttosto che una premessa. Questa è una struttura diversa dagli obblighi di segnalazione di incidenti che le squadre finanziarie già conoscono: l'avviso precoce di NIS2 scatta entro 24 ore dal momento in cui si viene a conoscenza di un incidente significativo (Direttiva (UE) 2022/2555, Articolo 23), e il GDPR richiede a un titolare del trattamento di segnalare una violazione dei dati personali che rischia i diritti degli interessati senza indebito ritardo e, ove possibile, entro 72 ore dal momento in cui ne viene a conoscenza (Regolamento (UE) 2016/679, Articolo 33). Questi cronometri non sono intercambiabili. Tramite i controlli dell'Annex A A.5.24 a A.5.27, un'azienda certificata pianifica, valuta, risponde e impara dagli incidenti di sicurezza delle informazioni attraverso il processo implementato, e un auditor ha accettato tale processo come conforme. Un auditor che accetta che il processo sia conforme non è lo stesso che quel processo produca una segnalazione regolamentare correttamente classificata entro quattro ore dalla classificazione.
L'obbligo di testing
L'Articolo 26 richiede alle entità finanziarie identificate dalle loro autorità competenti, in base a dimensione, profilo di rischio e importanza sistemica, di eseguire test di penetrazione basati su minacce almeno ogni tre anni, su sistemi di produzione live che supportano funzioni critiche o importanti. I tre anni sono un limite minimo che l'autorità competente può modificare, e la metodologia dettagliata e i criteri di identificazione sono stabiliti nel Regolamento Delegato (UE) 2025/1190 della Commissione, applicabile dal 8 luglio 2025. Questo non riguarda tutte le entità finanziarie, e l'identificazione spetta al regolatore. Ma per un'azienda in ambito si tratta di un obbligo ricorrente e documentato di un tipo specifico.
La ISO/IEC 27001 chiede a un'azienda di monitorare, misurare e valutare le prestazioni del proprio ISMS (clausola 9.1) e di eseguire audit interni (clausola 9.2), e il controllo dell'Annex A A.8.29 copre i test di sicurezza nello sviluppo e nell'accettazione. Nessuno di questi, da solo, dimostra un esercizio di red team basato su intelligence contro sistemi di produzione, ripetuto secondo la cadenza di DORA e condotto secondo la metodologia di supervisione. Un'azienda può essere completamente certificata e non aver mai eseguito un test del genere.
La responsabilità che un certificato non raggiunge
L'Articolo 5(2) pone sull'organo di gestione l'obbligo di definire, approvare, supervisionare e essere responsabile del quadro di gestione del rischio ICT, e il punto (a) lo rende "responsabile in ultima istanza della gestione del rischio ICT dell'entità finanziaria". L'Articolo 5(4) aggiunge un obbligo personale: i membri dell'organo di gestione devono mantenere le proprie conoscenze e competenze sufficientemente aggiornate per comprendere e valutare il rischio ICT. Questa è una delle quattro che non è un cronometro. È un obbligo di governance continuo.
La clausola 5.1 della ISO/IEC 27001 richiede già la leadership e l'impegno della direzione, quindi questa è l'area di sovrapposizione più stretta. Il divario è più stretto e specifico del semplice "ISO ignora il consiglio di amministrazione". DORA fissa la responsabilità in ultima istanza sull'"organo di gestione", un termine giuridicamente definito, e impone un obbligo di competenza personale ai suoi membri. La "direzione" di ISO e l'"organo di gestione" di DORA non sono necessariamente le stesse persone, e la certificazione dimostra l'impegno della direzione verso l'ISMS, non la conformità con l'Articolo 5(2)(a) o 5(4). Un certificato può essere ottenuto senza aver mai testato la responsabilità specifica che DORA nomina.
Perché la mappatura nasconde tutti e quattro
Il foglio di calcolo fallisce in modo coerente: confronta il testo di un controllo con un altro, e il peso aggiuntivo di DORA non è solo nel testo. Un controllo recita "l'organizzazione deve gestire gli incidenti di sicurezza delle informazioni", e lo stesso recita l'evidenza ISO dell'azienda, e le celle corrispondono. Ciò che la cella non mostra è che DORA ha aggiunto un cronometro con punto di riferimento, uno schema di registro prescritto, un obbligo di testing almeno ogni tre anni e un organo responsabile nominato legalmente ad attività che ISO descrive come capacità. Due requisiti possono usare parole quasi identiche eppure essere soddisfatti da atti diversi, perché uno chiede se esiste un sistema conforme entro un ambito e l'altro chiede se un obbligo specifico è stato eseguito.
Questa è l'obiezione da prendere seriamente, ed è quella che mantiene molti programmi sulla strada della documentazione. L'Annex A, si argomenta, copre già la gestione degli incidenti, la gestione dei fornitori e i test, quindi DORA è la stessa sostanza con un involucro di conformità. La risposta è che una specifica e una scadenza non sono un involucro intorno a un controllo. Un punto di riferimento, un formato di invio, una cadenza di testing modificabile e una responsabilità legale nominata sono nuovi obblighi che l'esistenza di un controllo non assolve, e sono proprio quelli che una mappatura controllo-controllo rende invisibili.
La regola da mantenere
Quando mappi una certificazione su una regolamentazione, mappa gli obblighi operativi, non il testo del controllo. Un certificato attesta che un sistema di gestione ha soddisfatto uno standard, entro un ambito, per un ciclo di audit. Una regolamentazione dice cosa quel sistema deve fare, secondo quale specifica e entro quando. Dove le due descrivono la stessa attività, verifica se la regolamentazione ha aggiunto un cronometro con punto di riferimento, un formato, una cadenza o una responsabilità nominata, perché questi sono gli elementi che una mappatura controllo-controllo rende invisibili e che un supervisore è probabile che verifichi.
Questo principio si generalizza oltre DORA, anche se i dettagli variano a seconda del regime. NIS2 richiede agli Stati membri di imporre sia obblighi di governance dell'organo di gestione (Direttiva (UE) 2022/2555, Articolo 20) sia un obbligo di avviso precoce di 24 ore (Articolo 23), su attività che i controlli esistenti descrivono già. Il Cyber Resilience Act attacca la segnalazione temporizzata delle vulnerabilità attivamente sfruttate e degli incidenti gravi ai produttori di prodotti con elementi digitali, con tali obblighi di segnalazione che si applicano dal 11 settembre 2026 (Regolamento (UE) 2024/2847, Articolo 14). I modelli di responsabilità non sono identici, ma la disciplina di lettura è la stessa: trova il verbo, trova il cronometro o la specifica, e tratta ogni obbligo con una scadenza o un destinatario definito come un obbligo operativo piuttosto che come un documento da scrivere.
Se il tuo compito immediato è separare la reale sovrapposizione ISO 27001-DORA dagli obblighi temporizzati e specificati che un certificato non dimostra, quel lavoro di cross-referenziazione con gli articoli e gli standard tecnici effettivi è il tipo di attività che ISMS Copilot è stato progettato per supportare. Una grande sovrapposizione nella mappatura è reale. È anche una prova riutilizzabile che necessita comunque di una validazione specifica per DORA, non una conformità che puoi trasferire intatta, ed è per questo che non è la parte che dovrebbe guidare il piano.
Questa è un'analisi di conformità pratica, non un parere legale. Verifica l'ambito e gli obblighi della tua entità in base alla regolamentazione e ai suoi standard tecnici, e ove necessario con la tua autorità competente o un consulente legale.
Articoli correlati

La dichiarazione di ambito è il certificato
"ISO 27001 certificato" non è un'affermazione sì-o-no su un'azienda. La vera rivendicazione è la dichiarazione di ambito presente nel certificato, ed è verificabile.

Il CRA è un problema del 2026, non del 2027
L'obbligo di reporting del Cyber Resilience Act entra in vigore l'11 settembre 2026, oltre un anno prima dei suoi requisiti essenziali. I team che pianificano all'indietro partendo dalla marcatura CE del 2027 stanno ordinando il lavoro nel modo sbagliato.

La matrice di rischio 5x5 sopravvive agli audit, non al controllo
ISO 27001 non chiede mai una heat map. Ciò che richiede (risultati coerenti, validi e comparabili) è il test che la maggior parte delle matrici di rischio non supera.
