Roadmap DORA 2026 per rischio ICT, fornitori e TLPT

Il panico da ricerca su DORA 2026 non riguarda davvero la normativa, ma le evidenze

Sono le 08:15 di un lunedì e il CISO di un istituto di pagamento di medie dimensioni ha tre schede del browser aperte: “checklist DORA RTS/ITS”, “modello di registro ICT delle terze parti DORA” e “requisiti TLPT per entità finanziarie”.

Il Responsabile Compliance ha già chiesto se il pacchetto per l’organo di gestione debba includere l’ultimo flusso operativo di classificazione degli incidenti. La funzione Approvvigionamenti vuole qualificare una nuova piattaforma cloud di analisi. Il Direttore operativo (COO) vuole assurance documentata che il fornitore SaaS di core banking non abbia esposizioni non presidiate verso subappaltatori al di fuori dell’UE. L’audit interno chiede un calendario dei test. La funzione legale chiede se le tempistiche di notifica delle violazioni previste dal GDPR siano state allineate alla segnalazione degli incidenti DORA.

Nessuno sta ponendo una domanda teorica. Stanno chiedendo: “Possiamo dimostrarlo entro venerdì?”

Questo è il vero problema DORA 2026. La maggior parte delle entità finanziarie comprende gli obblighi principali: gestione del rischio ICT, segnalazione degli incidenti ICT, test di resilienza operativa digitale, gestione del rischio ICT derivante da terzi e sorveglianza rafforzata sui fornitori ICT critici. La parte difficile consiste nel trasformare Regulatory Technical Standards, Implementing Technical Standards e obblighi a livello di Article in prassi controllate, ripetibili e verificabili in sede di audit.

Il Digital Operational Resilience Act richiede alle entità finanziarie di mantenere solide capacità di gestione del rischio ICT, politiche per la gestione e la segnalazione degli incidenti ICT, test di sistemi, controlli e processi ICT, nonché un governo strutturato dei fornitori ICT terzi. Richiede anche proporzionalità. Una piccola società di investimento e un grande gruppo bancario non hanno bisogno di modelli di evidenza identici, ma entrambe devono dimostrare che il proprio approccio è adeguato a dimensioni, profilo di rischio, complessità e funzioni critiche.

I progetti DORA falliscono di solito per una di tre ragioni. Primo, l’organizzazione tratta DORA come un esercizio di mappatura legale anziché come un modello operativo. Secondo, il rischio dei fornitori viene documentato come un elenco di fornitori invece che come dipendenza, sostituibilità e rischio di concentrazione. Terzo, i test vengono trattati come un test di penetrazione annuale invece che come un programma di resilienza che include scansioni di vulnerabilità, test basati su scenari, esercitazioni sugli incidenti e, ove applicabile, test di penetrazione basati su minacce, comunemente cercati come TLPT.

Un approccio più efficace consiste nel costruire un unico sistema di evidenze che colleghi politiche, registri, titolari, rischi, incidenti, fornitori, test, ripristino e riesame della direzione. È qui che Zenith Blueprint di Clarysec, le politiche pronte all’uso e Zenith Controls aiutano le entità finanziarie a trasformare DORA da una scadenza a un ritmo operativo.

Partire dal modello operativo DORA, non dal foglio di calcolo RTS/ITS

Molti team iniziano con un foglio di calcolo che elenca gli articoli DORA e i requisiti RTS/ITS. È utile, ma non sufficiente. Un foglio di calcolo può indicare che cosa deve esistere. Non assegna titolari, non definisce la frequenza di riesame, non conserva evidenze e non dimostra che un controllo funzioni davvero.

In Zenith Blueprint: roadmap in 30 passi per auditor, Clarysec affronta questo aspetto nella fase di Gestione del rischio, Passo 14, Politiche di trattamento del rischio e riferimenti incrociati normativi:

“DORA: per le imprese del settore finanziario, DORA richiede un quadro di gestione del rischio ICT molto allineato a quanto abbiamo fatto: identificare i rischi, introdurre controlli e politiche, e testarli. DORA pone inoltre forte enfasi sulla risposta agli incidenti e sulla relativa segnalazione, nonché sulla vigilanza dei fornitori terzi di servizi ICT.”

