Propensione al rischio ICT DORA: guida all’approvazione del consiglio di amministrazione per il 2026

Sono le 08:15 di un martedì e il Responsabile della sicurezza delle informazioni (CISO) di una società di tecnologie di pagamento di medie dimensioni è fuori dalla sala del consiglio, con tre documenti aperti su un tablet.

Il primo è il registro dei rischi ICT. Contiene 137 righe, valutazioni codificate a colori e diversi rischi elevati collegati a concentrazione cloud, accesso privilegiato, ripristino da ransomware, esposizione dei dati dei clienti e risposta agli incidenti dei fornitori. Il secondo è il tracker di preparazione DORA. Indica che l’azienda dispone di politiche, procedure per gli incidenti, registri di terze parti e piani di test della resilienza. Il terzo è il pacchetto informativo per il consiglio in vista di una riunione con finalità regolamentari.

Il presidente ha una sola domanda, e non è tecnica:

“Quale livello di rischio ICT abbiamo effettivamente concordato di accettare?”

La sala tace perché l’azienda dispone di valutazioni del rischio, ma non di una propensione al rischio ICT approvata dal consiglio di amministrazione. Ha valutazioni di impatto, ma non soglie di tolleranza misurabili. Tiene riunioni di escalation, ma non ha un criterio formale che stabilisca quando un rischio cyber diventa una decisione dell’organo di gestione. Ha accettato rischi residui, ma alcuni sono giustificati come “decisioni aziendali” senza un collegamento chiaro con i criteri di rischio, la proporzionalità di GDPR Article 32, le aspettative di tolleranza DORA o l’accountability del management prevista da NIS2.

Questa lacuna è sempre più evidente nel 2026. DORA si applica dal 17 gennaio 2025 e richiede alle entità finanziarie di mantenere un quadro di governance e controllo per il rischio ICT, includendo la responsabilità dell’organo di gestione per il quadro di gestione del rischio ICT, la strategia di resilienza operativa digitale e la tolleranza al rischio ICT. NIS2 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza e di supervisionarne l’attuazione. GDPR Article 32 richiede misure tecniche e organizzative di sicurezza adeguate e basate sul rischio. ISO/IEC 27001:2022 fornisce i meccanismi del sistema di gestione: contesto, parti interessate, criteri di rischio, piani di trattamento, informazioni documentate e riesame da parte della direzione.

Il ponte mancante è una dichiarazione di propensione e tolleranza al rischio ICT che un consiglio possa comprendere, approvare, mettere in discussione e utilizzare.

Questa guida spiega come costruire quel ponte utilizzando Zenith Blueprint: una roadmap in 30 passi per auditor di Clarysec, la Politica di gestione del rischio di Clarysec, la Politica di gestione del rischio per PMI di Clarysec e Zenith Controls: la guida alla conformità trasversale.

Perché i registri dei rischi non sono propensione al rischio

Molte organizzazioni confondono un registro dei rischi con la governance del rischio. Un registro dei rischi indica quali rischi esistono, come sono valutati, chi ne è titolare e quale trattamento è pianificato. Non risponde automaticamente alle domande a livello di consiglio che DORA, NIS2, GDPR e ISO/IEC 27001:2022 si aspettano che i vertici affrontino.

Una dichiarazione matura di propensione al rischio ICT risponde a domande come:

• Quali rischi ICT sono inaccettabili indipendentemente dal costo?
• Quale indisponibilità operativa può tollerare l’azienda per una funzione critica o importante?
• Quale livello di perdita di dati o compromissione dell’integrità dei dati è fuori propensione?
• Quale rischio di concentrazione di terze parti richiede l’attenzione del consiglio?
• Chi può accettare il rischio ICT residuo e a quale livello?
• Quando un rischio deve essere sottoposto a escalation verso l’alta direzione o l’organo di gestione?
• In che modo i requisiti legali, normativi e contrattuali sono integrati nei criteri di rischio?

