DORA vs ISO 27001: la certificazione basta?

No, una certificazione ISO 27001 non rende conformi al DORA. La ISO/IEC 27001 è una norma volontaria che certifica un sistema di gestione della sicurezza delle informazioni. Il DORA, Regolamento (UE) 2022/2554, è una legge che si applica dal 17 gennaio 2025 a banche, assicurazioni, imprese di investimento e altre entità finanziarie. Coincidono su rischio, incidenti, continuità e fornitori; il DORA aggiunge obblighi che il certificato non attesta.

Gli obblighi in più sono concreti: la segnalazione dei gravi incidenti all'autorità, il registro dei contratti con i fornitori ICT, un programma di test con cadenza annuale, le clausole minime nei contratti, la responsabilità finale dell'organo di gestione. Chi ha già la 27001 parte con un vantaggio reale, a patto di sapere dove finisce. Qui vediamo dove le due coincidono, dove il DORA va oltre e come usare il sistema di gestione che si ha già.

Cosa sono, e perché la domanda si pone

DORA: un regolamento, non una norma tecnica

Il DORA (Digital Operational Resilience Act) è il Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario. L'articolo 64 lo dichiara obbligatorio in tutti i suoi elementi e direttamente applicabile negli Stati membri, a decorrere dal 17 gennaio 2025: non serve un recepimento nazionale.

L'articolo 2 elenca a chi si applica: enti creditizi, istituti di pagamento e di moneta elettronica, imprese di investimento, imprese di assicurazione e riassicurazione, intermediari assicurativi, gestori di fondi, sedi di negoziazione e altre categorie, fino ai fornitori terzi di servizi ICT (il testo italiano scrive TIC).

ISO 27001: una norma volontaria e certificabile

La ISO/IEC 27001:2022, adottata in Italia come UNI CEI EN ISO/IEC 27001:2024+A1:2024, specifica i requisiti per costruire, mantenere e migliorare un sistema di gestione della sicurezza delle informazioni (SGSI, o ISMS), compresa la valutazione e il trattamento dei rischi. Vale per qualsiasi organizzazione, di qualsiasi settore e dimensione. Nessuna legge la impone in generale: la si sceglie, e la verifica un organismo di certificazione accreditato. Il quadro completo è nella guida alla ISO 27001.

Chi se lo chiede

Due profili, quasi sempre. L'entità finanziaria che ha già un ISMS certificato e vuole capire quanto lavoro DORA le resta. E il fornitore ICT (software house, provider cloud, MSP) che lavora con banche e assicurazioni e si sente chiedere entrambe le cose nello stesso questionario.

Dove la ISO 27001 e il DORA coincidono

La sovrapposizione è ampia, ed è il motivo per cui la 27001 è un buon punto di partenza. Gli ambiti in cui si parla la stessa lingua sono cinque.

Gestione del rischio

La 27001 chiede un processo di valutazione del rischio (punto 6.1.2) e di trattamento del rischio (punto 6.1.3). Il DORA chiede un quadro per la gestione dei rischi informatici solido, esaustivo e documentato (articolo 6) e l'identificazione di funzioni, patrimoni informativi, risorse ICT e dipendenze (articolo 8). Un metodo di rischio che gira già si estende, non si rifà.

Governance e responsabilità del vertice

Il punto 5.1 della 27001, leadership e impegno, chiede alla direzione di guidare il sistema. L'articolo 5 del DORA mette sull'organo di gestione la definizione, l'approvazione e la vigilanza del quadro per la gestione dei rischi informatici.

Audit interno, riesame, miglioramento

La 27001 ha audit interni (9.2), riesame di direzione (9.3) e miglioramento (10). Il DORA chiede audit interni sul quadro da parte di auditor indipendenti e competenti (articolo 6, paragrafo 6), un procedimento formale per dare seguito alle risultanze (paragrafo 7) e il miglioramento continuo del quadro (paragrafo 5).

Incidenti e continuità operativa