Il messaggio operativo è semplice: non costruire la “conformità DORA” come una burocrazia parallela. Occorre costruire un livello di governance ICT basato sul rischio che mappi i requisiti DORA a politiche, registri, titolari dei controlli, registrazioni dei test, evidenze dei fornitori e riesame della direzione.

Un modello operativo DORA pratico dovrebbe prevedere cinque pilastri di evidenza:

Per le entità finanziarie regolamentate, questa struttura trasforma l’attuazione RTS/ITS in un sistema di evidenze pronto per l’audit. Per le entità soggette a gestione semplificata del rischio ICT, lo stesso modello può essere ridimensionato in un numero minore di documenti e registri più semplici. Le discipline di base restano le stesse: identificare, proteggere, rilevare, rispondere, ripristinare, testare e governare i fornitori.

Gestione del rischio ICT: il registro è la sala di controllo

Le aspettative DORA in materia di gestione del rischio ICT richiedono alle entità finanziarie di identificare, classificare e gestire i rischi ICT su sistemi, dati, processi, funzioni critiche o importanti e dipendenze da terze parti.

Il problema ricorrente non è l’assenza di un registro dei rischi. È il fatto che il registro sia scollegato da fornitori, asset, incidenti e test. DORA non premia un foglio di calcolo ben impaginato se non riesce a spiegare perché un fornitore ad alto rischio non abbia un piano di uscita o perché una piattaforma critica per i pagamenti dei clienti non sia stata testata.

La Politica di gestione del rischio SME di Clarysec fornisce alle entità finanziarie più piccole una baseline concisa di evidenze:

“Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, titolare e piano di trattamento.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.1.2.

Per le entità finanziarie più grandi, la Politica di gestione del rischio Enterprise di Clarysec richiede un processo più formale:

“Deve essere mantenuto un processo formale di gestione del rischio conforme a ISO/IEC 27005 e ISO 31000, che copra identificazione, analisi, valutazione, trattamento, monitoraggio e comunicazione del rischio.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.1.

Questa distinzione è rilevante. DORA è proporzionato, ma proporzionalità non significa informalità. Una piccola società di pagamenti può utilizzare un registro snello, mentre un gruppo bancario può utilizzare strumenti GRC integrati. In entrambi i casi, l’auditor chiederà comunque: quali sono i vostri rischi ICT? Chi ne è responsabile? Qual è il Piano di trattamento del rischio? Quali evidenze mostrano l’avanzamento? In che modo fornitori e funzioni critiche incidono sul punteggio?

Un solido registro dei rischi ICT DORA dovrebbe includere questi campi:

Un esercizio pratico consiste nel prendere un servizio ICT critico, ad esempio una piattaforma di monitoraggio delle transazioni ospitata nel cloud, e creare una voce di rischio in 20 minuti. Descrivere lo scenario di guasto o compromissione, attribuire un punteggio a probabilità e impatto, assegnare un titolare, identificare i fornitori correlati, definire un Piano di trattamento del rischio e collegare la voce a evidenze quali due diligence sui fornitori, SLA, clausole sugli incidenti, BIA, risultati dei test di DR, cruscotti di monitoraggio e riesami degli accessi.

Quella singola voce diventa il filo conduttore che collega gestione del rischio ICT DORA, governo delle terze parti, rilevazione degli incidenti, continuità e test. È così che un registro dei rischi diventa una sala di controllo, non un archivio.

Preparazione RTS/ITS: mappare gli obblighi alle politiche, non alle promesse

Il termine di ricerca pratico “checklist DORA RTS/ITS” di solito significa: “Quali documenti si aspetteranno le autorità di vigilanza?” Le entità finanziarie devono evitare di promettere conformità tramite dichiarazioni generiche. Serve una mappatura che colleghi ogni obbligo a una politica, un controllo, un titolare e un elemento di evidenza.

La Politica di conformità legale e normativa SME di Clarysec stabilisce un semplice riferimento di governance:

“Il Direttore generale (GM) deve mantenere un Registro di conformità semplice e strutturato che elenchi:”
Dalla sezione “Requisiti di governance”, clausola della politica 5.1.1.

Per DORA 2026, il Registro di conformità dovrebbe includere:

• Obbligo DORA o area di requisito RTS/ITS.
• Applicabilità, inclusa la motivazione della proporzionalità.
• Riferimento a politica o procedura.
• Titolare del controllo.
• Ubicazione delle evidenze.
• Frequenza di riesame.
• Lacune aperte e scadenza delle azioni di rimedio.
• Stato della reportistica all’organo di gestione o alla direzione.

Questo è allineato all’approccio dello Zenith Blueprint Passo 14: mappare i requisiti normativi ai controlli e alle politiche del SGSI affinché nulla sfugga. Invece di chiedere “Siamo conformi a DORA?”, la leadership può chiedere “Quali elementi di evidenza DORA sono scaduti, quali fornitori critici non hanno piani di uscita e quali attività di test non hanno ancora prodotto evidenze di remediation?”

Rischio ICT delle terze parti: concentrazione, sostituibilità e subappaltatori

DORA ha cambiato il modo in cui i servizi finanziari discutono dei fornitori. Non basta più chiedere se un fornitore abbia una certificazione di sicurezza, un’assicurazione o un Accordo sul trattamento dei dati (DPA). Le entità finanziarie devono valutare se un fornitore crea rischio di concentrazione, se può realisticamente essere sostituito, se più servizi critici dipendono da un solo fornitore o da fornitori collegati e se il subappalto introduce ulteriori esposizioni legali o di resilienza.

Questo è il tema che tiene svegli molti CISO. Un’impresa può dipendere da un unico grande fornitore di servizi cloud per elaborazione delle transazioni, analisi dei dati, portali clienti e collaborazione interna. Se quel fornitore subisce un’indisponibilità prolungata, una controversia regolatoria o il fallimento di un subappaltatore, la domanda non è solo “Abbiamo un contratto?” La domanda è “Possiamo continuare i servizi critici, comunicare con i clienti e dimostrare di aver compreso la dipendenza prima che si concretizzasse il guasto?”

La Politica di sicurezza delle terze parti e dei fornitori SME di Clarysec stabilisce le basi:

“Un Registro dei fornitori deve essere mantenuto e aggiornato dal referente amministrativo o degli Approvvigionamenti. Deve includere:”
Dalla sezione “Requisiti di governance”, clausola della politica 5.4.

Per i programmi enterprise, la Politica di gestione del rischio di dipendenza dai fornitori di Clarysec approfondisce dipendenza e sostituibilità specifiche per DORA:

“Registro delle dipendenze dai fornitori: il VMO deve mantenere un registro aggiornato di tutti i fornitori critici, includendo dettagli quali servizi/prodotti forniti; se il fornitore è in fornitura esclusiva; fornitori alternativi disponibili o sostituibilità; termini contrattuali correnti; e una valutazione dell’impatto in caso di fallimento o compromissione del fornitore. Il registro deve identificare chiaramente i fornitori ad alta dipendenza, ad esempio quelli per i quali non esiste un’alternativa rapidamente attivabile.”
Dalla sezione “Requisiti di attuazione”, clausola della politica 6.1.

Questa è l’evidenza sui fornitori che i progetti DORA spesso trascurano. Un registro dei fornitori dice chi è il fornitore. Un registro delle dipendenze dice che cosa accade quando il fornitore fallisce.

Lo Zenith Blueprint, fase Controls in Action, Passo 23, Controlli organizzativi, fornisce un flusso operativo pratico per il governo dei fornitori. Raccomanda di compilare un elenco completo dei fornitori, classificarli in base all’accesso a sistemi, dati o controllo operativo, verificare che le aspettative di sicurezza siano integrate nei contratti, gestire il rischio dei subappaltatori e dei soggetti a valle, definire procedure di modifica e monitoraggio e creare un processo di valutazione dei servizi cloud.

In Zenith Controls: guida alla conformità trasversale, il controllo ISO/IEC 27002:2022 5.21, Gestione della sicurezza delle informazioni nella catena di fornitura ICT, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. È associato alla sicurezza delle relazioni con i fornitori e al concetto di cibersicurezza Identify. Si collega a ingegneria sicura, programmazione sicura, controllo degli accessi, Test di sicurezza, raccolta delle evidenze, ciclo di vita sicuro dello sviluppo e sviluppo esternalizzato.

