Punti chiave
- DORA si applica dal 17 gennaio 2025 e per le Cyprus Investment Firms l'autorità competente è la CySEC, non un'autorità italiana (articolo 46 del regolamento e avviso del ministero delle Finanze cipriota K.D.P. 252/2025).
- La circolare C751 (19 gennaio 2026) richiama la funzione di controllo indipendente sul rischio ICT, il riesame annuale e l'audit interno ICT, e chiede di indicare nel portale CySEC il revisore ICT e il responsabile della funzione.
- Gli incidenti gravi si notificano alla CySEC solo tramite TRS: notifica iniziale entro 4 ore dalla classificazione e 24 dalla scoperta, relazione intermedia entro 72 ore, finale entro un mese, con i modelli V1.3 dal 10 giugno 2026.
- La CySEC ha trovato incidenti gravi non notificati e incidenti notificati come gravi senza esserlo: il rischio maggiore sta nella classificazione secondo il regolamento delegato (UE) 2024/1772.
- Il registro delle informazioni va inviato entro il 28 febbraio di ogni anno, con riferimento al 31 dicembre, solo in XBRL-CSV dal portale XBRL della CySEC.
- I sistemi a supporto di funzioni essenziali o importanti si testano almeno una volta l'anno; il TLPT riguarda solo le entità individuate dall'autorità, e le imprese di investimento non sono nell'elenco predefinito del regolamento delegato (UE) 2025/1190.
Se la tua società è una Cyprus Investment Firm o un'altra entità vigilata dalla CySEC ai sensi di DORA, il Regolamento (UE) 2022/2554 si applica dal 17 gennaio 2025 e l'autorità competente è la Cyprus Securities and Exchange Commission, non un'autorità italiana. In pratica: un quadro per la gestione del rischio ICT riesaminato almeno una volta l'anno, gli incidenti gravi notificati alla CySEC tramite TRS entro 4 ore dalla classificazione e 24 dalla scoperta, il registro delle informazioni entro il 28 febbraio, un programma di test.
Questa guida è per chi guida o segue da Milano o da Roma una Cyprus Investment Firm (CIF) o un'altra entità vigilata dalla CySEC: intermediari, broker, fintech e operatori cripto italiani con licenza cipriota. Segue il regolamento capitolo per capitolo e aggiunge quello che la CySEC ha pubblicato nelle sue circolari, dalla C700 (aprile 2025) alla C799 (settembre 2026). Il quadro generale del regolamento è nella guida completa a DORA. Il regolamento in italiano scrive TIC per ICT.
Perché l'autorità è la CySEC
L'articolo 46 di DORA affida la vigilanza all'autorità che già vigila ciascun tipo di entità. Per le imprese di investimento è quella designata ai sensi della direttiva (UE) 2019/2034, che per una CIF è la CySEC: la licenza è cipriota, e conta quella. Il ministero delle Finanze cipriota ha fissato la ripartizione con un avviso pubblicato in Gazzetta ufficiale il 14 agosto 2025 (K.D.P. 252/2025). La CySEC è l'autorità DORA per:
- le CIF soggette alla legge cipriota sulla vigilanza prudenziale delle imprese di investimento;
- i prestatori di servizi per le cripto-attività autorizzati dalla CySEC ai sensi di MiCA e gli emittenti di token collegati ad attività autorizzati dalla CySEC;
- depositari centrali, controparti centrali e sedi di negoziazione sotto la sua vigilanza;
- gestori di fondi di investimento alternativi, società di gestione UCITS e fornitori di servizi di crowdfunding autorizzati dalla CySEC.
Banche (salvo quelle significative, vigilate dalla BCE), istituti di pagamento e IMEL ciprioti fanno capo alla Banca centrale di Cipro. Se nel gruppo ci sono entità vigilate da entrambe, vale la pena leggere lo stesso avviso: l'articolo 19, paragrafo 1, chiede agli Stati membri di indicare un'autorità unica per le notifiche degli incidenti quando un'entità risponde a più autorità, e l'avviso assegna quel ruolo. Se invece nel gruppo c'è anche un intermediario italiano, per quello valgono le autorità italiane, riassunte nella guida su gestione del rischio ICT e registro dei fornitori.
Proporzionalità: le imprese di classe 3 e le microimprese
Non tutte le CIF portano lo stesso carico. Per l'articolo 16, le imprese di investimento piccole e non interconnesse (la CySEC le chiama di classe 3) sono esentate dagli articoli da 5 a 15 e applicano un quadro semplificato per la gestione del rischio ICT, dettagliato nel titolo III del regolamento delegato (UE) 2024/1774. Le microimprese sono esentate da diversi obblighi, fra cui la funzione di controllo indipendente sul rischio ICT e il programma di test. La classificazione va verificata prima di dimensionare il lavoro.
Gestione del rischio ICT: cosa ha chiesto la CySEC (articoli da 5 a 16)
L'organo di gestione definisce, approva e sorveglia il quadro per la gestione del rischio ICT e ne ha la responsabilità ultima (articolo 5, paragrafo 2). Sotto il consiglio, l'articolo 6 fissa quattro meccanismi che la CySEC ha ripreso quasi alla lettera nella circolare C751 del 19 gennaio 2026:
- Una funzione di controllo sul rischio ICT, con un livello di indipendenza adeguato a evitare conflitti di interesse e separata dalla gestione operativa e dall'audit interno, secondo il modello delle tre linee di difesa o un modello equivalente (articolo 6, paragrafo 4).
- Un riesame annuale del quadro, più un riesame dopo un incidente grave, dopo indicazioni dell'autorità o dopo le conclusioni di test e audit (articolo 6, paragrafo 5). La CySEC può chiedere la relazione sul riesame, e la C751 indica di impostarla sul capo V del regolamento delegato (UE) 2024/1774.
- L'audit interno del quadro da parte di revisori con competenze sul rischio ICT e indipendenza adeguata, con una frequenza commisurata al rischio (articolo 6, paragrafo 6).
- Un processo formale di follow-up per verificare e correggere per tempo i rilievi critici dell'audit ICT (articolo 6, paragrafo 7).
La C751 aggiunge due passi pratici nel portale CySEC: indicare il revisore ICT nella sezione Auditors, selezionando l'opzione "Is ICT" (obbligo per le entità diverse dalle microimprese), e indicare nella sezione Personnel la persona responsabile della funzione di controllo sul rischio ICT.
La circolare C786 sui modelli di AI di frontiera
Il 17 giugno 2026 la CySEC ha pubblicato la C786 sul rischio cyber legato ai modelli di AI di frontiera capaci di trovare e sfruttare vulnerabilità software in fretta e su larga scala. È impostata come un richiamo agli obblighi DORA esistenti: la CySEC chiede alle entità, in proporzione a dimensione e complessità, di verificare se le misure sul rischio ICT sono ancora adeguate, e indica le aree da guardare: gestione delle vulnerabilità e delle patch (con attenzione ai sistemi legacy), gestione delle identità e degli accessi, preparazione dei fornitori ICT, tempi di rilevamento e risposta, backup separati e provati in condizioni realistiche, rischio legato all'AI dentro le valutazioni del rischio ICT.
Incidenti gravi: prima si classifica, poi si notifica (articoli da 17 a 23)
Ogni incidente ICT si registra e si classifica con i criteri dell'articolo 18 e del regolamento delegato (UE) 2024/1772. Per l'articolo 8 di quel regolamento un incidente è grave quando ha colpito servizi critici e, in più, si è verificato un accesso riuscito, doloso e non autorizzato ai sistemi che può portare a perdite di dati, oppure sono superate almeno due delle altre soglie di rilevanza. Una di queste è economica: costi e perdite oltre i 100.000 euro, o che probabilmente li supereranno. Gli incidenti che si ripetono almeno due volte in sei mesi con la stessa causa apparente, e insieme soddisfano i criteri, valgono come un unico incidente grave; la verifica è mensile e non si applica a microimprese e imprese di classe 3.
La classificazione è il punto in cui la CySEC ha trovato problemi. Nella C751 ha scritto che alcuni incidenti da notificare come gravi non sono stati notificati, mentre altri sono stati notificati come gravi senza esserlo. L'indicazione è di applicare con cura il regolamento delegato 2024/1772, insieme al diagramma di classificazione discusso nel rapporto finale delle Autorità europee di vigilanza su quelle norme tecniche.
Le tre comunicazioni e i loro termini
I termini li fissa il regolamento delegato (UE) 2025/301 (articolo 5), e la CySEC li ha ripresi nella circolare C700:
- Notifica iniziale: entro 4 ore dalla classificazione dell'incidente come grave, e comunque entro 24 ore dal momento in cui ne sei venuto a conoscenza.
- Relazione intermedia: entro 72 ore dalla notifica iniziale, anche se nulla è cambiato, con un aggiornamento quando le attività regolari sono riprese.
- Relazione finale: entro un mese dalla relazione intermedia, o dall'ultima relazione intermedia aggiornata.
Se il termine cade di sabato, di domenica o in un giorno festivo, l'articolo 5, paragrafo 4, consente l'invio entro mezzogiorno del primo giorno lavorativo successivo. La deroga non vale per notifiche iniziali e relazioni intermedie di gestori di sedi di negoziazione, controparti centrali, enti creditizi ed entità essenziali o importanti ai sensi della NIS2. Se un incidente grave incide sugli interessi finanziari dei clienti, l'articolo 19, paragrafo 3, chiede anche di informarli senza indebito ritardo.
Come si invia alla CySEC
- Le comunicazioni passano solo dal sistema TRS della CySEC, non via email, e i file Excel non si firmano digitalmente (C700, C784).
- Dal 10 giugno 2026 la CySEC chiede i modelli V1.3 del pacchetto delle Autorità europee per la notifica degli incidenti (C784). La regola per i nomi dei file non è cambiata.
- L'invio conta solo quando il TRS restituisce un file di riscontro con l'indicazione NO ERROR.
- Le minacce informatiche significative si possono notificare su base volontaria, con un modello separato e dallo stesso canale.
C'è anche una comunicazione annuale. Con la C735 la CySEC ha adottato gli orientamenti congiunti delle Autorità europee sui costi e le perdite annui aggregati causati dagli incidenti gravi, e la C799 (8 settembre 2026) ne ha fissato l'invio: entro il 30 giugno dell'anno successivo a quello di riferimento, dal portale CySEC, solo se ci sono stati incidenti gravi. Per gli incidenti del 2025 il termine era il 30 settembre 2026.
Il rilevamento è il passaggio che rende praticabile la finestra delle quattro ore: non si classifica un incidente che non si è visto. Se il monitoraggio non copre tutti i sistemi dietro le funzioni essenziali o importanti, si parte da lì.
Test di resilienza operativa digitale (articoli da 24 a 27)
Tutte le entità diverse dalle microimprese tengono un programma di test basato sul rischio, dentro il quadro per la gestione del rischio ICT (articolo 24). Due punti portano la maggior parte del lavoro:
- test adeguati su tutti i sistemi e le applicazioni ICT che sostengono funzioni essenziali o importanti, almeno una volta l'anno (articolo 24, paragrafo 6);
- test condotti da soggetti indipendenti, interni o esterni, evitando i conflitti di interesse se il tester è interno (articolo 24, paragrafo 4).
L'articolo 25 elenca i tipi di test: valutazioni e scansioni delle vulnerabilità, valutazioni della sicurezza delle reti, revisioni del codice sorgente se fattibili, test basati su scenari, test end-to-end e penetration test, fra gli altri.
Il test di penetrazione guidato dalla minaccia (TLPT) è un'altra cosa: è richiesto almeno ogni tre anni solo alle entità che l'autorità individua (articolo 26). Il regolamento delegato (UE) 2025/1190 elenca chi è dentro per impostazione predefinita, salvo valutazione contraria: depositari centrali, controparti centrali e sedi di negoziazione con sistema di negoziazione elettronico sopra determinate quote di mercato, fra gli altri. Le imprese di investimento non sono in quell'elenco; l'autorità può comunque individuarne una sulla base di dimensione, interconnessione, sostituibilità dei servizi e profilo di rischio ICT (articolo 2, paragrafo 1). Imprese di classe 3 e microimprese sono fuori dal TLPT. Metodo e fasi sono nella guida ai test di resilienza DORA e TLPT.
Fornitori ICT e registro delle informazioni (articoli da 28 a 30)
Affidare l'ICT a terzi non sposta la responsabilità: l'entità resta pienamente responsabile del rispetto di DORA (articolo 28, paragrafo 1). Da qui gli obblighi principali:
- un registro delle informazioni su tutti gli accordi contrattuali per servizi ICT, a livello di entità e a livello subconsolidato e consolidato, distinguendo quelli che sostengono funzioni essenziali o importanti (articolo 28, paragrafo 3), con i modelli del regolamento di esecuzione (UE) 2024/2956;
- l'informativa tempestiva alla CySEC su ogni accordo previsto per servizi ICT a supporto di funzioni essenziali o importanti, e su quando una funzione diventa essenziale o importante (articolo 28, paragrafo 3);
- contratti con le clausole minime dell'articolo 30, paragrafo 2, e per le funzioni essenziali o importanti con quelle aggiuntive del paragrafo 3: livelli di servizio precisi, obblighi di preavviso e di comunicazione, piani di emergenza, partecipazione al TLPT, condizioni di uscita;
- strategie di uscita per i servizi a supporto di funzioni essenziali o importanti, con piani documentati, testati e riesaminati (articolo 28, paragrafo 8). Per chi usa il cloud il tema è sviluppato in DORA e cloud per fintech e intermediari.
L'invio del registro alla CySEC
Il registro va inviato ogni anno entro il 28 febbraio, con data di riferimento al 31 dicembre dell'anno prima (C700, confermata dalla C751). La CySEC lo accetta ormai solo in formato XBRL-CSV (C751, che richiama la C719), l'unico accettato dall'Autorità bancaria europea, generato con un software che lo valida sulle regole EBA, compresso e caricato dal portale XBRL della CySEC. Il vecchio file "Build in Excel" non è più accettato. La C700 fissa anche il livello: singola entità, oppure il livello di consolidamento più alto nell'Unione per i gruppi. La CySEC inoltra i registri alle Autorità europee di vigilanza.
Il calendario DORA della CySEC per una CIF
- Entro il 28 febbraio: registro delle informazioni, riferimento al 31 dicembre (C700, C751).
- Entro il 30 giugno: relazione su costi e perdite annui aggregati, solo se nell'anno di riferimento ci sono stati incidenti gravi (C799).
- Dal 1 al 15 settembre: autoclassificazione per il contributo annuale DORA, con pagamento entro il 30 novembre (C731).
- Almeno una volta l'anno: riesame del quadro per la gestione del rischio ICT e test sui sistemi a supporto delle funzioni essenziali o importanti (articoli 6, paragrafo 5, e 24, paragrafo 6).
- A ogni incidente grave: notifica iniziale, relazione intermedia e finale tramite TRS.
Le domande da portare in consiglio
- Chi ricopre la funzione di controllo sul rischio ICT, ed è indicato nel portale CySEC insieme al revisore ICT?
- Quando abbiamo applicato l'ultima volta i criteri del 2024/1772 a un incidente reale, e saremmo arrivati alla stessa conclusione della CySEC?
- Riusciamo a classificare e notificare un incidente grave entro quattro ore, anche nel fine settimana se la deroga non ci riguarda?
- Il registro copre tutti i contratti ICT, e supera la validazione EBA in XBRL-CSV prima del 28 febbraio?
- Quali sistemi dietro le funzioni essenziali o importanti abbiamo testato quest'anno, con chi, e cosa resta aperto?
In sintesi
Per una società vigilata dalla CySEC, DORA è il regolamento europeo più un elenco breve di istruzioni della CySEC su canali, formati e date: TRS e modelli V1.3 per gli incidenti, XBRL-CSV per il registro, il portale per il revisore ICT e la funzione di controllo. I rilievi nascono quasi sempre dalla classificazione degli incidenti e da registri che non corrispondono ai contratti veri.
Se vuoi una lettura esterna di dove si trova la tua CIF rispetto a DORA e alle circolari CySEC, parti dal percorso DORA di AmagisTech.
