DORA per le entità con licenza MFSA a Malta: cosa preparare

La risposta breve: se la tua società, o la controllata del tuo gruppo, ha una licenza della Malta Financial Services Authority (MFSA) e rientra fra le entità finanziarie dell'articolo 2 del Regolamento (UE) 2022/2554 (DORA), il regolamento si applica dal 17 gennaio 2025. La MFSA si aspetta quattro cose pronte: un quadro di gestione del rischio ICT in capo al consiglio, la segnalazione degli incidenti gravi tramite il suo Cyber Reporting Management System, un programma di test e il registro delle informazioni sui fornitori ICT, inviato ogni anno fra il 1° gennaio e il 21 marzo.

DORA è un regolamento, quindi vale direttamente anche a Malta. I pezzi nazionali sono arrivati con il Legal Notice 166 of 2024, i DORA Regulations, 2024, adottati in base al Malta Financial Services Authority Act, che la circolare MFSA dell'11 novembre 2024 indica come lo strumento che attua DORA nell'ordinamento maltese. Per un gruppo italiano la conseguenza pratica è semplice: la controllata maltese risponde alla MFSA, con i canali e i calendari della MFSA, mentre la capogruppo italiana resta vigilata dalla propria autorità di settore in Italia. Qui sotto, blocco per blocco, l'articolo che lo chiede e cosa ha pubblicato la MFSA.

Chi rientra nel perimetro a Malta

L'articolo 2, paragrafo 1 di DORA elenca le entità finanziarie alle lettere da a) a t): fra queste enti creditizi, istituti di pagamento e di moneta elettronica, imprese di investimento, prestatori di servizi per le cripto-attività, gestori di fondi, imprese di assicurazione e intermediari assicurativi. Prima di tutto conviene verificare tre limiti:

• Esclusioni. L'articolo 2, paragrafo 3 esclude fra gli altri gli intermediari assicurativi che sono microimprese o piccole o medie imprese, e gli enti pensionistici che gestiscono schemi che contano congiuntamente non più di 15 aderenti in totale.
• Quadro semplificato. Per l'articolo 16, paragrafo 1, gli articoli da 5 a 15 non si applicano, fra gli altri, alle imprese di investimento piccole e non interconnesse, agli istituti di pagamento e di moneta elettronica esentati e ai piccoli enti pensionistici aziendali o professionali, che seguono un quadro di gestione del rischio ICT più leggero, comunque documentato.
• Proporzionalità. L'articolo 4 chiede di applicare le regole sul rischio ICT in funzione di dimensioni, profilo di rischio complessivo e natura, portata e complessità dei servizi. Dimensiona il lavoro, non lo elimina.

Gli enti creditizi classificati come significativi rispondono alla BCE (articolo 46, lettera a), e la MFSA rinvia alle indicazioni della BCE per l'invio del registro. Per i gruppi, il registro si tiene a livello di entità e su base subconsolidata e consolidata (articolo 28, paragrafo 3).

1. Gestione del rischio ICT (articoli da 5 a 16)

È la base su cui poggia tutto il resto, e DORA la mette prima di tutto in capo al consiglio. Per l'articolo 5, paragrafo 2 l'organo di gestione definisce, approva e sorveglia il quadro di gestione dei rischi informatici e ne è responsabile; la lettera a) dice che "assume la responsabilità finale per la gestione dei rischi informatici dell’entità finanziaria". Lo stesso articolo gli chiede di approvare la strategia di resilienza operativa digitale e il livello di tolleranza al rischio (lettera d), di assegnare le risorse finanziarie (lettera g) e, al paragrafo 4, di tenere aggiornate le proprie competenze con una formazione regolare. Il dettaglio sull'articolo 5 sta in DORA e responsabilità del CdA.

Sotto il consiglio, il regolamento chiede prove che un'autorità possa leggere:

• un quadro documentato e riesaminato almeno una volta all'anno, e dopo gli incidenti gravi (articolo 6, paragrafo 5), con una funzione di controllo dotata di adeguata indipendenza (paragrafo 4) e audit interni regolari (paragrafo 6);
• inventari di asset informativi, asset ICT e funzioni aziendali supportate dalle TIC, con quelli critici mappati e la classificazione riesaminata almeno annualmente (articolo 8);
• meccanismi per individuare tempestivamente le attività anomale e risorse sufficienti per monitorare attività degli utenti, anomalie e incidenti, in particolare gli attacchi informatici (articolo 10);
• una politica di continuità operativa delle TIC con piani di risposta e ripristino testati almeno una volta all'anno (articolo 11, paragrafo 6) e, quando i backup si ripristinano su sistemi propri, sistemi separati fisicamente e logicamente da quello di origine (articolo 12, paragrafo 3);
• una relazione almeno annuale del personale TIC di grado più elevato all'organo di gestione (articolo 13, paragrafo 5) e programmi obbligatori di sensibilizzazione per tutto il personale (articolo 13, paragrafo 6).

