Le autorità di vigilanza olandesi guardano oltre le policy, concentrandosi su persone, fornitori e registri che assicurano il funzionamento dei mercati.
Alle 02:17, un responsabile operativo riceve un allarme. Il sistema che controlla l’accesso a una piattaforma di trading presenta un comportamento anomalo. Una parte dell’ambiente è ospitata da un fornitore esterno; un’altra è gestita dal team tecnologico del gruppo. Un tecnico chiede l’autorizzazione per effettuare una modifica di emergenza prima dell’apertura del mercato.
Il problema tecnologico è urgente, ma lo sono altrettanto le decisioni aziendali. A chi spetta decidere? Di quali log ci si può fidare? Potrebbe trattarsi di un incidente graveconnesso alle TIC? Chi è autorizzato a informare l’autorità di vigilanza e quella persona ha accesso al portale dell’AFM?
Sono queste le domande concrete alla base dell’analisi condotta dall’AFM nel giugno 2026 sulla gestione dei rischi TIC nelle sedi di negoziazione. L’esame ha riguardato mercati regolamentati, sistemi multilaterali di negoziazione e sistemi organizzati di negoziazione. In generale, le sedi avevano predisposto le basi richieste da DORA, ma restavano margini di miglioramento nel monitoraggio della sicurezza, nella gestione degli accessi, nella registrazione degli eventi, nelle modifiche di emergenza e nella continuità operativa.
L’indirizzo è chiaro. Un’impresa autorizzata può esternalizzare la tecnologia, ma non la propria responsabilità.
La policy non è il sistema operativo
DORA si applica dal 17 gennaio 2025. Per i soggetti finanziari che rientrano nel suo ambito disciplina la gestione dei rischi TIC, la segnalazione degli incidenti gravi, i test di resilienza digitale, il rischio derivante dai fornitori terzi di servizi TIC e la condivisione di informazioni sulle minacce informatiche.
L’AFM ha rilevato che le analisi degli scostamenti svolte dalle sedi di negoziazione esaminate erano spesso troppo generiche. Inoltre, non sempre emergeva una distinzione netta tra policy e procedure. Quando un sistema si blocca, questa differenza diventa essenziale.
Una policy definisce l’indirizzo, le responsabilità e i livelli di approvazione. Una procedura spiega a un dipendente che cosa fare alle 02:17: chi deve ricevere l’allarme, chi può autorizzare una modifica, chi classifica l’incidente e in che modo deve essere documentata la decisione.
Confondere i due strumenti genera una doppia debolezza. Il consiglio di amministrazione può ritenere di aver approvato un assetto operativo efficace, mentre il tecnico continua a dipendere da conoscenze personali e telefonate concitate. L’impresa reagisce così più lentamente e incontra maggiori difficoltà nel ricostruire le decisioni prese.
Il registro deve rappresentare l’attività reale
L’aggiornamento dell’AFM del 6 agosto aggiunge un ulteriore elemento. Nell’intera popolazione sottoposta alla vigilanza dell’AFM, la quota dei registri delle informazioni approvati dall’Autorità bancaria europea è salita dal 40 per cento nel 2025 al 94 per cento nel 2026. È un segnale di miglioramento nella qualità delle comunicazioni, ma richiama anche l’attenzione sulla solidità delle informazioni contenute nei singoli registri.
Un registro utile rispecchia l’ambiente tecnologico effettivamente in uso. Indica quale fornitore supporta ciascuna funzione critica, che cosa comprende il servizio e in quali punti della catena intervengono società del gruppo o subfornitori.
Descrizioni come “scambio di dati” o “supporto informatico” servono a poco durante un incidente. Una registrazione più solida chiarisce se il fornitore gestisce dati di mercato, controlli di identità, hosting, connettività, monitoraggio o flussi di ordini. Riporta inoltre i diritti di accesso del fornitore e le fasi del ripristino che dipendono dal suo intervento.
Le conseguenze economiche vanno ben oltre la fattura tecnologica. Un’impresa incapace di spiegare una dipendenza critica avrà difficoltà a negoziare impegni di ripristino, diritti di audit, trasparenza sul subappalto o assistenza in uscita. Durante un’interruzione, il peso maggiore può derivare dalle indagini, dagli interventi correttivi, dalle comunicazioni ai clienti, dal tempo dedicato dalla direzione e dalle controversie con i fornitori.
Il supporto del gruppo non elimina la responsabilità locale
Molte imprese regolamentate di dimensioni minori si affidano alla tecnologia del gruppo. Può essere una scelta efficiente e ragionevole. L’analisi dell’AFM ha tuttavia rilevato che i requisiti DORA non erano sempre recepiti in modo coerente nelle policy e nella documentazione predisposte a livello di gruppo.
Il punto di governance è semplice. L’entità autorizzata nei Paesi Bassi deve verificare se la documentazione del gruppo copra i suoi sistemi, i suoi rischi e i suoi obblighi specifici. Un modello elaborato dalla sede centrale non può rispondere a ogni esigenza locale. Potrebbe non considerare il canale olandese di segnalazione, una particolare connessione di trading o i poteri necessari al di fuori dell’orario d’ufficio.
Torniamo all’incidente notturno. Il team di sicurezza del gruppo potrebbe controllare la piattaforma di monitoraggio, mentre il servizio interessato potrebbe essere ospitato da un cloud provider esterno. Nessuna delle due circostanze dice alla direzione locale se il trading possa iniziare in sicurezza, se la modifica di emergenza sia autorizzata o se l’evento soddisfi i criteri di segnalazione.
Per le imprese soggette alla vigilanza dell’AFM, gli incidenti gravi ai sensi di DORA devono essere segnalati tramite il portale dell’AFM. In linea di principio, gli amministratori e i rappresentanti legali sono autorizzati. Gli altri dipendenti devono ricevere un’apposita autorizzazione per il portale. Una volta classificato l’evento come grave, la notifica iniziale deve essere presentata entro quattro ore e comunque non oltre 24 ore dal momento del rilevamento. Entro 72 ore segue una relazione intermedia, mentre la relazione finale deve essere trasmessa entro un mese da quella intermedia.
Poteri e diritti di accesso devono quindi essere parte integrante della progettazione del processo di gestione degli incidenti. Non possono emergere soltanto da un’e-mail preparata a evento già avvenuto.
I test devono mettere alla prova le decisioni, non soltanto individuare difetti
Alcuni soggetti rientranti nell’ambito di DORA possono essere selezionati, una volta ogni tre anni, per test di penetrazione guidati dalla minaccia. Per tali soggetti, il test può estendersi alle funzioni aziendali critiche o importanti e ai sistemi di produzione che le supportano. Le sedi di negoziazione possono essere selezionate in base a criteri di quota di mercato oppure in ragione del loro profilo di rischio TIC, del carattere sistemico o del possibile impatto sulla stabilità finanziaria.
Questo standard rivela la finalità più profonda di DORA. La resilienza non è un certificato acquistato da un fornitore di servizi di cybersicurezza. È la capacità di tenere insieme sistemi, contratti, persone e decisioni quando la pressione aumenta.
Un test efficace verifica se gli allarmi raggiungono la persona giusta, se gli accessi privilegiati sono controllati, se le modifiche di emergenza lasciano tracce utilizzabili e se il ripristino può procedere preservando le prove. Sono questioni operative che riguardano la direzione e il consiglio di amministrazione almeno quanto il team di sicurezza.
Anche i fornitori di tecnologia dovrebbero prestare attenzione. Chi presta servizi a una sede regolamentata può aspettarsi domande più puntuali su accessi, log, subfornitori, tempi di ripristino e cooperazione durante gli incidenti. Le risposte possono incidere sul valore del contratto, sul confronto con gli assicuratori e sulla solidità del rapporto con il cliente.
Prima dell’apertura del mercato, la squadra che ha gestito l’incidente notturno ha bisogno di un’unica risposta coerente: un responsabile nominativamente individuato, prove affidabili, un percorso di ripristino controllato e poteri di segnalazione ben definiti.
È questa la direzione della vigilanza olandese. Le regole contano, ma è il sistema concretamente funzionante a sostenere il peso maggiore. Quando lo schermo si spegne, l’impresa deve ancora sapere chi decide, chi interviene e chi ne risponde.
Se la vostra impresa vuole verificare se la governance DORA reggerebbe durante un vero incidente ai sistemi di trading, contattate Pavan Geraedts.
I dati, le fonti e l’analisi di questo articolo sono stati curati da Paolo Maria Pavan. L’IA non è stata usata per individuare le fonti, costruire la base fattuale o produrre il giudizio analitico. L’IA è stata usata solo come aiuto di redazione. Il testo italiano finale è stato rivisto, corretto e approvato personalmente da Paolo Maria Pavan prima della pubblicazione.
Riferimenti
- Handelssystemen vragen om scherpere ICT-risicobeheersing onder DORA
- Autoriteit Financiële Markten - Later AFM update: implementation has progressed, proof and operational reporting remain weak points
- De Nederlandsche Bank - Supplier register, subcontracting visibility and formal reporting
- De Nederlandsche Bank - Incident reporting is a technical and governance process, not only an operational response
- Autoriteit Financiële Markten - Authority, access and the AFM reporting route
- Autoriteit Financiële Markten - Testing critical trading functions under supervisory oversight
- De Nederlandsche Bank - AI-driven cyber pressure and dependency concentration
- De Nederlandsche Bank - Digital autonomy, exit capacity and supply-chain resilience