Questa è esattamente la realtà del governo DORA delle terze parti. Il rischio dei fornitori non riguarda solo gli Approvvigionamenti. Tocca architettura, sviluppo, risposta agli incidenti, controllo degli accessi, continuità operativa e funzione legale.

Da una prospettiva di conformità trasversale, Zenith Controls mappa la sicurezza della catena di fornitura ICT agli GDPR Articles 28 and 32 perché responsabili del trattamento e sub-responsabili devono essere selezionati e supervisionati con misure tecniche e organizzative adeguate. Supporta le aspettative NIS2 in materia di sicurezza della catena di fornitura, incluse le misure di gestione dei rischi di cibersicurezza previste dall’Article 21 e le valutazioni coordinate dei rischi della catena di fornitura previste dall’Article 22. Si mappa fortemente ai DORA Articles 28, 29 and 30, dove rischio ICT delle terze parti, rischio di concentrazione, sub-outsourcing e disposizioni contrattuali sono centrali.

Gli standard di supporto rafforzano le evidenze. ISO/IEC 27036-3:2021 supporta la sicurezza dell’approvvigionamento ICT e della selezione dei fornitori. ISO/IEC 20243:2018 supporta l’integrità dei prodotti tecnologici affidabili e la sicurezza della catena di fornitura. ISO/IEC 27001:2022 collega questi aspetti al trattamento del rischio e ai controlli sui fornitori dell’Annex A.

Segnalazione degli incidenti: costruire la catena di escalation prima dell’incidente

La segnalazione degli incidenti DORA non riguarda solo l’invio di una notifica. Riguarda rilevare, classificare, effettuare escalation, comunicare e apprendere dagli incidenti ICT. Le entità finanziarie devono mantenere processi per la gestione e la segnalazione degli incidenti ICT, con ruoli definiti, criteri di classificazione, canali di notifica e analisi post-incidente.

La Politica di risposta agli incidenti SME di Clarysec collega le tempistiche di risposta ai requisiti legali:

“Le tempistiche di risposta, inclusi il ripristino dei dati e gli obblighi di notifica, devono essere documentate e allineate ai requisiti legali, come l’obbligo previsto dal GDPR di notificare le violazioni dei dati personali entro 72 ore.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.3.2.

Per gli ambienti enterprise, la Politica di risposta agli incidenti di Clarysec aggiunge la prospettiva di escalation sui dati regolamentati:

“Se un incidente determina un’esposizione confermata o probabile di dati personali o di altri dati regolamentati, la funzione legale e il DPO devono valutare l’applicabilità di:”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.4.1.

La citazione si interrompe sul punto di attivazione, che è esattamente dove molti processi di incidente falliscono. Se il trigger non è chiaro, i team discutono sugli obblighi di notifica mentre il tempo sta già decorrendo.

Lo Zenith Blueprint, fase Controls in Action, Passo 16, Controlli relativi al personale II, enfatizza la segnalazione degli incidenti guidata dal personale. Dipendenti, contraenti e stakeholder devono sapere come riconoscere e segnalare potenziali incidenti di sicurezza utilizzando canali semplici, come una casella e-mail dedicata, un portale o una hotline. Il Blueprint collega questo aspetto al GDPR Article 33, al NIS2 Article 23 e al DORA Article 17, perché la segnalazione regolatoria inizia dalla consapevolezza interna e dall’escalation.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.24, Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, è mappato come controllo correttivo a supporto di riservatezza, integrità e disponibilità, allineato a Respond e Recover. Si collega direttamente alla valutazione degli eventi, alle lezioni apprese dagli incidenti, a registrazione e monitoraggio, alla sicurezza durante le interruzioni, alla continuità della sicurezza delle informazioni e al contatto con le autorità. La guida lo mappa ai DORA Articles 17 to 23 per gestione, classificazione, segnalazione degli incidenti ICT e notifica volontaria delle minacce informatiche, agli GDPR Articles 33 and 34 per notifica delle violazioni e al NIS2 Article 23 per notifica degli incidenti.

Un processo di incidente pronto per DORA dovrebbe includere:

• Canali chiari di ricezione degli incidenti.
• Criteri di triage e classificazione degli eventi.
• Flussi operativi di escalation per gli incidenti ICT rilevanti.
• Punti decisionali per notifica legale, DPO e regolatoria.
• Trigger di notifica degli incidenti dei fornitori.
• Requisiti di conservazione delle evidenze.
• Regole di comunicazione per direzione esecutiva e organo di gestione.
• Riesame post-incidente e lezioni apprese.
• Collegamento agli aggiornamenti del registro dei rischi e alla remediation dei controlli.

Gli standard di supporto aggiungono struttura. ISO/IEC 27035-1:2023 fornisce principi di pianificazione e preparazione per la gestione degli incidenti. ISO/IEC 27035-2:2023 dettaglia i passaggi di trattamento degli incidenti. ISO/IEC 22320:2018 supporta comando, controllo e comunicazione di crisi strutturata. Questo conta quando un’indisponibilità ICT diventa una crisi con impatto sui clienti e l’entità deve dimostrare che le decisioni sono state tempestive, coordinate e basate su evidenze.

Test di resilienza operativa digitale e TLPT: evitare che il test diventi l’incidente

I test sono uno degli argomenti DORA 2026 più cercati perché sono al tempo stesso tecnici e fortemente legati alla governance. Le entità finanziarie devono testare sistemi, controlli e processi ICT. Per le entità designate, test avanzati come il TLPT diventano un requisito centrale ai sensi del DORA Article 26.

La domanda di audit non è solo “Avete testato?” È “Il test era basato sul rischio, autorizzato, sicuro, indipendente ove richiesto, oggetto di remediation e collegato agli obiettivi di resilienza?”

La Politica di Test di sicurezza e Red Teaming Enterprise di Clarysec definisce chiaramente il programma minimo di test:

“Tipi di test: il programma di Test di sicurezza deve includere, come minimo: (a) scansioni di vulnerabilità, consistenti in scansioni automatizzate settimanali o mensili di reti e applicazioni per identificare vulnerabilità note; (b) test di penetrazione, consistenti in test manuali approfonditi di specifici sistemi o applicazioni da parte di tester qualificati per identificare debolezze complesse; e (c) esercitazioni red team, consistenti in simulazioni basate su scenari di attacchi reali, incluse ingegneria sociale e altre tattiche, per testare nel complesso le capacità di rilevazione e risposta dell’organizzazione.”
Dalla sezione “Requisiti di attuazione”, clausola della politica 6.1.

Questo è il ponte tra i test ordinari e la maturità TLPT. Le scansioni di vulnerabilità trovano debolezze note. I test di penetrazione validano la sfruttabilità. Il red teaming testa rilevazione e risposta come sistema. Il TLPT, ove applicabile, dovrebbe collocarsi all’interno di un programma di test governato, con controllo dell’ambito, regole di sicurezza, gestione del rischio di produzione, raccolta delle evidenze e tracciamento della remediation.

Lo Zenith Blueprint, fase Controls in Action, Passo 21, affronta la protezione dei sistemi informativi durante audit e test. Avverte che audit, test di penetrazione, riesami forensi e valutazioni operative possono introdurre rischi perché possono comportare accessi elevati, strumenti intrusivi o modifiche temporanee al comportamento dei sistemi. Il Blueprint mappa questo tema al GDPR Article 32, alle aspettative DORA sui test di resilienza operativa digitale, alle preoccupazioni NIS2 sulla continuità e alle pratiche COBIT 2019 per l’esecuzione sicura di audit e valutazioni.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.35, Riesame indipendente della sicurezza delle informazioni, è mappato come preventivo e correttivo, a supporto di riservatezza, integrità e disponibilità. Si collega alla conformità alle politiche, alle responsabilità della direzione, alle lezioni apprese dagli incidenti, alla protezione delle registrazioni, alla cancellazione delle informazioni, a registrazione e monitoraggio. Per DORA, gli obblighi di test rilevanti sono principalmente gli Articles 24 to 27, incluso l’Article 26 per TLPT. Questo supporta inoltre il GDPR Article 32(1)(d), che richiede test e valutazioni regolari delle misure tecniche e organizzative, e il NIS2 Article 21, che richiede misure di gestione dei rischi di cibersicurezza.

Un pacchetto di preparazione DORA TLPT dovrebbe includere:

La lezione principale DORA è che le evidenze dei test non devono fermarsi al report. Gli auditor chiederanno se le risultanze sono state classificate in base al rischio, assegnate, corrette e ritestate. Potrebbero anche verificare se i test hanno coperto funzioni critiche o importanti, non solo asset esposti a Internet.