Ai sensi di DORA, non si tratta di un perfezionamento opzionale della governance. Article 5 richiede all’organo di gestione di definire, approvare, supervisionare e assumere la responsabilità del quadro di gestione del rischio ICT, inclusa la strategia di resilienza operativa digitale e la tolleranza al rischio ICT. Article 6 richiede un quadro documentato di gestione del rischio ICT, un riesame annuale per le imprese non micro, l’audit interno, la remediation delle risultanze critiche dell’audit e una strategia di resilienza operativa digitale con obiettivi ICT, tolleranza al rischio, tolleranza all’impatto, architettura, test e strategia di comunicazione degli incidenti.

NIS2 aggiunge un modello parallelo di accountability. Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate basate su un approccio multirischio, includendo analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, efficacia dei controlli, formazione, cifratura, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e MFA ove appropriato.

Per le entità finanziarie, DORA è trattato come atto giuridico dell’Unione specifico di settore quando si applicano obblighi NIS2 sovrapposti. In pratica, DORA generalmente prevale sui requisiti NIS2 sovrapposti di gestione dei rischi e segnalazione degli incidenti per le entità finanziarie rientranti nel suo campo di applicazione, mentre NIS2 resta importante per il coordinamento e per i fornitori al di fuori degli obblighi diretti di DORA verso le entità finanziarie. Per fornitori SaaS, cloud, prestatori di servizi gestiti e servizi di sicurezza gestiti, NIS2 può applicarsi direttamente quando sono soddisfatte le condizioni di campo di applicazione.

Ecco perché la propensione al rischio ICT approvata dal consiglio non è più un artefatto di rischio finanziario. È un controllo di governance della cibersicurezza.

Usa ISO/IEC 27001:2022 come sistema operativo

DORA e NIS2 indicano ai vertici cosa deve essere governato. ISO/IEC 27001:2022 offre alle organizzazioni un sistema operativo pratico per governarlo.

ISO/IEC 27001:2022 Clauses 4.1 to 4.4 richiedono all’organizzazione di definire contesto, parti interessate, requisiti, campo di applicazione del SGSI e processi del SGSI. Questo è importante perché DORA, NIS2, GDPR, contratti, aspettative delle autorità di vigilanza, clienti, fornitori cloud e accordi di outsourcing diventano tutti requisiti che influenzano i criteri di rischio.

Clauses 5.1 to 5.3 richiedono impegno della leadership, allineamento delle politiche, risorse, responsabilità e rendicontazione delle prestazioni del SGSI all’alta direzione. Clauses 6.1.1 to 6.1.3 richiedono pianificazione basata sul rischio, un processo documentato di valutazione del rischio, criteri di accettazione del rischio, criteri di valutazione coerenti, titolari del rischio, confronto con i criteri di rischio, pianificazione del trattamento, una Dichiarazione di applicabilità e approvazione del rischio residuo.

Questa è la base per la tolleranza al rischio ICT DORA.

Nella fase di gestione del rischio, il passo 10 di Zenith Blueprint indica alle organizzazioni di definire i criteri di rischio prima di valutare i rischi:

“I criteri di rischio sono le regole e i benchmark che la tua organizzazione utilizza per valutare la significatività di ciascun rischio. Stabilire questi criteri in anticipo garantisce che tutti parlino lo stesso linguaggio del rischio.”

Lo stesso passo avverte che l’impatto normativo deve essere integrato nelle definizioni di rischio:

“Qualsiasi rischio che possa portare a non conformità con le leggi applicabili (GDPR, ecc.) non è accettabile e deve essere mitigato.”

Zenith Blueprint fornisce anche indicazioni pratiche per la scala degli impatti:

“Quando definisci l’impatto, è opportuno collegare i livelli alla scala specifica della tua attività. Ad esempio, ‘Impatto finanziario rilevante = perdita > $100k’ (da adattare al tuo contesto). Considera anche l’impatto normativo: ad esempio, una violazione dei dati personali potrebbe essere automaticamente ‘Rilevante’ o ‘Grave’ a causa delle sanzioni GDPR e dei requisiti di notifica, anche se la perdita finanziaria diretta non è chiara. Analogamente, se rientri nel campo di applicazione di NIS2 (servizi essenziali), un incidente che causa interruzione del servizio potrebbe essere almeno ‘Rilevante’ per le implicazioni legali. Includi tali considerazioni nelle tue definizioni.”

