Programma di test DORA: mappare i test su ISO 27001

È febbraio 2026. Il CISO di un istituto di pagamento di medie dimensioni ha una riunione dell’organo di gestione tra due giorni, un audit di sorveglianza ISO/IEC 27001:2022 tra sei settimane e una richiesta di vigilanza DORA nella casella di posta della funzione compliance.

L’autorità di regolamentazione non chiede una strategia di cybersicurezza patinata. La richiesta è operativa:

• Fornite il vostro programma di test della resilienza operativa digitale 2026.
• Indicate quali test coprono funzioni essenziali o importanti.
• Dimostrate come le risultanze vengono corrette e sottoposte a retest.
• Fornite evidenza della supervisione dell’organo di gestione.
• Spiegate come sono inclusi i fornitori terzi ICT.
• Fornite le registrazioni relative a valutazioni delle vulnerabilità, test basati su scenari, test di prestazioni e capacità e penetration test.

Il CISO apre quattro cartelle. Le scansioni di vulnerabilità sono nel sistema di gestione dei ticket del SOC. Le note delle esercitazioni tabletop sono in un’unità condivisa. I risultati dei test di carico sono gestiti dal team di ingegneria. I rapporti dei penetration test sono nel repository ad accesso ristretto della funzione legale. Il tracciamento della remediation è suddiviso tra Jira, e-mail e un foglio di calcolo creato per l’audit ISO dell’anno precedente.

Nulla è fittizio. Gran parte del lavoro è valido. Ma non è ancora un programma di test della resilienza operativa digitale DORA governato. È una raccolta di test.

Nel 2026 questa differenza è rilevante. DORA si applica dal 17 gennaio 2025 e istituisce un quadro uniforme dell’UE per la resilienza operativa digitale, che copre gestione del rischio ICT, segnalazione degli incidenti, test di resilienza, condivisione di informazioni su minacce informatiche e vulnerabilità, gestione del rischio di terze parti ICT, requisiti contrattuali e vigilanza sui fornitori terzi critici di servizi ICT. Si applica a un ampio insieme di entità finanziarie, tra cui enti creditizi, istituti di pagamento, imprese di investimento, prestatori di servizi per cripto-attività, imprese di assicurazione e altre entità regolamentate. DORA opera inoltre come atto giuridico settoriale dell’Unione per le entità finanziarie che altrimenti ricadrebbero in obblighi equivalenti di cibersicurezza previsti da NIS2.

La domanda pratica per organi di gestione, CISO, responsabili della compliance e fornitori ICT non è più se i test vengano svolti. La domanda è se i test siano pianificati, basati sul rischio, documentati da evidenze, corretti, riesaminati e riutilizzabili tra DORA e ISO/IEC 27001:2022.

Il modello operativo di Clarysec è costruito proprio per questo problema. Utilizzando Zenith Blueprint: An Auditor’s 30-Step Roadmap, la suite di politiche Clarysec allineata a ISO e Zenith Controls: The Cross-Compliance Guide, le organizzazioni possono trasformare attività di resilienza frammentate in un catalogo annuale dei test controllato, in grado di soddisfare autorità di vigilanza, auditor, clienti e organi di gestione.

Perché DORA trasforma i test in una questione di governance

DORA è esplicito sulla responsabilità esecutiva. Article 5 attribuisce all’organo di gestione la responsabilità della gestione del rischio ICT. Article 6 richiede un quadro di gestione del rischio ICT solido, completo e ben documentato, integrato nel sistema complessivo di gestione del rischio dell’organizzazione. Article 4 introduce il principio di proporzionalità, cioè l’applicazione dei requisiti in funzione di dimensioni, profilo di rischio complessivo e natura, portata e complessità di servizi, attività e operazioni.

Questo rende i test della resilienza operativa digitale qualcosa di più di un’attività tecnica. Diventano evidenza che l’organo di gestione comprende il rischio, ha approvato una strategia, riceve report significativi e indirizza la remediation.