L'Allegato A della 27001 dedica i controlli da 5.24 a 5.27 alla gestione degli incidenti di sicurezza delle informazioni, il 5.29 e il 5.30 alla sicurezza durante le interruzioni e alla prontezza ICT per la continuità operativa, l'8.13 al backup. Il DORA chiede un processo di gestione degli incidenti connessi alle ICT (articolo 17), una politica di continuità operativa ICT con piani di risposta e ripristino (articolo 11) e politiche di backup e ripristino (articolo 12).

Fornitori

I controlli da 5.19 a 5.22 della 27001 coprono la sicurezza nei rapporti con i fornitori, negli accordi, nella filiera ICT e nel monitoraggio dei servizi; il 5.23 l'uso dei servizi cloud. Il DORA dedica ai rischi informatici derivanti da terzi gli articoli da 28 a 30.

Dove il DORA va oltre il certificato

Qui sta la risposta alla domanda iniziale. Un certificato 27001 attesta che il sistema di gestione rispetta la norma sul perimetro dichiarato. Non attesta questi obblighi, che sono propri del regolamento.

• Il perimetro non si sceglie. Nella 27001 è l'organizzazione a determinare il campo di applicazione del sistema (punto 4.3). Il DORA chiede un quadro che copra tutti i patrimoni informativi e le risorse ICT (articolo 6, paragrafo 2), con attenzione specifica alle funzioni essenziali o importanti. Un ISMS certificato su un solo servizio o una sola sede lascia fuori il resto.
• La responsabilità finale è scritta in legge. L'organo di gestione assume la responsabilità finale per la gestione dei rischi informatici (articolo 5, paragrafo 2, lettera a), fissa il livello di tolleranza al rischio ICT (articolo 6, paragrafo 8, lettera b) e i suoi membri devono mantenere conoscenze aggiornate, anche con formazione specifica regolare (articolo 5, paragrafo 4).
• Il riesame ha una cadenza minima. Il quadro si riesamina almeno una volta all'anno, e comunque dopo gravi incidenti ICT, e su richiesta si consegna all'autorità competente una relazione sul riesame (articolo 6, paragrafo 5).
• Gli incidenti gravi si segnalano all'autorità. L'articolo 19 chiede una notifica iniziale, una relazione intermedia e una relazione finale all'autorità competente, con i modelli e nei termini fissati dalle norme tecniche previste dall'articolo 20, oltre all'informazione ai clienti quando l'incidente incide sui loro interessi finanziari. La 27001 chiede di gestire gli incidenti, non di notificarli a un'autorità.
• I test sono un programma, con cadenze fissate. Le entità diverse dalle microimprese tengono un programma di test di resilienza operativa digitale (articolo 24) ed eseguono almeno ogni anno test adeguati su tutti i sistemi e le applicazioni ICT a supporto di funzioni essenziali o importanti (paragrafo 6). L'articolo 25 elenca i tipi di test, dai vulnerability assessment ai penetration test; l'articolo 26 impone alle entità identificate test di penetrazione guidati dalla minaccia (TLPT) almeno ogni tre anni. Il dettaglio è nel nostro articolo sui test di resilienza e TLPT.
• I contratti ICT vanno censiti e comunicati. Serve un registro di informazioni su tutti gli accordi per servizi ICT prestati da terzi, e almeno una volta all'anno si comunicano all'autorità numero di nuovi accordi, categorie di fornitori, tipi di contratto e servizi (articolo 28, paragrafo 3). Come costruirlo lo spieghiamo in gestione del rischio ICT e registro dei fornitori.
• I contratti hanno un contenuto minimo di legge. L'articolo 30 elenca le clausole obbligatorie, che per i servizi a supporto di funzioni essenziali o importanti includono livelli di servizio con obiettivi precisi, diritti di accesso, ispezione e audit, partecipazione al TLPT dell'entità finanziaria e strategie di uscita.
• Il dettaglio tecnico è fissato da un regolamento delegato. Il Regolamento delegato (UE) 2024/1774 specifica politiche e procedure su cifratura e gestione delle chiavi, vulnerabilità e patch, logging, sicurezza della rete, gestione delle identità e controllo degli accessi, fra le altre. Nella 27001 la scelta e la motivazione dei controlli stanno nella Dichiarazione di Applicabilità: è l'organizzazione a decidere quanto spingersi, nel DORA molto è già deciso.