Questa indicazione evita un errore comune: valutare un rischio cyber come moderato perché la perdita finanziaria immediata appare limitata, ignorando l’impatto legale, sulla resilienza operativa, sugli interessati o sui clienti.

Un modello pronto per il consiglio dovrebbe distinguere quattro livelli:

Questa struttura rende verificabile in audit la propensione al rischio perché ogni dichiarazione può essere ricondotta a criteri di rischio, controlli, evidenze e decisioni.

Una dichiarazione di propensione al rischio ICT DORA pronta per il consiglio

Una solida dichiarazione di propensione al rischio ICT è abbastanza breve da essere approvata dal consiglio, abbastanza specifica da essere applicata dalla direzione e abbastanza misurabile da essere verificata dagli auditor. Deve evitare il gergo, ma non può essere vaga.

Una dichiarazione pratica di alto livello potrebbe essere:

“La nostra azienda ha una bassa propensione ai rischi ICT che potrebbero comportare danni significativi ai clienti, interruzione di funzioni critiche o importanti, divulgazione o alterazione non autorizzata di dati regolamentati, mancato rispetto di obblighi legali o perdita di resilienza nei servizi ICT critici di terze parti.”

Questa dichiarazione richiede poi soglie di tolleranza misurabili e criteri di escalation.

Questa tabella cambia la conversazione. Il consiglio non approva più uno slogan. Approva confini operativi per disponibilità, riservatezza, integrità, fornitori, vulnerabilità, ripristino e conformità.

La Politica di gestione del rischio di Clarysec supporta questo modello di governance. La policy enterprise stabilisce:

“Approva il quadro per la gestione del rischio e definisce la propensione al rischio accettabile e le soglie di tolleranza.”

La Clause 6.2.1 rende esplicito il requisito di misurazione:

“I rischi devono essere valutati per probabilità e impatto utilizzando una matrice del rischio standard con scale di punteggio chiaramente definite.”

La Clause 6.3.4 crea la regola di accettazione che gli auditor si aspettano:

“I rischi accettati senza trattamento devono essere giustificati per iscritto, collegati alla propensione al rischio dell’organizzazione e approvati al livello appropriato.”

Per le PMI, la Politica di gestione del rischio per PMI mantiene lo stesso principio di governance in un formato più leggero:

“Garantire il coinvolgimento della direzione nell’approvazione della tolleranza al rischio e dei principali piani di trattamento del rischio.”

Richiede inoltre l’escalation dei rischi elevati:

“I rischi elevati devono essere sottoposti a escalation verso il Direttore generale per decisione.”

Questa è proporzionalità in pratica. DORA Article 4 richiede che i requisiti siano applicati in modo proporzionato alla dimensione, al profilo di rischio e alla natura, scala e complessità dei servizi. ISO/IEC 27001:2022 abilita lo stesso principio attraverso ambito di applicazione, contesto, criteri di rischio e decisioni di trattamento. Lo standard di governance non è che ogni organizzazione debba avere la stessa struttura di comitati. Lo standard di governance è che propensione al rischio, tolleranza, escalation e accettazione siano definite, approvate, comprovate da evidenze e utilizzate.

GDPR Article 32 cambia la conversazione sul rischio

GDPR Article 32 è spesso trattato come una clausola tecnica di sicurezza. In termini di governance, è anche una clausola di propensione al rischio.

Article 32 richiede a titolari del trattamento e responsabili del trattamento di attuare misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio. Questo approccio basato sul rischio considera lo stato dell’arte, i costi di attuazione, la natura, l’ambito di applicazione, il contesto e le finalità del trattamento, nonché i rischi per i diritti e le libertà delle persone fisiche.

Ciò incide sulla propensione al rischio ICT in tre modi.

In primo luogo, l’impatto sui dati personali non può essere ridotto alla perdita finanziaria. L’esposizione di una piccola banca dati può avere costi diretti limitati ma gravi conseguenze in termini di riservatezza, identità, frode, discriminazione o impatto sui diritti. Se sono coinvolte categorie particolari di dati personali, come dati sanitari, biometrici o genetici, la propensione dovrebbe essere sostanzialmente inferiore.