ISO/IEC 27001:2022 utilizza una logica analoga di sistema di gestione. Le clausole 4.1-4.4 richiedono all’organizzazione di comprendere contesto, parti interessate, obblighi legali e contrattuali, ambito, interfacce e dipendenze. Le clausole 5.1-5.3 richiedono leadership, allineamento delle politiche, risorse, comunicazione, responsabilità assegnate e reportistica all’alta direzione. La clausola 6.1 richiede la valutazione del rischio per la sicurezza delle informazioni e il trattamento del rischio.

Un programma di test DORA deve quindi collegare:

• servizi aziendali e funzioni essenziali o importanti
• asset ICT, dati e dipendenze da terze parti
• valutazione del rischio, titolari del rischio e piani di trattamento del rischio
• tipologie di test, frequenza e trigger
• autorizzazione, indipendenza e regole di ingaggio
• risultanze, scadenze di remediation e retest
• conservazione delle evidenze e controllo degli accessi
• reportistica di direzione e miglioramento continuo

Per entità finanziarie più piccole o a minore rischio, Article 16 prevede un quadro semplificato di gestione del rischio ICT, ma semplificato non significa informale. Anche i programmi dimensionati in modo proporzionato richiedono comunque gestione documentata del rischio ICT, monitoraggio, sistemi resilienti, identificazione delle fonti di rischio ICT e delle anomalie, dipendenze chiave da terze parti ICT, misure di continuità e ripristino, test regolari e lezioni apprese.

In altri termini, DORA non premia il volume dei test. Premia test governati e basati sul rischio che dimostrano la resilienza dei servizi più rilevanti.

Che cosa deve contenere un programma di test DORA 2026?

Un programma di test DORA maturo deve operare come catalogo annuale dei test. Non deve limitarsi a un penetration test annuale o a un insieme di esportazioni di scansioni di vulnerabilità. Deve includere test di base e avanzati, pianificati in funzione di rischio, criticità del servizio, obblighi normativi, dipendenze dai fornitori, modifiche rilevanti e risultanze precedenti.

DORA Article 24 istituisce il programma di test della resilienza operativa digitale. Article 25 descrive un insieme di test, comprese valutazioni e scansioni delle vulnerabilità, analisi open source, valutazioni della sicurezza della rete, analisi delle lacune, riesami di sicurezza fisica, questionari, soluzioni software di scansione, riesami del codice sorgente ove possibile, test basati su scenari, test di compatibilità, test di prestazioni, test end-to-end e penetration test. Article 26 aggiunge i penetration test basati sulle minacce per le entità finanziarie individuate dalle autorità competenti.

Per la maggior parte delle organizzazioni, il catalogo operativo si costruisce intorno a quattro famiglie di test.

La Security Testing and Red-Teaming Policy di Clarysec fornisce un solido ancoraggio di policy per questo catalogo:

“Tipologie di test: il programma di Test di sicurezza deve includere, almeno: (a) scansioni di vulnerabilità, consistenti in scansioni automatizzate settimanali o mensili di reti e applicazioni per identificare vulnerabilità note; (b) penetration test, consistenti in test manuali approfonditi di specifici sistemi o applicazioni, eseguiti da tester qualificati, per identificare debolezze complesse; e (c) esercitazioni di red teaming, consistenti in simulazioni basate su scenari di attacchi reali, compresa l’ingegneria sociale e altre tattiche, per testare nel complesso le capacità di rilevamento e risposta dell’organizzazione.”

La stessa politica richiede una pianificazione regolare:

“Pianificazione dei test: l’organizzazione deve svolgere Test di sicurezza secondo una pianificazione regolare. I principali sistemi esposti a Internet e le applicazioni interne critiche devono essere sottoposti a penetration test almeno una volta l’anno. Le modifiche ad alto rischio, quali il deployment di un nuovo sistema critico o aggiornamenti rilevanti, richiedono test ad hoc prima e/o subito dopo la messa in esercizio in produzione.”