Continuità operativa e Disaster Recovery: la resilienza deve essere operativa

DORA è una normativa sulla resilienza operativa digitale. Il ripristino conta quanto la prevenzione. Un quadro documentato di rischio ICT non aiuta se un’indisponibilità della piattaforma di pagamento rivela che i Recovery Time Objective non sono mai stati testati, gli alberi di contatto dei fornitori sono obsoleti e il team di crisi non concorda su chi comunichi con i clienti.

La Politica di continuità operativa e disaster recovery SME di Clarysec stabilisce una baseline chiara:

“L’organizzazione deve testare almeno annualmente sia il proprio BCP sia le proprie capacità di DR. I test devono includere:”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.4.1.

La Politica di continuità operativa e disaster recovery Enterprise parte dall’impatto aziendale:

“La Business Impact Analysis (BIA) deve essere eseguita almeno annualmente per tutte le unità aziendali critiche e riesaminata in caso di modifiche significative a sistemi, processi o dipendenze. Gli output della BIA devono definire:”
Dalla sezione “Requisiti di governance”, clausola della politica 5.2.

Per DORA, la BIA dovrebbe essere collegata ad asset ICT, fornitori, risposta agli incidenti e test. Se la BIA identifica i “pagamenti dei clienti” come funzione critica, il registro delle dipendenze dai fornitori dovrebbe identificare processori, servizi cloud e fornitori di rete che la supportano. Il registro dei rischi dovrebbe includere scenari di guasto. Il piano di test dovrebbe includere la convalida della resilienza. Il Piano di risposta agli incidenti dovrebbe includere escalation e comunicazione. Il test di DR dovrebbe produrre evidenze, non solo un verbale di riunione.

Questa tracciabilità è ciò che trasforma la conformità DORA in un sistema di resilienza operativa.

Conformità trasversale: un solo set di evidenze, molte domande di audit

Le entità finanziarie raramente affrontano DORA da sole. Spesso hanno obblighi GDPR, esposizione a NIS2, impegni contrattuali di sicurezza, obiettivi ISO/IEC 27001:2022, requisiti di audit interno, due diligence dei clienti, aspettative SOC e reportistica del rischio all’organo di gestione. La risposta non è creare silos separati di evidenze. La risposta è costruire un modello di evidenze di conformità trasversale.

Zenith Controls è la bussola di conformità trasversale di Clarysec. Non inventa nuovi obblighi. Mappa standard e quadri di riferimento ufficiali affinché le organizzazioni possano comprendere come una singola area di controllo supporti più risultati di conformità.

Questo conta per budget e governance. Un CISO può spiegare all’organo di gestione che migliorare la classificazione degli incidenti supporta la segnalazione DORA, la notifica delle violazioni GDPR, il trattamento degli incidenti NIS2 e la resilienza interna. Un responsabile degli Approvvigionamenti può giustificare la mappatura delle dipendenze dai fornitori perché supporta il rischio di concentrazione DORA, la due diligence sui responsabili del trattamento GDPR e la sicurezza della catena di fornitura NIS2. Un responsabile dei test può mostrare che esercitazioni red team e riesami indipendenti supportano test DORA, valutazione dei controlli GDPR e assurance più ampia.

Prospettiva di audit: come i valutatori testeranno le evidenze DORA

La preparazione a DORA diventa concreta quando qualcuno chiede evidenze. Auditor e valutatori diversi affronteranno lo stesso tema da angolazioni diverse.

Un auditor orientato a ISO/IEC 27001:2022 partirà dalla logica del SGSI: campo di applicazione, valutazione del rischio, trattamento del rischio, applicabilità dei controlli dell’Annex A, audit interno, riesame della direzione ed evidenze che i controlli siano implementati. Per la sicurezza della catena di fornitura ICT, esaminerà politiche, classificazione dei fornitori, clausole contrattuali, due diligence e monitoraggio continuativo. Per la gestione degli incidenti, ispezionerà il piano, i ruoli, i percorsi di escalation, gli strumenti e le registrazioni. Per i test, si aspetterà intervalli pianificati, indipendenza ove appropriato, remediation e input al riesame della direzione.