In secondo luogo, i ruoli nel trattamento devono collegarsi alla titolarità del rischio. GDPR distingue titolari del trattamento e responsabili del trattamento. DORA distingue entità finanziarie e fornitori terzi di servizi ICT. NIS2 distingue soggetti essenziali e importanti. ISO/IEC 27001:2022 richiede titolari del rischio. Una dichiarazione matura di propensione dovrebbe identificare chi è titolare delle decisioni di rischio che riguardano dati personali, trattamento esternalizzato, servizi critici e dipendenze transfrontaliere.

In terzo luogo, la proporzionalità di Article 32 dovrebbe essere visibile nella selezione dei controlli. Cifratura, pseudonimizzazione, controllo degli accessi, backup, registrazione, monitoraggio, risposta agli incidenti e resilienza non sono attività tecniche isolate. Sono misure di trattamento selezionate perché un rischio ha superato la propensione o la tolleranza.

La Politica di gestione del rischio di Clarysec collega esplicitamente questo punto:

“Article 32: impone un approccio basato sul rischio alle misure di sicurezza, soddisfatto mediante valutazioni del rischio basate sull’impatto e selezione dei controlli.”

Questo è il collegamento operativo che gli auditor cercano: requisito Article 32, valutazione del rischio, punteggio di rischio, piano di trattamento del rischio, selezione dei controlli, rischio residuo e approvazione.

In che modo Zenith Controls supporta le evidenze di conformità trasversale

Una dichiarazione di propensione approvata dal consiglio diventa efficace quando è mappata ai controlli. Zenith Controls funge da guida alla conformità trasversale di Clarysec, aiutando i team a riutilizzare evidenze tra ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF e assurance in stile COBIT.

Tre aree di controllo ISO/IEC 27002:2022 sono particolarmente importanti:

Non si tratta di un esercizio di mappatura cartacea. Cambia il modo in cui vengono prese le decisioni.

Se un titolare dell’attività chiede di accettare un ritardo nel rollout MFA per gli amministratori, Zenith Controls aiuta il CISO a dimostrare perché non è solo una questione di controllo degli accessi. Tocca governance delle politiche, responsabilità della direzione, requisiti legali e normativi, sicurezza del trattamento GDPR, gestione del rischio ICT DORA, misure di cibersicurezza NIS2, impatto degli incidenti ed evidenze di audit.

Se un team di prodotto vuole lanciare in un nuovo mercato UE utilizzando un nuovo servizio cloud, il controllo ISO/IEC 27002:2022 5.31 porta il riesame dei requisiti legali e normativi nel campo di applicazione del SGSI. ISO/IEC 27001:2022 Clause 4.2 richiede l’identificazione dei requisiti delle parti interessate, inclusi obblighi legali, normativi e contrattuali. Clause 8.1 richiede pianificazione e controllo operativi, incluso il controllo di processi, prodotti o servizi forniti esternamente e rilevanti per il SGSI.

L’obiettivo è un unico linguaggio del rischio, non dialetti di conformità separati.

Flusso di approvazione: chi decide cosa

Un CISO può proporre la propensione al rischio ICT, ma il consiglio o l’organo di gestione deve esserne titolare. Questa titolarità richiede un flusso di approvazione.

Questo è allineato anche con NIST CSF 2.0. La funzione GOVERN, in particolare GV.RM, prevede obiettivi concordati di gestione del rischio, dichiarazioni di propensione e tolleranza al rischio, attività di rischio integrate nella gestione del rischio aziendale, opzioni definite di risposta al rischio, linee di comunicazione e metodi standardizzati per calcolare, documentare, categorizzare e prioritizzare i rischi di cibersicurezza. GV.RR prevede accountability della leadership, ruoli, autorità e risorse allineati alla strategia di rischio. GV.PO prevede che le politiche siano stabilite, comunicate, applicate, riesaminate e aggiornate.

I professionisti dell’assurance in stile COBIT 19 e ISACA chiederanno se la propensione al rischio è integrata nella governance aziendale dell’informazione e della tecnologia, e non semplicemente allegata come appendice a una policy cyber.

Costruisci un pacchetto di propensione al rischio ICT in una sessione di lavoro

Un workshop pratico sulla propensione al rischio ICT può portare un’organizzazione da registri dispersi a un pacchetto per il consiglio verificabile in audit.

Passo 1: raccogli gli input corretti