Il dettaglio tecnico sta nel Regolamento delegato (UE) 2024/1774, che copre anche il quadro semplificato dell'articolo 16. Una lettura operativa del pilastro, insieme al quarto, è in gestione del rischio ICT e registro dei fornitori.

2. Classificazione e segnalazione degli incidenti (articoli da 17 a 23)

L'articolo 17 chiede un processo che individui, gestisca e notifichi gli incidenti connessi alle TIC, li registri tutti insieme alle minacce informatiche significative e informi l'organo di gestione almeno di quelli gravi. L'articolo 19 chiede di segnalare gli incidenti gravi all'autorità competente.

Quando un incidente è grave

Il test sta nell'articolo 8 del Regolamento delegato (UE) 2024/1772. Un incidente è grave quando ha colpito servizi critici e, in più, c'è stato un accesso riuscito, doloso e non autorizzato ai sistemi informatici che può comportare perdite di dati, oppure sono superate almeno due delle altre soglie di rilevanza. Fra queste soglie, per esempio, una durata superiore a 24 ore, un'indisponibilità superiore a 2 ore per i servizi ICT a supporto di funzioni essenziali o importanti, un impatto in due o più Stati membri, costi e perdite superiori, o probabilmente superiori, a 100.000 euro. Gli incidenti ricorrenti con la stessa causa apparente, avvenuti almeno due volte in sei mesi, contano come un unico incidente grave se nel complesso superano i criteri; la verifica è mensile.

I termini

Il Regolamento delegato (UE) 2025/301, articolo 5, paragrafo 1, fissa tre passaggi:

1. Notifica iniziale: quanto prima, e comunque entro quattro ore dalla classificazione dell'incidente come grave ed entro 24 ore dal momento in cui l'entità ne è venuta a conoscenza.
2. Relazione intermedia: al più tardi entro 72 ore dalla notifica iniziale, anche se nulla è cambiato, con un aggiornamento quando le attività regolari sono riprese.
3. Relazione finale: entro un mese dall'ultima relazione intermedia.

Se il termine cade nel fine settimana o in un giorno festivo, il paragrafo 4 consente l'invio entro le 12:00 del giorno lavorativo successivo, ma non per la notifica iniziale e la relazione intermedia di enti creditizi, controparti centrali, gestori delle sedi di negoziazione e entità identificate come soggetti essenziali o importanti ai sensi della NIS2 (paragrafo 5). I modelli sono quelli del Regolamento di esecuzione (UE) 2025/302. I clienti i cui interessi finanziari sono colpiti vanno informati senza indebito ritardo (articolo 19, paragrafo 3 di DORA), e la segnalazione si può esternalizzare restando pienamente responsabili (articolo 19, paragrafo 5).

Cosa ha predisposto la MFSA

La circolare MFSA del 17 gennaio 2025 sul Cyber Reporting Management System (CRMS) stabilisce che i soggetti autorizzati nel perimetro segnalano gli incidenti gravi connessi alle TIC, notificano su base volontaria le minacce informatiche significative e comunicano la partecipazione ad accordi di condivisione delle informazioni attraverso il CRMS del License Holder (LH) Portal, con i modelli della MFSA. La MFSA applica lo stesso processo sugli incidenti anche ai soggetti autorizzati fuori dal perimetro di DORA, come aspettativa di vigilanza. La casella per questo flusso è mirt@mfsa.mt.

Il punto pratico, per un gruppo con l'IT accentrato in Italia: le 24 ore decorrono da quando l'entità viene a conoscenza dell'incidente, non da quando lo viene a sapere la compliance a Malta. Se di notte o nel fine settimana nessuno guarda gli alert, la finestra di quattro ore dopo la classificazione è difficile da rispettare.

3. Test di resilienza operativa digitale (articoli da 24 a 27)

Le entità finanziarie diverse dalle microimprese tengono un programma di test basato sul rischio, parte del quadro di gestione del rischio ICT (articolo 24). I test li eseguono soggetti indipendenti, interni o esterni, e con cadenza almeno annuale tutti i sistemi e le applicazioni a supporto di funzioni essenziali o importanti passano test adeguati (articolo 24, paragrafo 6). L'articolo 25 elenca le tipologie, dalle scansioni delle vulnerabilità ai test basati su scenari fino ai test di penetrazione.

I test avanzati riguardano meno soggetti. Per l'articolo 26 le entità identificate dall'autorità competente effettuano test di penetrazione guidati dalla minaccia (TLPT) con cadenza almeno triennale, sui sistemi di produzione a supporto delle funzioni essenziali o importanti. Il dettaglio è nel Regolamento delegato (UE) 2025/1190; il quadro generale è in test di resilienza e TLPT.

A Malta, la circolare MFSA del 7 luglio 2025 indica la MFSA come TLPT Authority e stabilisce che i TLPT seguono il framework TIBER-EU. La MFSA ha pubblicato il TIBER-MT and DORA TLPT-MT National Implementation Document: le entità con licenza MFSA identificate per il TLPT svolgono un test TIBER-MT, che porta all'attestazione se sono rispettati i requisiti di DORA e delle norme tecniche. La corrispondenza sui TLPT va a tlpt@mfsa.mt.