Questo è essenziale per DORA. Un piano annuale statico non è sufficiente se l’entità implementa un nuovo gateway di pagamento, migra un sistema core in cloud, cambia fornitore di servizi gestiti o rilascia un nuovo flusso di autenticazione dei clienti. Una modifica ad alto rischio deve attivare test aggiuntivi.

Costruire il catalogo annuale dei test come fonte unica di verità

Il modo più efficiente per soddisfare DORA e ISO/IEC 27001:2022 è creare un unico catalogo annuale dei test controllato. Può risiedere in una piattaforma GRC, in un workflow di gestione dei ticket o in un foglio di calcolo controllato. Il formato conta meno della tracciabilità.

Ogni test deve rispondere a cinque domande di audit:

1. Quale servizio, asset, fornitore, applicazione o processo è stato testato?
2. Quale rischio, obbligo o requisito di controllo ha attivato il test?
3. Chi ha autorizzato ed eseguito il test?
4. Quali risultanze sono state identificate, accettate, corrette o differite?
5. Quale evidenza dimostra che il test è stato eseguito e che l’esito è stato riesaminato?

Un catalogo pratico in stile Clarysec include questi campi.

La Audit and Compliance Monitoring Policy-sme - SME di Clarysec fornisce una regola di governance concisa che si adatta a questa struttura:

“Ogni audit deve includere un ambito definito, obiettivi, personale responsabile ed evidenze richieste.”

Sebbene sia scritta per gli audit, la stessa regola deve applicarsi ai test di resilienza. Se una scansione di vulnerabilità, un’esercitazione tabletop, una simulazione di failover o un penetration test non ha ambito, obiettivo, proprietario ed evidenze richieste definiti, sarà debole sia sotto scrutinio DORA sia in sede di audit ISO.

La stessa politica stabilisce:

“Le evidenze devono essere conservate per almeno due anni, o più a lungo ove richiesto da certificazioni o accordi con i clienti.”

Per le entità finanziarie e i fornitori ICT regolamentati da DORA, due anni devono essere considerati una soglia minima. Obblighi contrattuali, aspettative di vigilanza, cicli di certificazione e indagini sugli incidenti possono richiedere periodi di conservazione più lunghi.

Mappare le tipologie di test DORA sulle evidenze ISO 27001

Il valore di un programma integrato è che un singolo test può soddisfare più obblighi. Il punto chiave è etichettare correttamente le evidenze e collegarle all’ISMS.

Il Zenith Blueprint lo spiega nella fase Audit, Review & Improvement, Step 24:

“La vostra SoA deve essere coerente con il Registro dei rischi e con il Piano di trattamento del rischio. Verificate che ogni controllo scelto come trattamento del rischio sia contrassegnato come “Applicabile” nella SoA.”

Per un programma di test DORA, il catalogo dei test diventa il ponte tra trattamento del rischio ed evidenze operative. La Dichiarazione di Applicabilità non deve indicare che un controllo si applica mentre le evidenze dei test si trovano altrove, non mappate e non gestite.

Questa tabella aiuta un CISO a rispondere alla domanda tipica del CEO: “I nostri penetration test e le nostre scansioni di vulnerabilità ISO sono sufficienti per DORA?”

La risposta è: possono far parte della conformità a DORA, ma solo se sono basati sul rischio, collegati a funzioni essenziali o importanti, governati da policy, tracciati fino alla remediation e riportati alla direzione.

Valutazioni delle vulnerabilità: evidenze continue, non solo output di scansione

La valutazione delle vulnerabilità è spesso l’attività di test più facile da eseguire e più facile da gestire male. Molte organizzazioni possono produrre rapporti di scansione. Meno organizzazioni possono dimostrare che le scansioni coprono gli asset corretti, assegnano priorità ai servizi critici, generano remediation tempestiva e alimentano le decisioni di trattamento del rischio.

La Vulnerability and Patch Management Policy-sme - SME di Clarysec parte dall’obiettivo corretto:

“Identificare e valutare le vulnerabilità note su tutti gli asset IT in modo tempestivo e coerente”

Per DORA, ciò supporta l’identificazione delle fonti di rischio ICT, sistemi resilienti e aggiornati, monitoraggio, rilevamento delle anomalie e miglioramento continuo. Per ISO/IEC 27001:2022, si mappa direttamente su 8.8 Gestione delle vulnerabilità tecniche e si appoggia anche a 5.9 Inventario delle informazioni e degli altri asset associati, 8.16 Attività di monitoraggio e 8.32 Gestione delle modifiche.

Una registrazione solida della valutazione delle vulnerabilità deve includere:

• snapshot dell’inventario degli asset utilizzato per definire l’ambito
• data della scansione, strumento e metodo autenticato o non autenticato
• esclusioni e giustificazione aziendale
• risultanze per gravità, sfruttabilità e servizio aziendale
• mappatura su funzioni essenziali o importanti e tipi di dati
• riferimenti ai ticket e titolare del rischio
• SLA di remediation e data di scadenza
• risultato del retest
• eccezioni con approvazione del rischio residuo

Zenith Controls posiziona 8.8 Gestione delle vulnerabilità tecniche come area centrale di evidenza per identificazione, valutazione, prioritizzazione e tracciamento della remediation. Mostra anche perché gli auditor testeranno i processi adiacenti. Se l’inventario degli asset è incompleto, la copertura delle vulnerabilità è incompleta. Se la gestione delle modifiche viene aggirata, il deployment delle patch può creare nuovo rischio operativo. Se il monitoraggio è debole, i tentativi di sfruttamento potrebbero non essere rilevati.

Test di scenario: dimostrare il processo decisionale prima dell’incidente reale

I test di scenario sono il punto in cui la resilienza operativa diventa visibile ai dirigenti. Un tabletop su ransomware, una simulazione di indisponibilità di una regione cloud, un’esercitazione su compromissione di accessi privilegiati o uno scenario di fallimento di un fornitore ICT critico evidenzieranno debolezze che una scansione non può rilevare.

DORA Articles 17-20 richiedono un ciclo di vita formale degli incidenti connessi all’ICT: rilevare, gestire, notificare, registrare, monitorare, trattare, dare seguito, documentare la causa radice, correggere, classificare la gravità, assegnare ruoli, effettuare escalation degli incidenti gravi e trasmettere le segnalazioni nelle fasi richieste. Quando sono interessati gli interessi finanziari dei clienti, questi devono essere informati senza indebito ritardo.

NIS2 presenta urgenze analoghe per le entità nel proprio ambito, tra cui preallarme, notifica, reportistica intermedia e report finale. Per le entità finanziarie nel perimetro, DORA è l’atto giuridico settoriale per gli obblighi equivalenti di gestione del rischio e segnalazione in materia di cibersicurezza. I fornitori ICT, le piattaforme SaaS, gli MSP e gli MSSP devono comunque verificare se rientrano direttamente nel campo di applicazione di NIS2 o se vengono inclusi contrattualmente nell’assurance DORA dai clienti regolamentati.

Il Zenith Blueprint, nella fase Controls in Action, Step 23, fornisce il modello pratico di evidenza:

“Selezionate un evento recente o conducete un’esercitazione tabletop per validare il vostro piano. Acquisite e registrate tutte le decisioni, i ruoli e le comunicazioni (5.26) e aggiornate il piano con le lezioni apprese (5.27).”

Un test di scenario DORA deve produrre registrazioni verificabili in sede di audit, non solo appunti di riunione:

• sintesi dello scenario e obiettivi
• partecipanti e ruoli, compresi Legale, Comunicazione, IT, SOC, titolare dell’attività e contatti dei fornitori
• cronologia degli inject e delle decisioni
• decisione di classificazione e analisi delle soglie di segnalazione
• bozze di comunicazioni interne ed esterne
• azioni di preservazione delle evidenze
• lezioni apprese
• titolari delle azioni e date di scadenza
• procedure di incidente, continuità o comunicazione aggiornate