Lo stesso schema vale per la direttiva sulla sicurezza delle reti: lo abbiamo visto in NIS2 vs ISO 27001. Una certificazione dimostra che esiste un metodo; la conformità a una legge si misura sugli obblighi della legge.

Se sei un fornitore ICT di banche e assicurazioni

Per chi vende servizi ICT al settore finanziario la domanda ha un'altra forma. L'articolo 28, paragrafo 5, del DORA stabilisce: "Le entità finanziarie possono stipulare accordi contrattuali soltanto con fornitori terzi di servizi TIC che soddisfano standard appropriati in materia di sicurezza delle informazioni." Per le funzioni essenziali o importanti l'entità deve anche considerare l'uso, da parte del fornitore, degli standard più aggiornati ed elevati.

Il regolamento non nomina nessuna norma. Una certificazione ISO 27001 è un modo riconoscibile per documentare che se ne applica una, e spesso è il primo documento che il cliente chiede. La valutazione però resta all'entità finanziaria, e il certificato non sostituisce il resto: le clausole dell'articolo 30, la disponibilità a partecipare ai test, i diritti di audit del cliente e dell'autorità. Se il certificato serve in tempi stretti per un cliente o una gara, abbiamo descritto come impostiamo il percorso nella pagina sulla certificazione ISO 27001 in tempi rapidi.

Come usare la ISO 27001 come base per il DORA

Se l'ISMS c'è già, conviene estenderlo invece di costruire un secondo sistema accanto. L'ordine che funziona:

1. Gap analysis articolo per articolo. Si parte dalla Dichiarazione di Applicabilità e dal registro dei rischi, e si confrontano con gli articoli da 5 a 30 del DORA e con il Regolamento delegato 2024/1774. Il risultato è l'elenco di cosa c'è, cosa va esteso, cosa manca.
2. Allargare il perimetro. Se il certificato copre una parte dell'azienda, il quadro DORA deve coprire tutte le risorse ICT, partendo dalle funzioni essenziali o importanti.
3. Allineare i criteri di rischio. I criteri di accettazione della 27001 diventano il livello di tolleranza al rischio ICT approvato dall'organo di gestione, con riesame almeno annuale.
4. Aggiungere classificazione e segnalazione degli incidenti. Il processo di gestione esiste già; vanno aggiunti i criteri per riconoscere un grave incidente, i modelli di notifica e chi li invia.
5. Trasformare i test in un programma. Vulnerability assessment e penetration test sparsi diventano un piano annuale sui sistemi a supporto delle funzioni essenziali o importanti, eseguito da soggetti indipendenti.
6. Costruire il registro e rivedere i contratti. L'inventario dei fornitori della 27001 diventa il registro di informazioni, e i contratti si confrontano con le clausole dell'articolo 30.
7. Un solo ciclo di audit e riesame. Audit interno e riesame di direzione coprono entrambi i perimetri, così le evidenze servono sia all'organismo di certificazione sia all'autorità di vigilanza.

In sintesi

La ISO 27001 e il DORA non sono alternative e non si equivalgono. La 27001 dà il metodo e un certificato che il mercato riconosce; il DORA è una legge con obblighi propri su perimetro, responsabilità dell'organo di gestione, segnalazione degli incidenti, test, registro e contratti. Chi ha un ISMS certificato ha già in casa buona parte dell'impianto, e il lavoro che resta si individua con una gap analysis sugli articoli del regolamento.

Se vuoi capire quanto del tuo sistema di gestione regge già davanti al DORA, o costruire la 27001 pensando fin da subito anche al regolamento, guarda come lavoriamo sulla ISO 27001.