Perché NIS2 e DORA ti stanno stressando (più dei cyber attacchi)
Quando parli con colleghi di altre entità finanziarie, nessuno ti dice di sentirsi tranquillo su NIS2 e DORA. Quasi tutti confessano la stessa cosa: la vera paura non è solo l’attacco informatico, ma arrivare ai prossimi cicli di compliance con un castello di carte fatto di file, mail e riunioni improvvisate.
La vera sfida di "conformità NIS2 e DORA" oggi è trasformare obblighi frammentati (scadenze NIS2, ROI DORA, incidenti, fornitori ICT) in un unico sistema di governance del rischio, che riduca gli errori manuali, renda tracciabili le decisioni e ti permetta di dimostrare alle autorità cosa fai davvero, non solo cosa dichiari nei documenti.
Se ti riconosci in almeno una di queste situazioni, sei in buona compagnia:
– il ROI DORA ancora in Excel, alimentato “a mano” da IT, procurement, legal, risk;
– incidenti gestiti con ticket separati, dove nessuno ha una vista di insieme;
– NIS2 affrontata come un fascicolo parallelo, con l’ennesimo file di gap analysis.
Il problema non è la competenza delle persone. Il problema è strutturale: la normativa europea sta convergendo su tre esigenze molto concrete — presidio dei fornitori ICT, capacità reale di gestione degli incidenti e qualità del dato. Continuare a trattarle come progetti distinti è il modo migliore per moltiplicare i rischi, non per ridurli.
Dal caos Excel al registro vivo: come costruire il ROI DORA in modo intelligente
L’articolo 28 di DORA, reso operativo dagli ITS e dal Regolamento di esecuzione 2024/2956, ha trasformato il Registro delle Informazioni (ROI) in un esercizio di data governance, non in un semplice adempimento tabellare. Lo si vede nei template: entità, funzioni, servizi, contratti, fornitori, livelli di consolidamento, codici EBA.
Chi ha provato a farlo solo in Excel lo sa: dopo il terzo ciclo di aggiornamento iniziano le incongruenze. Fornitore scritto in modi diversi, contratti duplicati, servizi non allineati alle funzioni, colonne “temporanee” che diventano definitive. Poi arriva il caricamento su INFOSTAT, i controlli di qualità, e iniziano i rigetti.
Una piattaforma dedicata, come il modulo GRC4ROI integrato nella GRC di Augeos, cambia la natura del lavoro:
– il censimento è guidato: i campi sono normalizzati, le obbligatorietà incorporate, i domini EBA mappati con etichette leggibili;
– le regole di qualità sono “in tempo reale”: l’errore viene intercettato mentre inserisci il dato, non tre mesi dopo al momento della segnalazione;
– il repository è unico: stesso fornitore ICT, stesso contratto, stessa storia, a prescindere da chi aggiorna.
Un intermediario che ha migrato il proprio ROI da fogli sparsi a GRC4ROI si è trovato, al primo ciclo di segnalazione, con due effetti molto concreti: tempo di revisione tagliato di oltre il 40% e, soprattutto, nessun rigetto per incoerenze di base. Non perché “tutti siano diventati più attenti”, ma perché il sistema impediva proprio i casi limite: LEI mancanti, funzioni non mappate, date non coerenti.
In prospettiva NIS2, questo non è un mero vantaggio operativo. Significa poter dimostrare che la gestione dei fornitori ICT non è affidata a un foglio excel di buona volontà, ma a un presidio strutturato e verificabile
NIS2 2026: usare incidenti, evidenze e ruoli per evitare la compliance di facciata
La NIS2, recepita in Italia con il d.lgs. 138/2024, porta tre messaggi molto pratici: gli incidenti vanno gestiti, notificati e relazionati con tempi precisi, la governance non è delegabile all’IT, e le evidenze contano più delle policy eleganti. Le linee guida pubblicate da ACN sulla gestione degli incidenti lo ripetono a ogni paragrafo.
Nel 2026, per i soggetti essenziali e importanti, non basterà dire di avere un processo di incident management. Dovrai mostrare:
– chi decide se un evento è un incidente significativo e secondo quali criteri;
– dove sono tracciate le fasi di rilevazione, risposta, ripristino e miglioramento;
– come l’incidente viene collegato agli asset, ai servizi e agli eventuali fornitori coinvolti.
Questo è il punto in cui molte organizzazioni iniziano a moltiplicare strumenti: un tool per il ticketing, un file per l’ACN, un documento “ufficiale” per l’audit. Il risultato è quasi sempre disallineamento. Un log dice una cosa, la segnalazione un’altra.
Integrare la gestione incidenti in una piattaforma di IT risk come A.IT Risk permette un cambio di passo: incidenti, controlli, asset e risk assessment convivono nello stesso ecosistema. Se un fornitore cloud ha un disservizio, l’evento non è più solo un ticket tecnico: è collegato immediatamente ai servizi critici, alle funzioni NIS2, alle responsabilità di governance già definite.
E soprattutto, quando compili la notifica, non parti da un foglio bianco.
Un’unica piattaforma per NIS2 e DORA: come lavorare meglio con GRC4ROI e A.IT Risk
La tentazione più naturale è creare “il progetto DORA” e “il progetto NIS2”: due comitati, due roadmap, due flussi. Nel breve periodo dà l’illusione del controllo. Nel medio periodo crea attrito: le stesse persone vengono chiamate su tavoli diversi, gli stessi dati vengono duplicati, le versioni iniziano a divergere.
Un approccio più maturo è ragioare per domini:
– fornitori e contratti ICT: coperti da GRC4ROI per il ROI DORA, ma anche fonte primaria per supply chain e vendor governance NIS2;
– asset, rischi e controlli IT: gestiti su A.IT Risk, che diventa il cuore della mappatura NIS2 e del supporto al ROI (quali asset sono serviti da quali fornitori);
– governance e controlli trasversali: orchestrati sulla piattaforma RED / GRC, dove piani, audit, remediation e evidenze convergono.
Il vantaggio sta nella possibilità di costruire viste diverse sugli stessi dati. Al supervisor serve un file ROI conforme ITS? Lo produci da GRC4ROI. All’ACN serve dimostrazione di misure, incidenti, ruoli? Recuperi da A.IT Risk e dai moduli GRC che gestiscono piani, responsabilità, decisioni di accettazione del rischio.
Non si tratta più di aggiungere un modulo per ogni norma. Si tratta di decidere quali oggetti — fornitore, contratto, servizio, asset, incidente, controllo — devono esistere una sola volta e vivere in più contesti.
Esempio concreto: cosa cambia davvero in una banca che integra NIS2 e DORA
Immagina una banca con forte dipendenza da un fornitore di core banking SaaS, classificato come critico nel ROI DORA. Fino a ieri, DORA e NIS2 seguivano binari separati: il contratto era descritto in un file per DORA, l’asset in un CMDB a parte, gli incidenti in un sistema di ticket.
Scenario integrato:
– il contratto ICT viene censito una volta in GRC4ROI, con tutte le informazioni richieste dal template europeo;
– lo stesso oggetto “fornitore/servizio” è collegato in A.IT Risk agli asset business e IT coperti, alle misure previste, agli SLA su incidenti e disponibilità;
– quando si verifica un disservizio grave, l’incidente aperto in A.IT Risk richiama automaticamente fornitore, servizi, sistemi, impatto stimato.
Nel giro di poche ore, il responsabile NIS2 ha già:
– gli elementi per qualificare l’incidente come “significativo” secondo i criteri ACN;
– i dati di contesto per predisporre la pre-notifica e la notifica nei tempi richiesti;
– una base informativa coerente con il perimetro DORA relativo al fornitore coinvolto.
Per l’organo di gestione questo si traduce in qualcosa di molto concreto: meno riunioni improvvisate, meno versioni in conflitto, responsabilità più chiare. E, in caso di ispezione, un racconto unico che tiene insieme incidenti, fornitori ICT, controlli e resilienza operativa.
Da progetto emergenziale a sistema sostenibile: la roadmap dei prossimi 12 mesi
Se oggi ti senti in ritardo, la via d’uscita non è correre di più, ma scegliere meglio dove mettere le energie.
Una sequenza pragmatica, compatibile con scadenze NIS2 2026 e invii annuali DORA, potrebbe essere:
- Perimetro e dati di base (1–2 mesi): verificare chi siete per NIS2, quali servizi rientrano, quali fornitori ICT alimentano funzioni critiche, quali contratti mancano ancora nel ROI.
- Scelta della piattaforma (1 mese): valutare se usare GRC4ROI e A.IT Risk solo per la “one shot” di segnalazione (modello SaaS) o per costruire un presidio permanente.
- Migrazione guidata dei contratti (2–3 mesi): import storico (anche da ZIP INFOSTAT), normalizzazione, pulizia duplicati, definizione regole di qualità.
- Incident & evidence management (3–4 mesi): modellare il processo incidenti NIS2 dentro A.IT Risk, collegando ticket, asset, controlli e logiche di notifica.
- Industrializzazione del ciclo annuale (continuativo): ogni nuovo contratto ICT e ogni incidente rilevante entrano subito nel sistema, non “alla fine dell’anno per la segnalazione”.
Il punto non è avere tutto perfetto al giorno zero. Il punto è smettere di aggiungere strati emergenziali e iniziare a costruire un’unica infrastruttura di dati e processi che regga DORA, NIS2 e le prossime evoluzioni regolamentari.
In questo, il ruolo di un partner che conosce sia la norma sia la tecnologia fa la differenza: ti permette di evitare errori già visti, usare modelli collaudati e concentrarti sulle decisioni che non puoi delegare, quelle di rischio e di governance.
Post Correlati