La Business Continuity Policy and Disaster Recovery Policy-sme - SME di Clarysec rafforza l’aspettativa di test annuale:

“L’organizzazione deve testare almeno annualmente sia il proprio BCP sia le capacità di DR. I test devono includere:”

Il catalogo dei test deve trasformare tale obbligo in esercitazioni specifiche, quali tabletop di gestione della crisi, test di ripristino dei backup, test di failover cloud, test dell’albero dei contatti e simulazione di interruzione di un fornitore.

Test di prestazioni, capacità e ripristino: le evidenze di resilienza trascurate

I test di prestazioni sono spesso trattati come una questione di ingegneria. In ambito DORA, diventano evidenze di resilienza.

Una piattaforma di trading, un servizio di pagamento, un sistema sinistri, una piattaforma di identità o un portale clienti non hanno bisogno di un attacco informatico per non funzionare per i clienti. Esaurimento della capacità, saturazione delle code, colli di bottiglia nei database, autoscaling configurato in modo errato o failover non funzionante possono generare la stessa interruzione operativa di un incidente di sicurezza.

ISO/IEC 27001:2022 Allegato A 8.6 Gestione della capacità è l’ancora principale. Le evidenze possono includere test di carico, stress test, test di degradazione del servizio, validazione delle soglie infrastrutturali, test di ripristino dei backup e simulazioni di failover.

Una buona registrazione dei test di prestazioni e capacità deve acquisire:

• carico normale di baseline e ipotesi di carico di picco
• percorsi critici delle transazioni testati
• limiti di infrastruttura e cloud testati
• dashboard di monitoraggio e soglie di allerta
• modalità di guasto, quali saturazione delle code o colli di bottiglia dei database
• rilevanza di RTO e RPO quando vengono testati failover o ripristino
• impatto aziendale in caso di superamento delle soglie
• azioni di remediation, decisioni di scaling o modifiche architetturali
• accettazione da parte della direzione del rischio residuo di capacità

Il Zenith Blueprint, Step 23, collega le aspettative di ripristino alle evidenze:

“Verificate che gli obiettivi di tempo di ripristino (RTO) e gli obiettivi di punto di ripristino (RPO) per i sistemi critici siano allineati alle aspettative di continuità operativa (5.30). Eseguite almeno un test tecnico di ripristino o una simulazione di failover e documentate i risultati.”

Questa è la differenza tra dire “abbiamo i backup” e dimostrare che un servizio critico è stato ripristinato entro la tolleranza concordata, con risultati documentati e visibilità da parte della direzione.

Penetration test e red teaming: evidenze forti richiedono controlli forti

I penetration test sono evidenze di grande valore, ma comportano anche rischio operativo. Test governati male possono influire sui sistemi di produzione, esporre dati sensibili, attivare allarmi non controllati, creare problemi legali o interrompere i servizi ai clienti.

La Application Security Requirements Policy-sme - SME definisce un gate di rilascio chiaro:

“Prima del deployment, tutte le Applicazioni devono essere sottoposte a Test di sicurezza per verificare le funzionalità di baseline elencate sopra.”

Per le applicazioni critiche, questo deve alimentare il catalogo DORA come test di sicurezza pre-produzione, validazione post-messa in esercizio per modifiche ad alto rischio e penetration test periodici basati su esposizione e criticità.

La Security Testing and Red-Teaming Policy rafforza la catena di remediation:

“Remediation delle risultanze: tutte le vulnerabilità o debolezze identificate devono essere documentate in un report delle risultanze con classificazione di gravità. Al ricevimento del report, i proprietari dei sistemi sono responsabili della creazione di un piano di remediation con date di scadenza; ad esempio, le risultanze critiche devono essere corrette entro 30 giorni e quelle ad alta gravità entro 60 giorni, in conformità alla Politica di gestione delle vulnerabilità e delle patch dell’organizzazione. Il STC deve tracciare l’avanzamento della remediation. Il retest deve essere eseguito per confermare che le problematiche critiche siano state risolte o adeguatamente mitigate.”