4. Rischio da terzi ICT e registro delle informazioni (articoli da 28 a 30)

Esternalizzare l'ICT non esternalizza gli obblighi: per l'articolo 28, paragrafo 1, lettera a) l'entità resta pienamente responsabile. Le entità fuori dal regime semplificato e diverse dalle microimprese adottano una strategia per i rischi derivanti da terzi, con una politica sui servizi ICT a supporto di funzioni essenziali o importanti (paragrafo 2). Prima di firmare valutano rischi, concentrazione e idoneità del fornitore (paragrafo 4 e articolo 29) e, per le funzioni essenziali o importanti, tengono strategie di uscita testate (paragrafo 8). L'articolo 30 fissa le clausole minime; per le funzioni essenziali o importanti comprendono livelli di servizio con obiettivi quantitativi, partecipazione ai TLPT dell'entità, diritti illimitati di accesso e audit e un periodo di transizione in uscita.

Il registro, e come lo raccoglie la MFSA

L'articolo 28, paragrafo 3 chiede un registro di informazioni su tutti gli accordi contrattuali per servizi ICT prestati da terzi, distinguendo quelli a supporto di funzioni essenziali o importanti. I modelli sono quelli del Regolamento di esecuzione (UE) 2024/2956.

La circolare MFSA del 3 novembre 2025 fissa la raccolta dal 2026 in poi:

• il registro completo, a livello di entità o consolidato, si invia una volta all'anno tramite l'LH Portal;
• il periodo di segnalazione va dal 1° gennaio al 21 marzo (o al giorno lavorativo successivo) di ogni anno;
• la data di riferimento è il 31 dicembre dell'anno precedente;
• un invio è conforme a DORA solo quando sull'LH Portal ha lo stato Accepted; se è respinto, si correggono i rilievi e si reinvia;
• il file è un plain-csv conforme a DORA e allineato all'ultimo pacchetto tecnico delle Autorità europee di vigilanza, e prepararlo e convertirlo spetta all'entità: la MFSA precisa di non essere un fornitore XBRL.

La prima raccolta si è svolta dal 1° all'8 aprile 2025, e la MFSA ha ricordato la finestra 2026 con una circolare del 28 gennaio 2026. Con la regola di novembre 2025, la prossima finestra si apre a gennaio 2027 con data di riferimento 31 dicembre 2026. Le circolari avvertono che il mancato invio di un registro accettato entro il periodo può portare ad azioni di vigilanza ai sensi del L.N. 166 of 2024 e del MFSA Act. Le domande vanno a roi@mfsa.mt.

Cosa succede se manca qualcosa

DORA non fissa importi. L'articolo 50 chiede agli Stati membri di dare alle autorità competenti poteri sanzionatori, fra cui ordini di cessazione dei comportamenti, misure anche di natura pecuniaria e comunicazioni pubbliche, e il paragrafo 5 consente di estendere quelle misure ai membri dell'organo di gestione alle condizioni del diritto nazionale. A Malta le circolari MFSA indicano il L.N. 166 of 2024 e il MFSA Act come base per le azioni di vigilanza.

Una checklist per il prossimo consiglio della controllata

1. C'è una delibera che approva quadro di gestione del rischio ICT, strategia di resilienza e tolleranza al rischio, riesaminata negli ultimi dodici mesi?
2. Chi è la funzione di controllo indipendente sul rischio ICT, e chi monitora i fornitori ICT ai sensi dell'articolo 5, paragrafo 3?
3. L'entità sa classificare un incidente sulle soglie del 2024/1772 e inviare la notifica iniziale nel CRMS nei termini, anche di notte e nel fine settimana? Chi ha l'accesso all'LH Portal?
4. Ogni sistema a supporto di funzioni essenziali o importanti ha avuto quest'anno un test adeguato, e i rilievi sono chiusi?
5. Il registro 2026 è stato accettato sull'LH Portal, e chi ha in carico l'invio 2027?
6. I contratti per funzioni essenziali o importanti, compresi quelli infragruppo con la capogruppo italiana, contengono le clausole dell'articolo 30, paragrafo 3, e c'è un piano di uscita testato?

Per il quadro d'insieme dei cinque pilastri il punto di partenza resta la guida completa a DORA.

Come aiuta AmagisTech

Lavoriamo con le entità finanziarie sui quattro blocchi: gap analysis, quadro di gestione del rischio ICT, procedure sugli incidenti allineate ai termini del 2025/301, registro delle informazioni e un SOC attivo 24 ore su 24 per rilevamento e risposta. Abbiamo sedi a Milano e a Gżira, quindi seguiamo sia il lato italiano sia quello maltese dello stesso gruppo.

Se vuoi una lettura onesta di dove si trova la tua entità rispetto a DORA e ai requisiti della MFSA, parti dai nostri servizi DORA.