Una prospettiva di audit ISO/IEC 19011:2018 si concentra sull’esecuzione dell’audit. In Zenith Controls, la metodologia di audit per la sicurezza della catena di fornitura ICT indica che gli auditor esaminano politiche di approvvigionamento, modelli RFP e processi di gestione dei fornitori per verificare che i requisiti di sicurezza specifici ICT siano integrati dall’acquisizione alla dismissione. Per la gestione degli incidenti, gli auditor esaminano il Piano di risposta agli incidenti per completezza e allineamento alle migliori pratiche. Per il riesame indipendente, gli auditor cercano evidenze dell’esecuzione di audit o riesami indipendenti.

Una prospettiva ISO/IEC 27007:2020 è più specifica per l’audit del SGSI. Zenith Controls osserva che gli auditor possono intervistare responsabili degli Approvvigionamenti, personale di sicurezza IT e vendor manager per valutare comprensione ed esecuzione dei controlli della catena di fornitura ICT. Per la preparazione agli incidenti, confermano che esista un Team di risposta agli incidenti e che sia operativo. Per il riesame indipendente, verificano che il programma di audit interno copra l’intero campo di applicazione del SGSI e disponga di risorse adeguate.

Un valutatore dei test basato su NIST SP 800-115 si concentrerà sulla metodologia di valutazione delle vulnerabilità e test di penetrazione. Potrà esaminare se ambito del test, regole di ingaggio, risultanze, classificazione di gravità, remediation e retest siano documentati. Per DORA TLPT, ciò significa che il valutatore non si accontenterà di un set di slide del Red Team. Vorrà prove di governance, sicurezza, profondità tecnica e chiusura.

Un auditor in stile COBIT 2019 o ISACA chiederà se gli obiettivi di governance sono raggiunti: chi possiede il processo, come viene misurata la prestazione, come sono approvate le eccezioni e in che modo la direzione riceve assurance.

Checklist pratica di preparazione DORA 2026

Utilizzare questa checklist come baseline operativa per trasformare le ricerche su DORA in azioni.

Governance e mappatura RTS/ITS

• Mantenere un Registro di conformità DORA con area dell’obbligo, applicabilità, titolare, evidenze, frequenza di riesame e stato delle lacune.
• Mappare i requisiti DORA a politiche, registri, controlli e reportistica alla direzione.
• Definire la motivazione di proporzionalità per la gestione del rischio ICT semplificata o scalata, ove applicabile.
• Assegnare responsabilità esecutiva per rischio ICT, segnalazione degli incidenti, governo delle terze parti e test.
• Includere lo stato DORA nel Riesame della direzione e nella reportistica del rischio all’organo di gestione.

Gestione del rischio ICT

• Mantenere un registro dei rischi ICT con descrizione, probabilità, impatto, punteggio, titolare e Piano di trattamento del rischio.
• Collegare i rischi a funzioni critiche o importanti.
• Collegare i rischi ad asset ICT, fornitori e processi.
• Riesaminare i rischi dopo incidenti rilevanti, modifiche dei fornitori, modifiche tecnologiche o risultanze dei test.
• Tracciare le azioni di trattamento fino alla chiusura o all’accettazione formale del rischio.

Governo ICT delle terze parti

• Mantenere un Registro dei fornitori e un registro delle dipendenze dai fornitori.
• Identificare i fornitori che supportano funzioni critiche o importanti.
• Valutare i fornitori in fornitura esclusiva e la sostituibilità.
• Riesaminare subappaltatori e accordi di sub-outsourcing.
• Integrare nei contratti clausole di sicurezza, accesso, segnalazione degli incidenti, audit e uscita.
• Monitorare i fornitori critici almeno annualmente o dopo modifiche significative.
• Mantenere piani di uscita e di contingenza per i fornitori ad alta dipendenza.

Gestione e segnalazione degli incidenti

• Mantenere procedure di risposta agli incidenti con ruoli e percorsi di escalation chiari.
• Definire criteri di classificazione degli incidenti ICT.
• Allineare i trigger di segnalazione DORA con GDPR, NIS2 e obblighi contrattuali di notifica.
• Formare dipendenti e contraenti sui canali di segnalazione degli incidenti.
• Mantenere log degli incidenti, registrazioni delle decisioni ed evidenze.
• Condurre riesami post-incidente e aggiornare rischi e controlli.