La stessa politica definisce le aspettative di reportistica:

“Reportistica: al termine di ogni test deve essere emesso un rapporto formale. Per i penetration test, il rapporto deve includere una sintesi esecutiva, la metodologia e risultanze dettagliate con evidenze a supporto e raccomandazioni.”

Il Zenith Blueprint, Step 21, evidenzia anche la protezione durante audit e test:

“Nessun test o audit deve procedere senza approvazione documentata da parte dei proprietari dei sistemi o degli stakeholder pertinenti.”

Regole di ingaggio, finestre di test, contatti di emergenza, accessi temporanei, gestione dei dati, logging, procedure di rollback e approvazioni legali non sono burocrazia. Sono misure di sicurezza per la resilienza.

Includere i fornitori terzi ICT prima che il test fallisca

DORA rende il rischio di terze parti ICT un tema centrale di resilienza. Article 28 richiede alle entità finanziarie di gestire il rischio di terze parti ICT nell’ambito del quadro di gestione del rischio ICT, di rimanere responsabili quando utilizzano servizi ICT, di mantenere un registro informativo, di segnalare determinati accordi, di svolgere valutazioni precontrattuali e di utilizzare fornitori che rispettino standard appropriati di sicurezza delle informazioni. Articles 29 e 30 trattano rischio di concentrazione, subappalto, ripristino dei dati, protezioni contrattuali, livelli di servizio, assistenza in caso di incidente, diritti di audit, test di continuità dei fornitori, partecipazione ai test ove pertinente e accordi di uscita.

ISO/IEC 27001:2022 Allegato A fornisce controlli di supporto sui fornitori, tra cui 5.19 Sicurezza delle informazioni nelle relazioni con i fornitori, 5.20 Trattamento della sicurezza delle informazioni negli accordi con i fornitori, 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT, 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori e 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud.

Un catalogo di test DORA deve identificare quali test richiedono la partecipazione dei fornitori o evidenze dei fornitori. Esempi:

• ipotesi di failover del fornitore cloud
• escalation del SOC gestito e preservazione delle evidenze
• comunicazione degli incidenti della piattaforma di core banking
• scenario di indisponibilità del processore dei pagamenti
• test di ripristino del provider di identità
• attestazioni dei penetration test del fornitore SaaS
• valutazione dell’impatto della catena dei subappaltatori critici

Un programma che esclude i fornitori ICT critici fallirà il test della realtà. Il servizio esposto al cliente può essere vostro, ma la dipendenza di resilienza può trovarsi in una regione cloud, in un SOC esternalizzato, in un provider di identità, in un fornitore software, in un processore dei pagamenti o in un data center.

Mappatura cross-compliance: un set di evidenze, molti obblighi

Un programma di test DORA ben progettato riduce l’affaticamento da audit. Le stesse evidenze possono supportare DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 e riesami di governance COBIT 2019 se sono etichettate, conservate e riportate correttamente.

Il GDPR non deve essere dimenticato. Se i test di resilienza coinvolgono dati personali, log, registrazioni dei clienti, dati di identità, registrazioni HR, dati biometrici o categorie particolari di dati, l’organizzazione deve rispettare i principi GDPR, tra cui liceità, correttezza, trasparenza, minimizzazione dei dati, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Copie di dati di test, log esportati ed evidenze dei penetration test possono diventare archivi di dati regolamentati. Il programma di test deve definire chi può accedervi, per quanto tempo sono conservati e come vengono smaltiti in modo sicuro.

Come gli auditor testeranno lo stesso programma

Un supervisore DORA, un auditor ISO, un valutatore basato su NIST, un revisore COBIT e un auditor cliente possono esaminare le stesse evidenze attraverso prospettive diverse.