Prepara il registro dei rischi ICT corrente, la Business Impact Analysis, gli obiettivi di ripristino, l’elenco delle funzioni critiche o importanti, l’inventario degli asset ICT, l’inventario dei servizi ICT, il registro delle dipendenze da fornitori e cloud, i criteri di classificazione degli incidenti, l’inventario dei trattamenti GDPR, le DPIA ove pertinenti, il registro degli obblighi legali, le politiche, la Dichiarazione di applicabilità e la dichiarazione esistente di propensione al rischio aziendale.

Questo è allineato con ISO/IEC 27001:2022 Clauses 4, 6 and 8 e con i metodi di profilo NIST CSF che partono da priorità aziendali, priorità di rischio, requisiti, misure di sicurezza e ruoli.

Passo 2: definisci scale di impatto che includano la regolamentazione

Utilizzando il passo 10 di Zenith Blueprint, definisci probabilità e impatto nel linguaggio dell’attività. Includi perdita finanziaria, interruzione operativa, impatto sui clienti, danno reputazionale, impatto legale e normativo, danno agli interessati e impatto sulle funzioni critiche.

Ad esempio, un impatto “Rilevante” potrebbe includere un’interruzione prolungata di un servizio critico, una violazione dei dati personali confermata che richiede notifica, il mancato rispetto di un obbligo di segnalazione degli incidenti DORA o un fallimento del fornitore che incida su una funzione critica o importante.

Passo 3: scrivi la propensione per dominio

Non creare una propensione cyber generica. Definisci domini come disponibilità dei servizi critici, riservatezza dei dati personali, integrità dei dati, accesso privilegiato, dipendenza ICT da terze parti, concentrazione cloud, esposizione alle vulnerabilità, preparazione alla segnalazione degli incidenti, backup e ripristino, e rischio di modifica nello sviluppo sicuro.

Per ciascun dominio, scrivi una dichiarazione di propensione, una o più soglie di tolleranza e criteri di escalation.

Passo 4: collega il trattamento alla Dichiarazione di applicabilità

Il passo 13 di Zenith Blueprint indica alle organizzazioni di scegliere le opzioni di trattamento del rischio: mitigare, evitare, trasferire o accettare. Sottolinea inoltre l’approvazione della direzione:

“Le decisioni di trattamento del rischio e la SoA devono essere riesaminate e approvate dall’alta direzione.”

Per DORA e NIS2, questa è evidenza che l’organo di gestione o la leadership delegata ha riesaminato rischi chiave, trattamenti ed esposizione residua accettata. Per GDPR, supporta l’accountability mostrando perché le misure selezionate erano adeguate al rischio.

Passo 5: registra l’accettazione con scadenza e condizioni

Ogni rischio residuo medio o elevato accettato dovrebbe includere:

• ID del rischio e titolare
• Motivazione aziendale
• Riferimento alla dichiarazione di propensione
• Soglia di tolleranza interessata
• Analisi legale e normativa
• Controlli compensativi
• Data di scadenza o riesame
• Approvatore
• Posizione delle evidenze
• Criteri per riaprire la decisione

La Politica di gestione del rischio per PMI stabilisce:

“Qualsiasi decisione di accettare o rinviare il trattamento di un rischio elevato o medio deve essere documentata nel registro dei rischi. Tale documentazione deve includere:”

Negli ambienti enterprise, questo diventa un flusso di approvazione e un pacchetto per il comitato rischi. Nelle organizzazioni più piccole, può essere una scheda strutturata del registro dei rischi con approvazione formale della direzione. Il punto non è la burocrazia. Il punto è la sostenibilità della decisione.

Tolleranza agli incidenti: dove la propensione incontra il tempo

La propensione al rischio diventa reale durante gli incidenti.

DORA Article 17 richiede alle entità finanziarie di istituire un processo di gestione degli incidenti relativi alle ICT per rilevare, gestire e notificare incidenti, registrare tutti gli incidenti e le minacce informatiche significative, identificare le cause radice, utilizzare indicatori di allerta precoce, classificare gli incidenti per priorità, gravità e criticità del servizio, assegnare ruoli, comunicare agli stakeholder, sottoporre a escalation almeno gli incidenti rilevanti relativi alle ICT verso l’alta direzione e l’organo di gestione e ripristinare operazioni sicure in modo tempestivo.