Test, red teaming e TLPT

• Mantenere un calendario dei test basato sul rischio.
• Eseguire scansioni di vulnerabilità e test di penetrazione a intervalli definiti.
• Utilizzare esercitazioni red team basate su scenari per testare rilevazione e risposta.
• Per la preparazione TLPT, definire ambito, regole di ingaggio, controlli di sicurezza e coordinamento dei fornitori.
• Proteggere i sistemi di produzione durante i test.
• Tracciare risultanze, remediation, retest e lezioni apprese.
• Comunicare gli esiti dei test alla direzione.

Continuità e ripristino

• Eseguire annualmente la BIA per le unità aziendali critiche e aggiornarla dopo modifiche significative.
• Definire obiettivi di ripristino per funzioni critiche e servizi ICT di supporto.
• Testare le capacità BCP e DR almeno annualmente.
• Includere scenari di indisponibilità dei fornitori e incidenti informatici.
• Conservare evidenze dei test, lacune, azioni di rimedio e risultati dei retest.
• Allineare i piani di continuità con risposta agli incidenti e comunicazioni di crisi.

Come Clarysec aiuta le entità finanziarie a passare dai risultati di ricerca alle evidenze pronte per l’audit

La preparazione a DORA 2026 non si ottiene scaricando una checklist e sperando che l’organizzazione colmi le lacune in seguito. Richiede un modello operativo strutturato che colleghi rischio, fornitori, incidenti, test, continuità ed evidenze di audit.

L’approccio Clarysec combina tre livelli.

Primo, Zenith Blueprint fornisce la roadmap di attuazione. Il Passo 14 aiuta le organizzazioni a creare riferimenti incrociati tra requisiti normativi, trattamento del rischio e politiche. Il Passo 16 rafforza la segnalazione degli incidenti guidata dal personale. Il Passo 21 garantisce che audit e test non mettano a rischio i sistemi di produzione. Il Passo 23 trasforma il governo dei fornitori in un flusso operativo pratico che copre classificazione, contratti, subappaltatori, monitoraggio e valutazione cloud.

Secondo, le politiche Clarysec forniscono una governance pronta per l’operatività. La Politica di gestione del rischio, la Politica di conformità legale e normativa, la Politica di sicurezza delle terze parti e dei fornitori, la Politica di gestione del rischio di dipendenza dai fornitori, la Politica di risposta agli incidenti, la Politica di Test di sicurezza e Red Teaming e la Politica di continuità operativa e disaster recovery offrono ai team clausole concrete, modelli di responsabilità e aspettative sulle evidenze.

Terzo, Zenith Controls fornisce la mappa di conformità trasversale. Mostra come sicurezza della catena di fornitura ICT, pianificazione della gestione degli incidenti e riesame indipendente si collegano a DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 e pratiche di test NIST.

Il risultato è un programma di conformità DORA difendibile in audit e utile durante un incidente reale, un fallimento di un fornitore o un test di resilienza.

Prossimo passo: costruire il pacchetto di evidenze DORA prima della prossima richiesta di audit

Se il vostro team sta ancora cercando “checklist DORA RTS/ITS”, “modello di gestione del rischio ICT DORA”, “vigilanza DORA sulle terze parti” o “requisiti DORA TLPT”, il passo successivo è trasformare quelle ricerche in evidenze controllate.

Iniziate con quattro azioni questa settimana:

1. Create o aggiornate il Registro di conformità DORA utilizzando il modello di politiche Clarysec.
2. Selezionate una funzione critica e tracciatela attraverso registro dei rischi, registro delle dipendenze dai fornitori, flusso operativo degli incidenti, BIA e piano di test.
3. Riesaminate i vostri cinque principali fornitori ICT per sostituibilità, subappaltatori, clausole sugli incidenti e opzioni di uscita.
4. Costruite un pacchetto di evidenze dei test con ambito, autorizzazione, risultati, remediation e retest.

Clarysec può aiutarvi a implementare questo approccio utilizzando Zenith Blueprint, modelli di politiche e Zenith Controls, affinché il vostro programma DORA 2026 sia pratico, proporzionato e pronto per l’audit.