Checklist DORA Testing per Audit e Conformità 2026

Il Regolamento DORA è ufficialmente in applicazione dal 17 gennaio 2025. Per le entità finanziarie, il 2026 rappresenta l’anno della maturità operativa, in cui non basta più aver disegnato i processi, ma occorre dimostrarne l’efficacia attraverso prove documentali solide. La conformità non è un traguardo statico: le autorità richiedono un ciclo continuo di test, remediation e revisione della governance. Questa guida fornisce una checklist DORA testing esaustiva per verificare se la tua organizzazione è pronta per un audit interno o un’ispezione delle autorità di vigilanza.

Checklist Governance

• L’organo di gestione ha approvato formalmente il framework di gestione dei rischi ICT e la strategia sui rischi di terze parti.
• È stato redatto e inviato alle autorità il report annuale sulla revisione del framework di gestione dei rischi ICT.
• Sono stati definiti livelli di tolleranza al rischio ICT chiari e approvati.
• Esiste una procedura di revisione del framework attivata in caso di cambiamenti significativi nel panorama delle minacce o negli asset ICT.

Checklist Asset e Scoping

• È presente un Register of Information (RoI) completo di tutti gli accordi contrattuali con fornitori ICT terzi.
• Tutte le funzioni critiche o importanti (CIF) sono state identificate e mappate sui relativi asset ICT e fornitori.
• Ogni asset ICT ha un “owner” chiaramente identificato e una classificazione di criticità documentata.
• Sono state mappate le interdipendenze tra asset, funzioni e fornitori (inclusi i subappaltatori materiali).

Checklist Vulnerability Management

• Le scansioni delle vulnerabilità sugli asset che supportano funzioni critiche (CIF) avvengono con frequenza almeno settimanale.
• Esiste una procedura automatizzata per il rilevamento delle vulnerabilità su tutti gli asset ICT.
• L’utilizzo di librerie di terze parti (incluso open source) è tracciato e monitorato per aggiornamenti e patch.
• Le patch vengono prioritizzate in base alla criticità della vulnerabilità e al profilo di rischio dell’asset.
• Esiste un registro documentato che traccia l’intero ciclo di vita delle vulnerabilità, dalla scoperta alla verifica della chiusura.

Checklist Penetration Testing

• Il programma di test include verifiche di sicurezza appropriate per i sistemi esposti a Internet.
• Per le entità soggette a TLPT, i test sono condotti su sistemi di produzione reali (“live production systems”).
• I tester (interni o esterni) soddisfano i requisiti di idoneità, reputazione, certificazione e copertura assicurativa.
• I risultati dei test includono un’analisi delle cause profonde (root cause analysis) e un piano di remediation dettagliato.

Checklist Business Continuity

• I piani di continuità operativa ICT sono testati almeno annualmente o dopo modifiche significative.
• I test si basano su scenari severi ma plausibili, inclusi attacchi informatici e fallimento di fornitori critici.
• I test dimostrano il raggiungimento dei Recovery Time Objectives (RTO) e Recovery Point Objectives (RPO) definiti.
• Il programma include test di switchover verso siti secondari o ambienti di disaster recovery per un periodo rappresentativo.

Checklist Terze Parti

• È stata eseguita la due diligence su tutti i fornitori ICT che supportano funzioni critiche prima della stipula dei contratti.
• I contratti con fornitori ICT includono clausole esplicite sui diritti di audit e sulla partecipazione ai test di sicurezza.
• I fornitori segnalano tempestivamente le vulnerabilità critiche e le statistiche sui rischi relativi ai servizi forniti.
• L’entità ha visibilità sui subfornitori materiali coinvolti nella catena di fornitura delle CIF.

Checklist Evidence Pack per Audit

• Politiche e procedure: Gestione asset, vulnerabilità, incidenti e business continuity.
• Report di test: Verbali di scansione settimanale, report di pentest e TLPT.
• Piani di rimedio: Documentazione delle azioni correttive, scadenze e verifiche di chiusura (retest).
• Certificazioni e CV: Evidenze delle competenze e dell’indipendenza dei tester coinvolti.
• Registro delle informazioni: Template aggiornato secondo gli standard ITS.
• Report di incident management: Notifiche iniziali, report intermedi e finali sui principali incidenti ICT.

FAQ

• Quali documenti deve poter esibire l’azienda? Oltre alle policy approvate, sono vitali i report tecnici dei test, i piani di remediation firmati, i registri delle vulnerabilità e le evidenze di monitoraggio dei fornitori terzi.
• Come dimostrare che il testing è risk-based? Attraverso la documentazione della Business Impact Analysis (BIA) e della classificazione degli asset, che giustificano perché determinati sistemi sono testati più frequentemente o con metodologie più invasive.
• Cosa manca più spesso nei programmi DORA? Le carenze più comuni riguardano la mancata verifica della remediation (retest), l’assenza di visibilità sui subfornitori materiali e la frequenza insufficiente (non settimanale) delle scansioni sui sistemi critici.

Assicura la tua conformità per il 2026: richiedi oggi un Assessment di Audit Readiness DORA per identificare i gap nel tuo programma di testing e mettere in sicurezza le tue evidenze cybersecurity.