DORA Article 18 classifica gli incidenti utilizzando fattori quali clienti interessati, durata, indisponibilità, diffusione geografica, perdite di dati che incidono su disponibilità, autenticità, integrità o riservatezza, criticità dei servizi interessati e impatto economico. Article 19 richiede che gli incidenti rilevanti relativi alle ICT siano segnalati all’autorità competente, con informativa ai clienti quando sono interessati i loro interessi finanziari.

NIS2 Article 23 prevede una segnalazione per fasi per gli incidenti significativi, inclusa un’allerta precoce senza indebito ritardo e, ove applicabile, entro 24 ore, una notifica dell’incidente senza indebito ritardo e, ove applicabile, entro 72 ore, aggiornamenti intermedi ove richiesti e una relazione finale non oltre un mese dalla notifica dell’incidente. Gli incidenti significativi includono quelli che causano grave interruzione operativa, perdita finanziaria o danni materiali o immateriali ad altri.

La dichiarazione di propensione dovrebbe definire le soglie di escalation prima che l’incidente accada.

I controlli dell’Annex A relativi a pianificazione degli incidenti, valutazione degli eventi di sicurezza delle informazioni, risposta agli incidenti, lezioni apprese dagli incidenti, raccolta delle evidenze, mantenimento della sicurezza delle informazioni durante le interruzioni e prontezza ICT per la continuità operativa supportano tutti queste soglie. Gli esiti NIST CSF attraverso IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER supportano lo stesso modello operativo, includendo backup, monitoraggio, dichiarazione dell’incidente, escalation, analisi della causa radice, comunicazione agli stakeholder e verifica del ripristino.

La tolleranza per fornitori e cloud che i consigli spesso trascurano

DORA rende il rischio ICT di terze parti un obbligo centrale di conformità. Article 28 richiede alle entità finanziarie di gestire il rischio ICT di terze parti come parte del quadro di gestione del rischio ICT, restando pienamente responsabili della conformità. Richiede strategia per il rischio ICT di terze parti, registri degli accordi contrattuali sui servizi ICT, distinzione dei servizi a supporto di funzioni critiche o importanti, reporting annuale, notifica degli accordi pianificati, valutazioni precontrattuali, due diligence, diritto di audit e ispezione, diritti di risoluzione e strategie di uscita documentate.

Article 29 aggiunge l’analisi del rischio di concentrazione, inclusi non sostituibilità, dipendenze multiple dallo stesso fornitore o da fornitori collegati, rischi di subappalto, subappaltatori di paesi terzi, conformità in materia di protezione dei dati, azionabilità e catene di subappalto complesse. Article 30 richiede diritti e obblighi contrattuali scritti, descrizioni dei servizi, sedi, protezioni di sicurezza, accesso e restituzione dei dati, livelli di servizio, assistenza sugli incidenti, cooperazione con le autorità, diritti di risoluzione, piani di continuità testati, monitoraggio e accordi di uscita.

Una dichiarazione di tolleranza verso i fornitori approvata dal consiglio potrebbe essere:

“Abbiamo una bassa propensione alla dipendenza di funzioni critiche o importanti da un fornitore terzo ICT quando non disponiamo di diritti contrattuali di audit, accordi di uscita testati, obblighi di notifica degli incidenti, obiettivi di livello di servizio, diritti di restituzione dei dati o visibilità sul subappalto sostanziale.”

Questa frase fornisce all’approvvigionamento una regola pratica. Se il contratto non soddisfa la soglia, il rischio non può essere accettato tacitamente dal gruppo di progetto.

Come gli auditor testeranno la tua propensione al rischio ICT

Una solida dichiarazione di propensione è progettata tenendo conto dell’audit.

Il passo 28 di Zenith Blueprint, nella fase Audit, riesame e miglioramento, rafforza il livello di riesame da parte della direzione. Indica alle organizzazioni di raccogliere input quali modifiche nelle questioni esterne e interne, prestazioni del SGSI, risultati degli audit, monitoraggio e misurazione, incidenti, non conformità, opportunità di miglioramento e bisogni di risorse. Stabilisce inoltre che il riesame da parte della direzione deve portare a decisioni e azioni, non solo a presentazioni.