Zenith Controls è utile qui come bussola cross-compliance. Per i test DORA, Clarysec evidenzia 5.35 Riesame indipendente della sicurezza delle informazioni, 8.8 Gestione delle vulnerabilità tecniche e 8.6 Gestione della capacità come ancore particolarmente importanti di ISO/IEC 27001:2022 Allegato A. Aiutano i titolari dei controlli a collegare i test all’assurance indipendente, al trattamento delle vulnerabilità e alla capacità operativa.

La Information Security Policy di Clarysec supporta anche la traccia di audit:

“I Proprietari dei controlli devono mantenere risultati dei test, log e registrazioni dei riesami a supporto degli audit periodici.”

Questa frase deve diventare una regola operativa. Ogni proprietario del test deve sapere che cosa conservare, dove conservarlo, come proteggerlo e come collegarlo alle evidenze di rischio e controllo.

Costruire un pacchetto di evidenze DORA-ISO in una settimana

Un’entità finanziaria o un fornitore ICT può compiere progressi significativi in cinque giorni lavorativi.

Giorno 1: definire ambito e criticità

Utilizzate la logica delle clausole 4.1-4.4 di ISO/IEC 27001:2022. Identificate parti interessate, obblighi normativi, obblighi contrattuali, interfacce e dipendenze. Elencate servizi aziendali, funzioni essenziali o importanti, asset chiave, tipi di dati e fornitori ICT.

Output: registro dell’ambito dei test DORA.

Giorno 2: creare il catalogo annuale dei test

Utilizzate le quattro famiglie di test: vulnerabilità, scenario, prestazioni e penetration test. Per ogni servizio, definite quali test si applicano, frequenza, proprietario, livello di indipendenza e trigger. Includete i trigger per modifiche ad alto rischio.

Output: catalogo dei test di resilienza operativa digitale 2026.

Giorno 3: mappare controlli e obblighi

Mappate ogni test su ISO/IEC 27001:2022 Allegato A, Registro dei rischi, SoA, articoli DORA, obblighi dei fornitori e voci pertinenti di Zenith Controls. Ad esempio, le scansioni mensili delle vulnerabilità esterne si mappano su 8.8 Gestione delle vulnerabilità tecniche, trattamento del rischio, monitoraggio, gestione del rischio ICT DORA e risultati NIST CSF sulle vulnerabilità.

Output: matrice di mappatura dei controlli.

Giorno 4: standardizzare le cartelle delle evidenze

Create una struttura di evidenze controllata:

• 01 Piano e autorizzazione
• 02 Ambito e regole di ingaggio
• 03 Risultati grezzi
• 04 Rapporto finale
• 05 Registro delle risultanze
• 06 Ticket di remediation
• 07 Evidenze di retest
• 08 Reportistica di direzione
• 09 Lezioni apprese e aggiornamenti delle politiche

Output: repository delle evidenze con regole di conservazione.

Giorno 5: riesaminare risultanze e reportistica

Consolidate le risultanze aperte per gravità, servizio, titolare del rischio e data di scadenza. Identificate remediation scadute, rischi accettati e lacune nei retest. Preparate una dashboard per l’organo di gestione che mostri copertura dei test, risultanze rilevanti, azioni scadute, problematiche di terze parti e rischio residuo.

Output: dashboard DORA e ISO pronta per l’organo di gestione.

Errori comuni nei programmi di test DORA

Il fallimento più comune non è la mancanza di test. È la mancanza di governance.

Attenzione a questi problemi:

• penetration test eseguiti annualmente, ma risultanze non tracciate fino alla chiusura
• scansioni di vulnerabilità eseguite frequentemente, ma asset critici mancanti dall’ambito
• esercitazioni tabletop svolte, ma senza log delle decisioni o piano d’azione sulle lezioni apprese
• test di ripristino dei backup completati, ma non mappati su RTO e RPO
• test di carico eseguiti dal team di ingegneria, ma non riportati a rischio o compliance
• fornitori ICT esclusi dai test di scenario e ripristino
• evidenze archiviate in cartelle personali, discussioni chat o unità non gestite
• report all’organo di gestione focalizzati sui conteggi delle attività anziché sul rischio di resilienza non risolto
• la SoA indica che un controllo si applica, ma non esiste alcuna evidenza di test
• i test creano rischio in produzione perché autorizzazione e confini non sono chiari