Almeno annualmente, e ogni volta che vi siano modifiche sostanziali, la direzione dovrebbe riesaminare se le soglie di tolleranza sono ancora allineate al modello di business, se gli incidenti hanno superato la propensione, se i rischi accettati restano entro i confini approvati, se nuovi requisiti DORA, NIS2, GDPR o contrattuali hanno modificato la baseline, se i fornitori restano entro le tolleranze di concentrazione e se i KRI generano escalation tempestive.

Se la risposta è no, deve cambiare la dichiarazione di propensione oppure devono cambiare i controlli.

Schemi di fallimento comuni nelle attività di preparazione 2026

Nei progetti DORA, NIS2, GDPR e ISO/IEC 27001:2022 emergono ripetutamente le stesse debolezze:

• Propensione senza soglie, in cui il consiglio approva una dichiarazione ma nessuno sa dire quando è stata violata.
• Soglie senza autorità, in cui esistono livelli di gravità ma i titolari del rischio possono accettare eccezioni senza approvazione dell’alta direzione.
• Rischio legale fuori dal modello di punteggio, in cui GDPR, DORA, NIS2 e contratti sono elencati separatamente ma non integrati nei criteri di impatto.
• Tolleranza verso i fornitori assente dal pacchetto per il consiglio, anche se le dipendenze ICT critiche sono note all’approvvigionamento o all’IT.
• Riesame da parte della direzione come esercizio formale, in cui vengono presentate slide ma decisioni, azioni, bisogni di risorse e accettazioni del rischio non sono documentati.
• Frammentazione delle evidenze di audit, in cui politiche, registri, KRI, rapporti sugli incidenti, riesami dei fornitori e verbali del consiglio esistono in luoghi diversi senza riferimenti incrociati.

L’approccio di Clarysec è progettato per eliminare queste lacune. Zenith Blueprint fornisce il percorso di attuazione per fasi. La Politica di gestione del rischio e la Politica di gestione del rischio per PMI forniscono clausole di governance scalate per ambienti enterprise e PMI. Zenith Controls mappa la spina dorsale dei controlli attraverso la politica per la sicurezza delle informazioni, la responsabilità della direzione e i requisiti legali o normativi, rendendo le evidenze riutilizzabili tra ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF e assurance in stile COBIT.

Trasforma l’intento del consiglio in governance del rischio ICT verificabile in audit

Se la tua organizzazione ha un registro dei rischi ma non può mostrare una propensione al rischio ICT approvata dal consiglio, soglie di tolleranza misurabili, criteri di escalation e regole formali di accettazione, la lacuna non è estetica. Incide sulla governance DORA, sull’accountability del management NIS2, sulla sostenibilità di GDPR Article 32 e sulla preparazione agli audit ISO/IEC 27001:2022.

Un passo successivo pratico è svolgere un workshop focalizzato sulla propensione al rischio ICT utilizzando il toolkit di Clarysec:

1. Usa Zenith Blueprint passo 10 per definire criteri di rischio e scale di impatto.
2. Usa Zenith Blueprint passo 13 per collegare opzioni di trattamento, rischio residuo e approvazione della Dichiarazione di applicabilità.
3. Usa Zenith Blueprint passo 14 per creare riferimenti incrociati tra obblighi GDPR, NIS2 e DORA.
4. Usa Zenith Blueprint passo 28 per portare propensione, KRI, rischi accettati e decisioni sulle risorse nel riesame da parte della direzione.
5. Applica la Politica di gestione del rischio o la Politica di gestione del rischio per PMI per formalizzare regole di approvazione e accettazione.
6. Usa Zenith Controls per mappare i controlli di governance alle evidenze di audit e alle aspettative di conformità trasversale.

Clarysec può aiutarti a convertire artefatti di rischio dispersi in un modello di propensione al rischio ICT approvato dal consiglio e pronto per le autorità di regolamentazione, che i tuoi team possono utilizzare quando la prossima indisponibilità cloud, il prossimo fallimento di un fornitore, la prossima divulgazione di vulnerabilità o il prossimo incidente relativo ai dati personali metteranno alla prova la tolleranza reale dell’organizzazione.