Ogni lacuna è risolvibile. Il rimedio non è aumentare i test casuali. Il rimedio è un unico programma controllato che collega rischio, attività di test, remediation, evidenze e supervisione della direzione.

Che cosa deve vedere davvero l’organo di gestione

DORA rende la resilienza ICT una responsabilità dell’organo di gestione. Un report utile per l’organo di gestione non deve includere ogni risultanza tecnica. Deve rispondere alla domanda se l’organizzazione sia sufficientemente resiliente rispetto alla propria propensione al rischio e alla tolleranza alle interruzioni.

Un report trimestrale o semestrale solido include:

• copertura dei test rispetto a funzioni essenziali o importanti
• test completati rispetto a quelli pianificati
• risultanze critiche e alte per servizio
• remediation scadute per proprietario
• tasso di superamento dei retest
• risultanze relative ai fornitori e preoccupazioni di concentrazione
• lezioni dei test di scenario che incidono sui piani di crisi o incidente
• rischi di capacità rispetto alla crescita aziendale e ai periodi di picco
• rischi residui che richiedono accettazione da parte della direzione
• vincoli di budget, risorse o strumenti

Questo report diventa input per il riesame di direzione ISO, evidenza di governance DORA e strumento decisionale pratico.

Dai test dispersi alla resilienza strategica

Il problema iniziale del CISO non era l’assenza di test. L’organizzazione disponeva di scansioni, tabletop, rapporti di carico e PDF di penetration test. Il problema era che queste attività non raccontavano ancora una storia coerente di evidenze.

Un programma di test unificato DORA e ISO/IEC 27001:2022 cambia questa situazione. La valutazione del rischio guida il catalogo. Il catalogo guida i test autorizzati. I test producono risultanze. Le risultanze guidano remediation e retest. I risultati alimentano la reportistica di direzione. Le lezioni apprese aggiornano politiche, procedure, contratti e controlli.

È così che un onere di conformità diventa una capacità strategica.

Clarysec aiuta le organizzazioni a evitare programmi di compliance paralleli. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 e COBIT 2019 non richiedono universi separati di evidenze. Richiedono un unico modello operativo governato, presentabile attraverso diverse prospettive di audit.

Il nostro approccio combina:

• Zenith Blueprint per l’implementazione ISO per fasi e la capacità di dimostrare la conformità in sede di audit
• Zenith Controls per la mappatura cross-compliance tra controlli, quadri di riferimento e aspettative di audit
• politiche Enterprise e SME per test di sicurezza, monitoraggio degli audit, gestione delle vulnerabilità, sicurezza delle applicazioni, continuità operativa e sicurezza delle informazioni
• registri pratici, strutture di evidenze e modelli di reportistica di direzione

Se le vostre evidenze di test DORA 2026 sono disperse tra strumenti di scansione, cartelle di ingegneria, note tabletop e PDF di penetration test, è il momento di consolidarle.

Iniziate da un catalogo annuale dei test mappato sul trattamento del rischio ISO/IEC 27001:2022, sulla vostra SoA, sulle funzioni essenziali o importanti, sulle terze parti ICT e sulla reportistica di direzione. Poi utilizzate Zenith Blueprint, Zenith Controls e il toolkit di policy di Clarysec per trasformare quel catalogo in evidenze di audit difendibili.

Clarysec può aiutarvi a progettare il programma, mappare i controlli, strutturare il pacchetto di evidenze e preparare il report di resilienza per l’organo di gestione prima che arrivi la prossima richiesta di vigilanza.