{"id":36186,"date":"2026-10-29T09:40:09","date_gmt":"2026-10-29T08:40:09","guid":{"rendered":"https:\/\/vanleeuwenlawfirm.eu\/it\/?p=36186"},"modified":"2026-10-29T09:52:19","modified_gmt":"2026-10-29T08:52:19","slug":"resilienza-operativa-digitale-nis2-e-dora","status":"publish","type":"post","link":"https:\/\/vanleeuwenlawfirm.eu\/it\/approfondimenti\/notizie-approfondimenti-personalizzati\/ia-resilienza-digitale\/resilienza-operativa-digitale-nis2-e-dora\/","title":{"rendered":"Resilienza operativa digitale, NIS2 e DORA"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La resilienza operativa digitale non rappresenta pi\u00f9, per la vostra organizzazione, una questione meramente tecnica legata alla cybersicurezza, alla disponibilit\u00e0 delle reti, ai backup, ai controlli degli accessi o al ripristino dei sistemi ICT. La questione centrale di governance consiste ormai nello stabilire se, in condizioni di grave perturbazione digitale, la vostra organizzazione sia in grado di proteggere, mantenere e ripristinare le proprie funzioni essenziali o importanti in modo controllato, verificabile e giuridicamente difendibile, rendendo al contempo conto delle decisioni adottate prima, durante e dopo l\u2019evento. Si tratta di un cambiamento sostanziale. Un\u2019organizzazione pu\u00f2 aver implementato misure tecniche di sicurezza avanzate e rimanere comunque insufficientemente preparata a un\u2019interruzione prolungata di un ambiente cloud, alla compromissione di identit\u00e0 digitali, a un incidente software presso un fornitore strategico, a un attacco ransomware su larga scala, alla perdita temporanea di accesso a dati essenziali, all\u2019interruzione delle infrastrutture di pagamento o al guasto simultaneo di pi\u00f9 sistemi interdipendenti. Le conseguenze giuridiche e operative di tali eventi dipendono sempre meno dal solo malfunzionamento tecnico iniziale o dal vettore d\u2019attacco e sempre pi\u00f9 dal modo in cui dipendenze, responsabilit\u00e0, poteri di escalation, priorit\u00e0 di ripristino, obblighi di comunicazione e relazioni contrattuali sono stati strutturati preventivamente. NIS2, la normativa nazionale di attuazione e il Digital Operational Resilience Act inseriscono questa evoluzione in un quadro regolamentare vincolante. Per le organizzazioni rientranti nell\u2019ambito di applicazione del regime NIS2, un sistema di obblighi in materia di gestione dei rischi, registrazione, notifica e governance richiede una dimostrabile capacit\u00e0 di controllo dei rischi di cybersicurezza. Per le entit\u00e0 finanziarie soggette a DORA, dal 17 gennaio 2025 si applica un regime europeo specifico relativo, tra l\u2019altro, alla gestione del rischio ICT, alla classificazione e notifica degli incidenti ICT gravi, ai test di resilienza operativa digitale, al rischio derivante da fornitori terzi di servizi ICT e alla supervisione dei fornitori critici. Il parametro di valutazione si \u00e8 quindi spostato dalla mera esistenza di politiche di cybersicurezza alla capacit\u00e0 di dimostrare il funzionamento effettivo di un sistema coerente in cui tecnologia, servizi critici, dipendenze dai fornitori, gestione delle crisi, supervisione del management e obblighi legali di accountability risultino realmente collegati.<\/p>

Per la vostra organizzazione ci\u00f2 significa che la resilienza operativa digitale deve essere considerata una questione di controllo a livello aziendale, nella quale analisi giuridica, tecnologia, gestione del rischio operativo, controllo interno, procurement, outsourcing, governance dei dati, crisis management, compliance, internal audit e processo decisionale esecutivo devono rimanere costantemente allineati. La domanda rilevante non consiste soltanto nello stabilire se un incidente informatico possa essere prevenuto, ma anche nel determinare quali processi debbano rimanere disponibili durante una perturbazione, quali sistemi siano indispensabili per sostenerli, quale durata massima dell\u2019indisponibilit\u00e0 sia accettabile, quali dati debbano rimanere disponibili e affidabili, quali fornitori siano in concreto indispensabili, quali capacit\u00e0 alternative siano realmente utilizzabili e quali decisioni debbano poter essere adottate entro tempi estremamente brevi durante una crisi. A ci\u00f2 si aggiunge il fatto che pi\u00f9 regimi giuridici possono applicarsi contemporaneamente senza necessariamente utilizzare la stessa terminologia, gli stessi criteri di ambito, le stesse soglie di notifica, le stesse relazioni di vigilanza o gli stessi requisiti di governance. Un\u2019entit\u00e0 finanziaria soggetta a DORA pu\u00f2, ad esempio, appartenere a un gruppo pi\u00f9 ampio nel quale altre societ\u00e0 siano principalmente soggette a NIS2, a prescrizioni settoriali, alla normativa sulla protezione dei dati, a regole prudenziali o a obblighi contrattuali di cybersicurezza. Un approccio integrato non richiede quindi che tutti gli obblighi legali vengano trattati come se fossero identici. Richiede piuttosto un modello centrale di governance nel quale, per ogni entit\u00e0, funzione critica, servizio, sistema, fornitore e categoria di incidente, sia possibile identificare il regime giuridico applicabile, la funzione responsabile dell\u2019azione, le informazioni che devono essere disponibili e gli elementi probatori necessari a dimostrare successivamente che sono state adottate misure adeguate. La vostra organizzazione deve quindi poter dimostrare che la continuit\u00e0 operativa digitale non dipende da conoscenze informali detenute da un numero limitato di specialisti tecnici, ma \u00e8 incorporata in responsabilit\u00e0 dimostrabili, capacit\u00e0 di ripristino testate, processi decisionali controllati, obblighi contrattuali opponibili ai fornitori e un organo di gestione in grado di comprendere e governare effettivamente i rischi digitali rilevanti.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

NIS2, normativa nazionale sulla cybersicurezza e obblighi settoriali in materia di sicurezza digitale<\/h4>

L\u2019attuazione di NIS2 ha trasformato, per molte organizzazioni, la cybersicurezza da ambito prevalentemente tecnico a specifica area di governance e responsabilit\u00e0 giuridica. Per la vostra organizzazione, un\u2019efficace conformit\u00e0 deve quindi iniziare con una precisa analisi dell\u2019ambito di applicazione. Occorre stabilire se l\u2019organizzazione nel suo complesso, una singola entit\u00e0 giuridica, una specifica attivit\u00e0 o un determinato servizio rientri in un settore regolamentato e quale qualificazione giuridica ne derivi. Tale valutazione pu\u00f2 risultare complessa quando gruppi societari svolgono pi\u00f9 attivit\u00e0, quando i servizi vengono erogati attraverso diverse entit\u00e0 giuridiche, quando le funzioni digitali di supporto sono centralizzate o quando prestatori esterni rivestono un ruolo essenziale nell\u2019erogazione di servizi regolamentati. Un\u2019analisi troppo restrittiva pu\u00f2 comportare la mancata individuazione di obblighi normativi o la loro identificazione tardiva. Un approccio eccessivamente ampio pu\u00f2 invece generare controlli inefficienti, obblighi di reporting non necessari e una perdita di focalizzazione a livello direzionale. La vostra organizzazione deve pertanto essere in grado di ricostruire quali servizi vengono erogati, quali qualificazioni giuridiche si applicano, quali sistemi e fornitori sostengono tali servizi e dove le relative responsabilit\u00e0 sono effettivamente allocate nel sistema di governance. Tale perimetro giuridico costituisce il punto di partenza per la valutazione dei rischi, la registrazione, le misure di gestione, la notifica degli incidenti, la supervisione da parte del management e il rapporto con le autorit\u00e0 competenti. L\u2019ambito di applicazione non deve essere considerato una qualificazione giuridica svolta una sola volta. Fusioni, acquisizioni, nuovi servizi digitali, cambiamenti nei criteri dimensionali o di fatturato, nuovi fornitori, riorganizzazioni interne e modifiche della disciplina settoriale possono alterare gli obblighi applicabili. La vostra organizzazione trae quindi vantaggio da un processo periodico di rivalutazione nel quale perimetro giuridico, attivit\u00e0 aziendali e dipendenze digitali vengano esaminati congiuntamente.<\/p>

Gli obblighi di diligenza e di gestione del rischio derivanti dal quadro NIS2 richiedono inoltre misure basate sul rischio, proporzionate alla natura delle vostre attivit\u00e0, alla probabilit\u00e0 delle minacce rilevanti, alle potenziali conseguenze sociali di una perturbazione e alle caratteristiche tecniche e organizzative del vostro ambiente digitale. Una politica generica di sicurezza delle informazioni non \u00e8 quindi sufficiente. La vostra organizzazione deve poter spiegare perch\u00e9 determinate misure di sicurezza siano appropriate, quale analisi del rischio le supporti e come venga verificata la loro effettiva efficacia. Tra le aree di controllo rilevanti possono rientrare la gestione degli incidenti, la continuit\u00e0 operativa, il crisis management, la sicurezza della supply chain, la gestione delle vulnerabilit\u00e0, il controllo degli accessi, la crittografia, le comunicazioni sicure, l\u2019igiene informatica, la formazione, l\u2019autenticazione multifattore e la valutazione del rischio dei fornitori. La coerenza tra tali misure \u00e8 pi\u00f9 importante della mera esistenza di documenti separati. Un forte sistema di gestione delle identit\u00e0, ad esempio, offre una protezione limitata se gli account di recovery non sono adeguatamente protetti. Una politica fornitori dettagliata \u00e8 poco efficace se i contratti non attribuiscono reali diritti di audit, informazione, notifica degli incidenti o risoluzione. Un incident response plan \u00e8 insufficiente se il personale non sa quando un evento debba essere giuridicamente considerato soggetto a notifica. Le misure tecniche devono pertanto essere costantemente collegate a scenari operativi concreti, obblighi giuridici e responsabilit\u00e0 di governance. In questo modo il sistema di controllo diventa effettivamente verificabile e si evita che la compliance si riduca a un esercizio documentale scollegato dalla realt\u00e0 operativa.<\/p>

La dimensione di governance collegata a NIS2 richiede particolare attenzione poich\u00e9 i rischi digitali diventano direttamente parte della supervisione e della responsabilit\u00e0 degli organi di gestione. I membri del management devono disporre di una comprensione sufficiente dei principali cyber risk, dell\u2019efficacia delle misure adottate e delle conseguenze delle carenze strutturali. Ci\u00f2 richiede pi\u00f9 di dashboard periodiche contenenti il numero di vulnerabilit\u00e0, segnalazioni di phishing o security alert. L\u2019organo di gestione deve ricevere informazioni che consentano di comprendere l\u2019esposizione materiale dei servizi critici, la rapidit\u00e0 con cui vengono corrette le vulnerabilit\u00e0 gravi, il livello di dipendenza da determinati fornitori, la reale capacit\u00e0 di recupero dei processi essenziali, l\u2019efficacia dei controlli di accesso, lo stato delle principali finding di audit e il grado di preparazione rispetto a scenari nei quali pi\u00f9 livelli di difesa falliscano contemporaneamente. Anche la formazione del management deve riflettere le responsabilit\u00e0 connesse al ruolo. I dirigenti non devono diventare specialisti operativi di cybersicurezza, ma devono essere in grado di riconoscere quali rischi abbiano rilievo strategico o materiale, quali incertezze rimangano, quali decisioni richiedano escalation e quando ulteriori investimenti diventino necessari. Qualora sorgano successivamente questioni da parte di un\u2019autorit\u00e0 di vigilanza, la valutazione non si limiter\u00e0 all\u2019esistenza formale di policy. Potr\u00e0 riguardare anche la qualit\u00e0 delle risk assessment, la rapidit\u00e0 e l\u2019adeguatezza della remediation, la proporzionalit\u00e0 delle decisioni e il grado in cui le carenze note sono state effettivamente affrontate. Una posizione solida richiede quindi una traccia decisionale verificabile nella quale l\u2019accettazione del rischio, le decisioni di investimento, le eccezioni, le priorit\u00e0 di remediation e le escalation risultino motivate e documentate in modo dimostrabile.<\/p>

DORA, gestione del rischio ICT nel settore finanziario e supervisione regolamentare<\/h4>

DORA introduce per le entit\u00e0 finanziarie un quadro europeo complessivo nel quale il rischio ICT non pu\u00f2 pi\u00f9 essere gestito come una specializzazione tecnologica separata, ma deve essere considerato una componente centrale della governance e del controllo dei servizi finanziari. Per la vostra organizzazione ci\u00f2 significa che la gestione del rischio ICT deve essere direttamente collegata alla strategia aziendale, alla gestione del rischio operativo, alla pianificazione della continuit\u00e0, alla gestione dei fornitori, all\u2019incident management e alla supervisione regolamentare. Il parametro centrale consiste nella capacit\u00e0 dell\u2019organizzazione di identificare, proteggere, rilevare, gestire, ripristinare e valutare sistematicamente i rischi ICT. Ci\u00f2 richiede un quadro coerente di gestione del rischio ICT nel quale le responsabilit\u00e0 siano chiaramente assegnate, gli information asset e gli ICT asset siano identificabili, le dipendenze critiche siano note e le adeguate misure di sicurezza e ripristino siano mantenute nel tempo. Deve essere possibile stabilire quali funzioni dipendano da quali applicazioni, infrastrutture, fonti di dati e fornitori esterni. Un prodotto finanziario, un servizio di pagamento, un processo assicurativo, una funzione di trading o un portale cliente possono dipendere da decine di componenti tecnici distribuiti tra pi\u00f9 ambienti interni ed esterni. Quando tali dipendenze sono conosciute soltanto da singoli team IT, si genera un rischio rilevante di governance. DORA richiede pertanto una modalit\u00e0 di gestione in cui le informazioni tecniche vengano tradotte in significato operativo e direzionale. Il management deve essere in grado di comprendere quali guasti ICT possano produrre effetti materiali, quale sequenza di ripristino sia necessaria e quali rischi emergano quando un fornitore esterno diventi indisponibile.<\/p>

Un elemento caratterizzante di DORA \u00e8 che l\u2019efficacia della gestione del rischio ICT non viene valutata soltanto sulla base della sicurezza preventiva, ma lungo l\u2019intero ciclo di vita della perturbazione digitale. Rilevazione, risposta, ripristino, apprendimento e miglioramento strutturale diventano quindi importanti quanto la protezione. La vostra organizzazione deve essere in grado di identificare e classificare tempestivamente gli incidenti ICT gravi e di segnalarli conformemente ai requisiti applicabili. Deve inoltre poter dimostrare come i segnali tecnici vengano tradotti in decisioni relative agli obblighi legali di segnalazione, all\u2019impatto sui clienti, alle conseguenze finanziarie, alla perdita di dati, all\u2019esposizione reputazionale e a eventuali effetti sistemici. Ci\u00f2 richiede un processo integrato di escalation nel quale cybersicurezza, ICT operations, risk management, compliance, funzione legale, privacy, comunicazione e senior management conoscano preventivamente il ruolo da svolgere. La stessa integrazione \u00e8 necessaria per i test di resilienza operativa digitale. Tali test non possono limitarsi a vulnerability scan o penetration test periodici. La vostra organizzazione deve valutare se i processi critici siano in grado di continuare a funzionare in scenari realistici di perturbazione, se le procedure di ripristino siano effettivamente eseguibili, se le decisioni di crisi possano essere adottate con sufficiente rapidit\u00e0 e se le soluzioni alternative siano realmente disponibili. Le finding derivanti dai test devono poi essere tradotte in misure concrete di remediation, priorit\u00e0, responsabili e scadenze. Un programma di testing privo di una remediation effettivamente governata offre soltanto un\u2019assurance limitata.<\/p>

DORA incide profondamente anche sul modo in cui la vostra organizzazione seleziona, contrattualizza, registra, valuta e sostituisce i fornitori esterni di servizi ICT. Cloud provider, managed service provider, software vendor, piattaforme dati, provider di sicurezza e altri soggetti esterni possono essere profondamente integrati nella fornitura di servizi finanziari critici. Un incidente operativo presso un fornitore pu\u00f2 pertanto avere conseguenze dirette sui vostri obblighi normativi, anche quando la causa tecnica si trova al di fuori del vostro ambiente. DORA chiarisce che l\u2019esternalizzazione della tecnologia non equivale all\u2019esternalizzazione della responsabilit\u00e0. La vostra organizzazione deve quindi valutare preventivamente quali funzioni siano supportate da un soggetto esterno, quali rischi di concentrazione si creino, quali dati vengano trattati, quali subfornitori siano coinvolti, quali localizzazioni siano rilevanti, quali rischi di termination esistano e se le exit strategy siano realmente praticabili. Le clausole contrattuali devono garantire adeguati diritti di informazione, audit, cooperazione, notifica degli incidenti, continuit\u00e0 e risoluzione. Il registro degli accordi contrattuali non deve essere trattato come un inventario amministrativo, ma come uno strumento strategico per individuare concentrazioni, dipendenze comuni ed esposizioni materiali. In sede di supervisory review, la vostra organizzazione deve essere in grado di dimostrare rapidamente quale fornitore supporti quale funzione critica, quali salvaguardie contrattuali siano applicabili, quale valutazione del rischio sia stata effettuata e quali misure siano disponibili in caso di mancata prestazione o inadempimento strutturale del fornitore.<\/p>

Servizi aziendali critici, Business Impact Analysis e mappatura delle dipendenze operative<\/h4>

La resilienza operativa digitale pu\u00f2 essere organizzata in modo efficace solo quando la vostra organizzazione definisce anzitutto quali servizi aziendali siano realmente critici per clienti, mercati, partner della catena del valore, interessi pubblici o continuit\u00e0 dell\u2019impresa stessa. Un approccio IT tradizionale parte spesso da sistemi, applicazioni o infrastrutture. Un approccio di operational resilience parte invece dal servizio che deve continuare a funzionare e procede a ritroso per identificare tutte le persone, i processi, le tecnologie, i dati, le localizzazioni e i fornitori esterni necessari a sostenerlo. Questa distinzione \u00e8 essenziale. Un\u2019applicazione pu\u00f2 essere tecnicamente importante senza essere direttamente critica per un servizio essenziale. Al contrario, un\u2019applicazione relativamente semplice pu\u00f2 costituire un punto di failure inatteso perch\u00e9 pi\u00f9 processi rilevanti dipendono da essa. La vostra organizzazione deve quindi identificare i servizi critici in funzione delle conseguenze della perturbazione, della rapidit\u00e0 con cui pu\u00f2 emergere un danno, della dipendenza di clienti o partner, degli obblighi normativi e della disponibilit\u00e0 di alternative. \u00c8 altrettanto importante evitare di qualificare come critico ogni processo aziendale. Se quasi tutto viene considerato critico, viene meno una reale capacit\u00e0 di prioritizzazione e diventa difficile assumere decisioni efficaci di ripristino durante una crisi. La criticit\u00e0 richiede quindi una differenziazione rigorosa.<\/p>

La Business Impact Analysis costituisce il collegamento tra servizi critici e requisiti concreti di recovery. La vostra organizzazione deve essere in grado di determinare quali conseguenze operative, finanziarie, giuridiche, sociali e reputazionali si producano quando un servizio risulti indisponibile per un determinato periodo. Il fattore tempo \u00e8 decisivo. Un\u2019interruzione di quindici minuti pu\u00f2 avere un impatto limitato, mentre la stessa perturbazione dopo quattro ore, dodici ore o due giorni pu\u00f2 diventare estremamente grave. Gli obiettivi di ripristino non devono quindi essere stabiliti esclusivamente sulla base di standard tecnici, ma devono derivare dalla tolleranza effettiva del servizio aziendale. Per ogni servizio critico deve essere chiaro quale livello minimo di funzionalit\u00e0 debba essere mantenuto, entro quale periodo debba avvenire il ripristino, quale perdita di dati sia accettabile, quali alternative manuali siano disponibili e quali dipendenze possano ritardare il recovery. L\u2019analisi deve inoltre considerare gli effetti a catena. Il guasto di un singolo servizio di autenticazione pu\u00f2 bloccare pi\u00f9 applicazioni. L\u2019indisponibilit\u00e0 di un data provider pu\u00f2 compromettere il processo decisionale anche quando l\u2019applicazione principale rimane operativa. Una perturbazione delle telecomunicazioni pu\u00f2 contemporaneamente incidere sulle comunicazioni interne, sui rapporti con i clienti e sull\u2019accesso agli ambienti cloud. Rendere visibili tali interdipendenze consente di ottenere una comprensione significativamente pi\u00f9 realistica della vulnerabilit\u00e0 effettiva.<\/p>

La mappatura delle dipendenze operative approfondisce ulteriormente questa analisi identificando l\u2019intera catena che sostiene un servizio critico. La vostra organizzazione non deve limitarsi a registrare i sistemi principali, ma deve includere anche tecnologie di supporto, identity services, fonti di dati, API, connessioni di rete, componenti cloud, siti fisici, personale chiave, fornitori esterni, subfornitori e strutture di recovery. Le dipendenze indirette richiedono particolare attenzione. Un fornitore che non \u00e8 formalmente classificato come critico pu\u00f2 fornire un componente software essenziale utilizzato da pi\u00f9 sistemi critici. Un fornitore esterno pu\u00f2 dipendere da un subfornitore che utilizza lo stesso cloud provider della vostra organizzazione, con la conseguenza che un\u2019apparente diversificazione pu\u00f2 in realt\u00e0 nascondere un unico punto concentrato di fallimento. Anche la concentrazione geografica pu\u00f2 essere rilevante quando pi\u00f9 data center, team o fornitori operano nella medesima area di rischio. Lo scopo della dependency mapping non \u00e8 quindi produrre un diagramma statico, ma creare informazioni di governance utili a stabilire dove esistano rischi di concentrazione, quali dipendenze siano insufficientemente controllate e quale sequenza di ripristino sia necessaria in caso di grave perturbazione. Queste informazioni costituiscono inoltre una base essenziale per la gestione dei fornitori, i programmi di testing, la scenario analysis, il crisis management e il confronto con le autorit\u00e0 di vigilanza.<\/p>

Classificazione dei cyber incident, obblighi di notifica e reporting regolamentare<\/h4>

Un cyber incident assume rilevanza giuridica e strategica non appena emerge che l\u2019evento pu\u00f2 produrre conseguenze materiali sulla disponibilit\u00e0, integrit\u00e0, riservatezza, autenticit\u00e0 o continuit\u00e0 dei servizi. La difficolt\u00e0 operativa consiste nel fatto che tale valutazione deve spesso essere effettuata quando i fatti tecnici sono ancora incompleti. Nelle prime ore di un incidente possono sussistere incertezze circa la causa, l\u2019ampiezza, la durata, i sistemi coinvolti, i dati compromessi e le conseguenze potenziali. Nel frattempo, i termini normativi di notifica possono gi\u00e0 essere iniziati e un ritardo pu\u00f2 generare esposizione regolamentare. La vostra organizzazione necessita pertanto di un processo di classificazione che colleghi direttamente la rilevazione tecnica degli incidenti ai criteri giuridici di valutazione. Devono essere determinati in anticipo gli indicatori che attivano l\u2019escalation, le informazioni minime che devono essere disponibili, chi sia autorizzato a classificare l\u2019evento e chi sia responsabile della notifica esterna. I criteri devono essere sufficientemente concreti da restare utilizzabili sotto pressione. Una generica istruzione secondo cui un \u201cincidente grave\u201d debba essere segnalato non offre indicazioni operative adeguate in una situazione acuta. Tra i fattori rilevanti possono rientrare durata, estensione geografica, numero di utenti interessati, impatto economico, perdita di dati, conseguenze sulle funzioni critiche, possibili effetti transfrontalieri e possibilit\u00e0 di ripristinare il servizio entro i tempi previsti.<\/p>

Il processo di notifica deve inoltre tenere conto del fatto che un singolo incidente pu\u00f2 attivare contemporaneamente pi\u00f9 regimi giuridici. Un cyberattack pu\u00f2 essere rilevante, ad esempio, ai sensi di NIS2, DORA, del GDPR, di requisiti di vigilanza settoriali, di obblighi contrattuali di notifica e delle condizioni assicurative. Questi regimi non utilizzano necessariamente le stesse definizioni, gli stessi termini o i medesimi criteri di valutazione. Esiste quindi il rischio che team differenti giungano parallelamente a conclusioni divergenti o che le notifiche dovute vengano predisposte in modo incoerente. La vostra organizzazione trae vantaggio da un processo centrale di incident governance nel quale ogni evento venga valutato rispetto a tutti i quadri giuridici potenzialmente applicabili, alle relative scadenze, alle informazioni gi\u00e0 disponibili e agli ulteriori approfondimenti necessari. Il processo deve impedire che l\u2019urgenza comprometta l\u2019accuratezza, ma anche che un eccesso di perfezionismo determini ritardi. Una prima notifica non deve necessariamente stabilire in modo definitivo ogni dettaglio tecnico. Deve tuttavia indicare in modo affidabile ci\u00f2 che \u00e8 noto, quali incertezze permangano, quali misure siano gi\u00e0 state adottate e come venga organizzato l\u2019ulteriore accertamento. Una rigorosa version control delle informazioni relative all\u2019incidente \u00e8 quindi essenziale.<\/p>

La qualit\u00e0 del regulatory reporting dipende in misura significativa dalla qualit\u00e0 della documentazione sottostante relativa all\u2019incidente. La vostra organizzazione deve poter ricostruire quando l\u2019incidente sia stato rilevato, quali segnali fossero disponibili, quali decisioni siano state adottate, quali persone fossero coinvolte, quando sia avvenuta l\u2019escalation, quali ipotesi siano state utilizzate e in quale momento fossero disponibili informazioni sufficienti per assumere una decisione di notifica. Questa timeline pu\u00f2 diventare decisiva qualora un\u2019autorit\u00e0 di vigilanza valuti successivamente se la segnalazione sia stata tempestiva e sufficientemente completa. Processo decisionale, classificazione e comunicazioni devono pertanto essere documentati fin dall\u2019inizio. \u00c8 altres\u00ec necessaria disciplina nelle comunicazioni interne. Ipotesi tecniche non confermate, qualificazioni informali o spiegazioni contrastanti possono successivamente creare difficolt\u00e0 interpretative. Un processo robusto distingue quindi tra constatazioni fattuali, ipotesi provvisorie, risk assessment e decisioni formali. Le comunicazioni con clienti, partner della catena del valore e media devono essere allineate alla medesima base fattuale controllata. Dichiarazioni esterne contraddittorie possono aggravare il danno reputazionale e suscitare ulteriori interrogativi da parte delle autorit\u00e0. La posizione pi\u00f9 solida si realizza quando technical incident response, analisi giuridica e comunicazione esecutiva operano sulla base di un unico factual record controllato, pur riconoscendo le legittime differenze che possono esistere tra segnalazioni regolamentari e comunicazione pubblica.<\/p>

Business continuity, disaster recovery e crisis management<\/h4>

La business continuity costituisce il cuore operativo della resilienza digitale perch\u00e9 nessuna misura preventiva di sicurezza pu\u00f2 garantire una protezione assoluta contro le perturbazioni. La vostra organizzazione deve quindi essere preparata a scenari nei quali i sistemi diventino effettivamente indisponibili, i dati non siano temporaneamente accessibili, un fornitore interrompa la prestazione, le comunicazioni digitali risultino gravemente limitate o il recovery richieda molto pi\u00f9 tempo del previsto. Il business continuity management deve partire dalla domanda relativa a quali servizi debbano continuare a essere erogati a un livello minimo durante la perturbazione, e non dalla domanda relativa a quale componente tecnico possa essere ripristinato per primo. La priorit\u00e0 deve essere determinata dalla funzione sociale, contrattuale ed economica del servizio interessato. Per ogni servizio aziendale critico deve pertanto essere definita la capacit\u00e0 operativa minima necessaria, quali persone e risorse debbano rimanere disponibili, quali decisioni debbano poter essere assunte in condizioni di crisi e quali alternative temporanee siano concretamente utilizzabili. Un processo manuale pu\u00f2, ad esempio, risultare sufficiente per mantenere temporaneamente un servizio essenziale, ma soltanto se i dati necessari restano accessibili, se il personale \u00e8 effettivamente in grado di utilizzare tale processo e se la capacit\u00e0 disponibile \u00e8 stata testata realisticamente. I continuity plan devono quindi basarsi su scenari realmente eseguibili e non su procedure teoriche.<\/p>

Il disaster recovery si concentra pi\u00f9 specificamente sul ripristino tecnico di sistemi, infrastrutture, dati e connettivit\u00e0, ma deve essere strettamente allineato con la business continuity. Gli obiettivi tecnici di recovery devono derivare dall\u2019impatto aziendale e non esclusivamente da standard IT storici. Se un servizio critico deve essere ripristinato entro due ore ma la procedura completa di recovery dell\u2019infrastruttura di supporto richiede otto ore, esiste una disconnessione sostanziale. La vostra organizzazione deve identificare e risolvere preventivamente tali divergenze tramite ridondanza tecnica, strutture alternative, ambienti di recovery separati, capacit\u00e0 aggiuntiva di backup o adattamento dei processi aziendali. I backup richiedono particolare attenzione. La mera esistenza di una copia di sicurezza non dimostra che i dati possano essere ripristinati tempestivamente, integralmente e in modo affidabile. I backup devono essere protetti contro gli stessi vettori di attacco che possono colpire i sistemi primari, testati regolarmente e organizzati con un sufficiente grado di indipendenza rispetto all\u2019ambiente produttivo. Configurazioni, certificati, credenziali di autenticazione, informazioni relative al key management, versioni software e documentazione tecnica possono anch\u2019essi essere essenziali per il ripristino. Un\u2019organizzazione che conserva i file di dati ma non dispone delle configurazioni e dei componenti di accesso necessari pu\u00f2 comunque affrontare una prolungata indisponibilit\u00e0 operativa.<\/p>

Il crisis management collega infine la risposta tecnica e operativa al processo decisionale esecutivo. Le gravi perturbazioni digitali evolvono spesso rapidamente e generano contemporaneamente pressioni giuridiche, commerciali, finanziarie e reputazionali. Il senior management pu\u00f2 dover assumere decisioni in condizioni di forte incertezza rispetto alle priorit\u00e0 di ripristino, alla comunicazione, al ricorso a supporto esterno, alle misure verso i clienti, all\u2019escalation nei confronti dei fornitori, al rapporto con le autorit\u00e0, al posizionamento giuridico e a eventuali restrizioni temporanee nella prestazione dei servizi. Deve quindi essere chiaro in anticipo chi partecipi alla struttura di crisi, quali poteri si applichino, come siano organizzate le sostituzioni, quali informazioni debbano essere disponibili in ogni fase e quali decisioni richiedano un\u2019approvazione formale. Il crisis management non deve dipendere da relazioni informali o dalla disponibilit\u00e0 di singoli individui. Anche la relazione tra team operativi e management deve essere chiaramente definita. Gli specialisti tecnici devono disporre di autonomia sufficiente per agire rapidamente, mentre le decisioni con conseguenze giuridiche, finanziarie o sociali rilevanti devono essere tempestivamente portate al livello competente.<\/p>

All\u2019interno di questo quadro pi\u00f9 ampio, la Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> deve rimanere strettamente collegata alla resilienza operativa digitale ogniqualvolta una perturbazione tecnologica possa compromettere i controlli destinati a prevenire, rilevare o gestire la criminalit\u00e0 finanziaria. La temporanea indisponibilit\u00e0 dei sistemi di transaction monitoring, sanctions screening, customer due diligence, fraud detection, payment control o identity verification pu\u00f2 creare ulteriori rischi di criminalit\u00e0 finanziaria esattamente nel momento in cui l\u2019attenzione operativa \u00e8 assorbita da altre criticit\u00e0. La pianificazione della continuit\u00e0 deve pertanto identificare quali controlli di criminalit\u00e0 finanziaria debbano rimanere operativi a un livello minimo, quali controlli compensativi possano essere attivati quando i sistemi ordinari non siano disponibili e come debbano essere monitorate le transazioni, le controparti o i flussi di pagamento a maggiore rischio durante la perturbazione. La Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> consente cos\u00ec di collegare continuit\u00e0 digitale, integrit\u00e0 finanziaria, controllo delle transazioni, compliance alle sanzioni, prevenzione delle frodi e governance degli incidenti all\u2019interno di un unico sistema di controllo. La resilienza digitale cessa quindi di essere una disciplina puramente tecnica di continuit\u00e0 e diventa una pi\u00f9 ampia capacit\u00e0 istituzionale, finalizzata a proteggere simultaneamente continuit\u00e0 operativa, conformit\u00e0 regolamentare, integrit\u00e0 finanziaria e capacit\u00e0 della vostra organizzazione di assumere decisioni difendibili sotto pressione.<\/p>

Test di resilienza operativa digitale, esercitazioni basate su scenari e test guidati dalle minacce<\/h4>

La resilienza operativa digitale non pu\u00f2 essere dimostrata esclusivamente verificando se policy, procedure, piani di ripristino e misure tecniche di sicurezza esistano formalmente. Per la vostra organizzazione, una reale assurance emerge soltanto quando, in condizioni realistiche, \u00e8 possibile dimostrare che i servizi aziendali critici sono in grado di resistere a gravi perturbazioni digitali e che i meccanismi di recovery funzionano effettivamente quando le misure preventive risultano insufficienti. I test di resilienza operativa digitale devono quindi andare ben oltre i penetration test convenzionali, i vulnerability scan e le verifiche periodiche di singoli sistemi. La questione centrale consiste nel determinare se la vostra organizzazione sia in grado di continuare a funzionare come un insieme coerente sotto pressione, quando pi\u00f9 dipendenze tecniche, organizzative ed esterne vengono compromesse simultaneamente. Un programma di testing efficace collega pertanto le vulnerabilit\u00e0 tecniche all\u2019impatto concreto sull\u2019attivit\u00e0. Possono essere sviluppati scenari nei quali, ad esempio, una piattaforma cloud diventi improvvisamente indisponibile, i servizi di autenticazione cessino di funzionare, un attacco ransomware interessi pi\u00f9 unit\u00e0 organizzative, dati essenziali diventino temporaneamente inaffidabili, un fornitore esterno di servizi ICT disponga di una capacit\u00e0 di ripristino insufficiente oppure emerga che diversi fornitori dipendono dalla medesima infrastruttura sottostante. Non deve essere la complessit\u00e0 tecnica dello scenario a guidare l\u2019esercizio, ma il potenziale impatto sulla continuit\u00e0 dei servizi critici. La vostra organizzazione deve quindi definire preventivamente quali servizi aziendali, processi, sistemi, dati, sedi, collaboratori e fornitori rientrino nel perimetro del test, quali tolleranze alla perturbazione si applichino e quali indicatori di performance debbano essere misurati durante e dopo l\u2019esercitazione. In questo modo il programma di testing consente di valutare non soltanto se i controlli tecnici siano in grado di resistere, ma anche se processo decisionale, escalation, comunicazioni, procedure di continuit\u00e0 e capacit\u00e0 di recovery corrispondano realmente alle esigenze operative.<\/p>

Le esercitazioni basate su scenari sono inoltre essenziali per verificare la dimensione di governance della resilienza digitale. Durante una crisi reale, gli organi di gestione, la funzione legale, la compliance, i security team e i responsabili operativi dispongono raramente, sin dalle prime ore, di informazioni complete. I primi segnali possono essere ambigui o contraddittori, mentre occorre comunque assumere decisioni relative alla continuit\u00e0 dei servizi, alle priorit\u00e0 di ripristino, agli obblighi regolamentari di notifica, alle comunicazioni verso i clienti, al coinvolgimento di consulenti esterni e all\u2019escalation verso le autorit\u00e0 di vigilanza. Un\u2019esercitazione ben progettata deve riprodurre deliberatamente questa incertezza. La vostra organizzazione pu\u00f2, ad esempio, trovarsi inizialmente di fronte a quella che appare come una limitata indisponibilit\u00e0 di servizio, per poi scoprire che l\u2019evento \u00e8 collegato a un accesso non autorizzato, a una possibile manipolazione dei dati e alla compromissione di un fornitore. In una fase successiva pu\u00f2 emergere che lo stesso fornitore supporta anche un altro servizio aziendale critico, amplificando ulteriormente l\u2019impatto operativo. Introducendo questi sviluppi in modo progressivo, l\u2019esercitazione consente di verificare se le informazioni siano condivise tempestivamente, se le responsabilit\u00e0 siano comprese, se le decisioni vengano assunte al livello appropriato e se gli obblighi giuridici siano correttamente individuati. Consente inoltre di stabilire se i team conoscano realmente i canali alternativi di comunicazione, le soluzioni di recovery e le possibilit\u00e0 di escalation disponibili. Il valore di tali esercitazioni non risiede quindi nella conferma della conoscenza delle procedure esistenti, ma nell\u2019individuazione delle incoerenze tra piani formali e comportamento effettivo. La vostra organizzazione ottiene cos\u00ec informazioni concrete sulla velocit\u00e0 decisionale, sulla qualit\u00e0 dei dati, sulla capacit\u00e0 di coordinamento, sulla recuperabilit\u00e0 dei processi e sulle dipendenze organizzative che una revisione documentale convenzionale potrebbe non evidenziare.<\/p>

Per le entit\u00e0 finanziarie, DORA pu\u00f2 inoltre richiedere, a seconda della natura, delle dimensioni e del profilo di rischio dell\u2019organizzazione, test di penetrazione avanzati basati sulle minacce. Questi test analizzano l\u2019organizzazione dal punto di vista di avversari realistici e verificano se funzioni critiche possano essere compromesse mediante tecniche, tattiche e procedure coerenti con l\u2019intelligence disponibile sulle minacce. Tale approccio richiede una precisa definizione degli obiettivi di test, dei sistemi inclusi nel perimetro, dei fornitori esterni coinvolti, dei limiti di sicurezza, degli aspetti di protezione dei dati e delle modalit\u00e0 di gestione delle vulnerabilit\u00e0 individuate. Un threat-led penetration test non rappresenta una competizione tra team offensivi e difensivi, ma un metodo controllato per valutare il funzionamento delle misure esistenti quando viene simulata una catena d\u2019attacco coordinata. Le finding non devono pertanto essere classificate esclusivamente in termini tecnici. La vostra organizzazione deve determinare quali vulnerabilit\u00e0 possano compromettere servizi critici, quali cause strutturali siano alla base delle debolezze individuate e quali misure di remediation meritino priorit\u00e0. Questo approccio si collega direttamente alla Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong>, poich\u00e9 gli stessi percorsi digitali di accesso che minacciano la continuit\u00e0 operativa possono essere sfruttati per frodi nei pagamenti, appropriazione o abuso di identit\u00e0, manipolazione dei dati, elusione delle sanzioni o altre forme di criminalit\u00e0 finanziaria. Collegare i risultati tecnici dei test ai rischi operativi, giuridici e di integrit\u00e0 permette di ottenere una visione molto pi\u00f9 completa dell\u2019esposizione effettiva della vostra organizzazione. L\u2019esito di ogni programma di testing deve pertanto essere tradotto in azioni di remediation dimostrabili, responsabili chiaramente individuati, scadenze concrete, retesting periodici e reporting al management, affinch\u00e9 il testing contribuisca direttamente al rafforzamento strutturale della resilienza digitale.<\/p>

Rischio ICT derivante da terze parti, registri di outsourcing e dipendenze da fornitori critici<\/h4>

La continuit\u00e0 digitale della vostra organizzazione dipende sempre pi\u00f9 da soggetti che operano al di fuori dei suoi confini giuridici e operativi. Cloud provider, software vendor, managed service provider, data center, payment processor, operatori di telecomunicazioni, fornitori di servizi di cybersicurezza, identity provider e fornitori specializzati di dati possono ciascuno costituire una componente essenziale dei servizi aziendali critici. Ci\u00f2 crea una questione fondamentale di governance: la vostra organizzazione pu\u00f2 esternalizzare l\u2019esecuzione tecnica, ma rimane responsabile della gestione dei rischi derivanti da tale dipendenza. Una gestione efficace del rischio ICT derivante da terze parti deve quindi iniziare molto prima della firma del contratto. Occorre poter stabilire quale servizio venga esternalizzato, quale funzione aziendale ne diventi dipendente, quali dati vengano trattati, quali sedi e subfornitori siano coinvolti, quali rischi di continuit\u00e0 esistano e quali conseguenze deriverebbero da una improvvisa indisponibilit\u00e0 del fornitore. Devono inoltre essere considerate la solidit\u00e0 finanziaria, operativa e giuridica della controparte. Un fornitore tecnicamente sofisticato pu\u00f2 comunque generare un rischio significativo di continuit\u00e0 qualora il servizio sia altamente concentrato, le conoscenze critiche siano detenute da poche persone o componenti essenziali dipendano da ulteriori soggetti esterni. La due diligence sui fornitori deve quindi comprendere le dipendenze sia dirette sia indirette ed essere proporzionata alla criticit\u00e0 del servizio aziendale supportato.<\/p>

Il controllo contrattuale assume in questo ambito particolare importanza. Un contratto di servizi articolato offre protezione limitata se, durante un incidente, la vostra organizzazione non pu\u00f2 ottenere tempestivamente le informazioni necessarie, non dispone di diritti di audit effettivi o non possiede poteri contrattuali sufficienti per imporre misure di remediation. Le clausole contrattuali devono quindi riflettere direttamente i rischi operativi e regolamentari. Tra gli elementi rilevanti rientrano gli obblighi informativi, i requisiti di cybersicurezza, la notifica degli incidenti, i diritti di audit e accesso, la localizzazione dei dati, il ricorso a subfornitori, le misure di continuit\u00e0, gli obiettivi di recovery, gli obblighi di testing, la protezione dei dati, i diritti di risoluzione e il supporto all\u2019uscita. Per funzioni critiche o importanti, tali disposizioni devono essere sufficientemente specifiche da risultare concretamente utilizzabili durante una crisi. La vostra organizzazione deve, ad esempio, poter stabilire entro quale termine un fornitore sia obbligato a segnalare un incidente grave, quali informazioni minime debbano essere messe a disposizione, in che modo possa essere condotta un\u2019indagine e quale supporto debba essere fornito per il ripristino. Anche i cambiamenti intervenuti durante il rapporto contrattuale devono essere governati. Nel corso del contratto, un fornitore pu\u00f2 introdurre nuovi subfornitori, migrare infrastrutture o sostituire componenti tecnici. Se tali modifiche non vengono individuate tempestivamente, il profilo di rischio del servizio pu\u00f2 cambiare sostanzialmente senza che la vostra organizzazione abbia aggiornato la propria valutazione. Il contract management deve pertanto essere direttamente collegato al risk management e non essere trattato esclusivamente come una funzione commerciale di gestione dei fornitori.<\/p>

I registri degli accordi contrattuali ICT assumono particolare rilievo ai sensi di DORA, poich\u00e9 devono offrire visibilit\u00e0 sull\u2019ampiezza e sulla natura delle dipendenze verso i fornitori esterni di servizi ICT. Un registro di questo tipo ha tuttavia valore di governance soltanto se le informazioni sono corrette, complete, aggiornate e collegabili a funzioni critiche, entit\u00e0 giuridiche, localizzazioni, categorie di dati e subfornitori. La vostra organizzazione deve poter utilizzare tale quadro per individuare se pi\u00f9 servizi aziendali critici dipendano dallo stesso fornitore, dallo stesso ambiente cloud, dal medesimo componente software o dalla stessa infrastruttura geografica. Tali rischi di concentrazione possono moltiplicare l\u2019impatto di un incidente. Anche una diversificazione apparente pu\u00f2 essere fuorviante quando diverse controparti contrattuali si appoggiano, in ultima analisi, allo stesso hyperscaler, allo stesso data center operator o allo stesso technology provider. Il rischio di concentrazione deve quindi essere analizzato al di l\u00e0 dei singoli confini contrattuali. La stessa metodologia pu\u00f2 essere utilizzata nell\u2019ambito della Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> per valutare se terze parti abbiano accesso a dati finanziari sensibili, flussi di transazioni, identit\u00e0 dei clienti o meccanismi di controllo rilevanti per la prevenzione e l\u2019individuazione della criminalit\u00e0 finanziaria. Il rischio fornitori diventa cos\u00ec una componente integrata della resilienza digitale, della continuit\u00e0 operativa e della gestione dei rischi di integrit\u00e0. Un solido framework di third-party risk management consente alla vostra organizzazione di sapere prima di un incidente quali fornitori siano materiali, di esercitare in modo mirato i propri diritti contrattuali durante l\u2019evento e di dimostrare successivamente quali misure di controllo fossero state predisposte.<\/p>

Responsabilit\u00e0 degli organi di gestione, propensione al rischio ICT e supervisione del senior management<\/h4>

La resilienza operativa digitale richiede una responsabilit\u00e0 degli organi di gestione che vada ben oltre la formale approvazione delle policy. Il consiglio di amministrazione e il senior management devono essere in grado di comprendere quali dipendenze digitali siano materiali per la continuit\u00e0 dell\u2019organizzazione, quali rischi vengano consapevolmente accettati, quali carenze richiedano un intervento immediato e quali investimenti siano necessari per proteggere in modo sostenibile i servizi aziendali critici. Ci\u00f2 richiede una chiara propensione al rischio ICT, tradotta in soglie concrete e criteri decisionali. Dichiarazioni generiche secondo cui la vostra organizzazione avrebbe una bassa tolleranza al cyber risk offrono una guida limitata. \u00c8 molto pi\u00f9 rilevante determinare quanto downtime non pianificato di un servizio critico sia accettabile, quali tempi massimi di recovery possano essere tollerati, quante vulnerabilit\u00e0 critiche non risolte possano essere accettate, quali livelli di concentrazione dei fornitori superino la soglia di tolleranza e in quali circostanze gli investimenti destinati alla riduzione dei rischi debbano obbligatoriamente essere sottoposti al management. Un framework efficace rende quindi visibile quali rischi possano essere gestiti nell\u2019ordinaria operativit\u00e0 e quali situazioni richiedano una decisione esplicita degli organi di gestione. Ci\u00f2 evita che eccezioni tecniche temporanee si trasformino progressivamente in rischi strutturali di governance senza un adeguato livello di challenge e supervisione.<\/p>

La qualit\u00e0 della supervisione manageriale dipende in larga misura dalla qualit\u00e0 delle informazioni sulle quali vengono assunte le decisioni. Molte organizzazioni dispongono di dashboard estese con numerosi indicatori tecnici, ma non tutti i technical metric presentano la stessa rilevanza ai fini della governance. Il management necessita soprattutto di informazioni che rendano evidente quali vulnerabilit\u00e0 possano compromettere l\u2019erogazione di servizi critici, quanto tempo possa richiedere il ripristino, quali dipendenze rimangano insufficientemente controllate e quali azioni di remediation risultino in ritardo. Gli indicatori possono riguardare, ad esempio, la percentuale di servizi critici per i quali le procedure di recovery siano state effettivamente testate, l\u2019anzianit\u00e0 delle finding di audit pi\u00f9 rilevanti, la disponibilit\u00e0 di fornitori alternativi, il grado di concentrazione delle funzioni critiche presso un singolo provider, il tempo medio tra rilevazione ed escalation di un incidente, l\u2019affidabilit\u00e0 del restore dei backup e il numero di eccezioni significative alle policy di sicurezza. Anche le tendenze assumono rilievo. Una deviazione isolata pu\u00f2 essere tollerabile, mentre un deterioramento persistente dello stesso indicatore pu\u00f2 rivelare una debolezza strutturale del sistema di controllo. Il management information reporting deve quindi fornire contesto e non limitarsi a esporre dati numerici. Il consiglio di amministrazione deve poter comprendere quali rischi stiano aumentando, quali cause siano alla base di tale evoluzione, quali misure siano gi\u00e0 state adottate e quali incertezze residue permangano.<\/p>

La responsabilit\u00e0 degli organi di gestione si manifesta inoltre nel modo in cui vengono bilanciati interessi concorrenti. Gli investimenti nella resilienza digitale competono spesso con priorit\u00e0 commerciali, iniziative di riduzione dei costi, programmi di innovazione e altri obiettivi strategici. La decisione di continuare a utilizzare un legacy system, rinviare una migrazione o mantenere un determinato fornitore pu\u00f2 essere economicamente comprensibile, ma pu\u00f2 al tempo stesso aumentare l\u2019esposizione operativa e giuridica. La vostra organizzazione deve quindi rendere tali trade-off espliciti e verificabili. I rischi rilevanti, le alternative disponibili, le conseguenze finanziarie e i controlli compensativi devono essere documentati prima che la decisione venga assunta. Il senior management deve inoltre ricevere un challenge sufficientemente indipendente dalle funzioni di risk management, compliance, legale, information security e internal audit. Il collegamento con la Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> assume qui particolare rilievo. Una debolezza nei controlli digitali pu\u00f2 compromettere non solo la continuit\u00e0 operativa, ma anche il transaction monitoring, il sanctions screening, la customer due diligence o la fraud detection. I rischi operativi e i rischi di criminalit\u00e0 finanziaria possono quindi rafforzarsi reciprocamente. Il reporting al management deve rendere visibile tale interazione, evitando che le decisioni sui rischi siano assunte in modo isolato da funzioni separate. Una governance efficace significa, in questo contesto, che la vostra organizzazione sia in grado di dimostrare quali rischi digitali assuma, perch\u00e9 determinati rischi vengano accettati e come venga verificato che tale accettazione rimanga entro limiti giuridici, regolamentari e sociali sostenibili.<\/p>

Indagini di vigilanza, esposizione all\u2019enforcement e difesa procedurale<\/h4>

La vigilanza sulla resilienza operativa digitale sta evolvendo da una valutazione prevalentemente policy-based verso una verifica sempre pi\u00f9 fattuale dell\u2019effettiva efficacia dei sistemi di controllo. Quando un\u2019autorit\u00e0 di vigilanza formula domande sulla conformit\u00e0 a NIS2, alla disciplina nazionale di cybersicurezza, a DORA o a obblighi settoriali connessi, l\u2019analisi difficilmente si limiter\u00e0 alla documentazione di policy. Pu\u00f2 estendersi a configurazioni tecniche, registri degli incidenti, decisioni degli organi di gestione, contratti con i fornitori, risultati dei test, finding di audit, piani di ripristino, risk acceptance e modalit\u00e0 con cui le carenze note siano state affrontate. Per la vostra organizzazione \u00e8 quindi essenziale trattare un\u2019indagine di vigilanza, sin dal primo contatto, come un processo sia giuridico sia fattuale. Quali informazioni vengono richieste, sulla base di quale fondamento giuridico, per quale periodo, in relazione a quale entit\u00e0 giuridica e con quale finalit\u00e0 di supervisione? Una disclosure eccessivamente ampia o insufficientemente controllata pu\u00f2 involontariamente aprire nuove linee di indagine o sovrapporre fatti tra loro distinti. Un atteggiamento eccessivamente difensivo pu\u00f2, al contrario, compromettere il rapporto con il supervisore e generare l\u2019impressione che informazioni rilevanti vengano trattenute. L\u2019approccio pi\u00f9 solido combina cooperazione trasparente, rigoroso controllo fattuale, precisa delimitazione giuridica e comunicazioni coerenti.<\/p>

La ricostruzione degli eventi diventa particolarmente importante quando il controllo regolamentare segue un incidente concreto. Un cyber incident grave non implica automaticamente che la vostra organizzazione abbia violato i propri obblighi legali di diligenza. I sistemi digitali possono essere colpiti, nonostante l\u2019esistenza di misure adeguate, da attacchi sofisticati, vulnerabilit\u00e0 precedentemente sconosciute, errori di fornitori o una combinazione eccezionale di circostanze. L\u2019analisi giuridica deve quindi esaminare quali misure fossero in vigore prima dell\u2019incidente, quali rischi fossero ragionevolmente conoscibili, quali segnali fossero disponibili, con quale rapidit\u00e0 l\u2019organizzazione abbia reagito e quali miglioramenti siano stati introdotti successivamente. Allo stesso tempo, l\u2019assenza di incidenti precedenti non dimostra che il sistema di controllo fosse efficace. La vostra organizzazione deve essere in grado di dimostrare come siano state assunte le decisioni e quali informazioni fossero disponibili nel momento rilevante. Timeline, incident log, verbali del consiglio di amministrazione, risk assessment, risultati dei test e decisioni di remediation possono risultare determinanti. Particolare attenzione deve essere prestata alla distinzione tra le conoscenze disponibili all\u2019epoca della decisione e quelle acquisite soltanto successivamente. In caso contrario, l\u2019analisi pu\u00f2 essere influenzata da hindsight bias, facendo apparire un rischio molto pi\u00f9 prevedibile di quanto fosse ragionevolmente prima dell\u2019evento. Una solida difesa procedurale deve quindi dimostrare quali fatti fossero conosciuti in ogni momento decisionale, quali incertezze permanessero e perch\u00e9 determinate scelte fossero difendibili nelle circostanze concrete.<\/p>

Quando un\u2019autorit\u00e0 valuta misure di enforcement, assumono rilievo centrale proporzionalit\u00e0, imputabilit\u00e0, prova, causalit\u00e0 e correttezza procedurale. La vostra organizzazione deve essere in grado di distinguere tra una specifica violazione normativa, una misura di miglioramento che sarebbe stata auspicabile ma non giuridicamente obbligatoria, un fallimento operativo isolato e una carenza strutturale rientrante nella sfera di controllo dell\u2019organizzazione. Anche il ruolo dei fornitori esterni pu\u00f2 essere rilevante. Sebbene l\u2019outsourcing non elimini la responsabilit\u00e0, la causa concreta dell\u2019incidente pu\u00f2 influire sulla valutazione del grado di colpa e sulla proporzionalit\u00e0 delle eventuali misure. Le indagini interne devono pertanto essere strutturate con attenzione, mediante quesiti investigativi chiaramente definiti, accertamento controllato dei fatti, adeguata protezione delle comunicazioni giuridicamente sensibili e una chiara separazione tra analisi tecnica, valutazione legale e responsabilit\u00e0 manageriale. La stessa logica vale quando l\u2019incidente presenta collegamenti con frodi, manipolazione dei dati, abusi nei pagamenti o altre forme di criminalit\u00e0 finanziaria. La Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> pu\u00f2, in tali situazioni, collegare cyber incident, controlli interni, rischi transazionali e possibili pattern di abuso all\u2019interno di un unico quadro probatorio. Ci\u00f2 consente alla vostra organizzazione non soltanto di rispondere alle richieste dell\u2019autorit\u00e0, ma anche di dimostrare che la remediation sia stata integrata in modo strutturale e che i rischi sottostanti siano stati effettivamente ridotti.<\/p>

Governance integrata della resilienza digitale, remediation e continuit\u00e0 istituzionale<\/h4>

La resilienza operativa digitale raggiunge la massima efficacia quando cybersicurezza, continuity management, ICT risk management, supplier management, legal compliance, privacy, controllo della criminalit\u00e0 finanziaria e crisis management non operano come discipline separate, ma vengono collegate all\u2019interno di un unico sistema coerente di governance. Ci\u00f2 non significa che tutti i regimi giuridici o tutte le funzioni specialistiche debbano essere fusi in un unico processo uniforme. NIS2, la disciplina nazionale in materia di cybersicurezza, DORA, la normativa sulla protezione dei dati, i requisiti di vigilanza settoriali e gli obblighi contrattuali mantengono ciascuno un proprio ambito di applicazione e specifici requisiti giuridici. La sfida di governance consiste nel rispettare tali differenze e, nello stesso tempo, creare una visione unica e affidabile dei servizi critici, delle dipendenze materiali, dei rischi significativi, degli incidenti, delle misure di remediation e dei responsabili individuati. La vostra organizzazione deve quindi essere in grado, mediante un framework integrato di governance, di determinare quali rischi abbiano rilevanza a livello enterprise e, successivamente, di identificare per ciascun regime giuridico quali specifici obblighi siano applicabili. Ci\u00f2 permette di evitare sia la frammentazione sia un\u2019eccessiva semplificazione giuridica.<\/p>

La governance della remediation costituisce un elemento fondamentale di tale sistema. Finding di audit, analisi post-incidente, risultati di testing, osservazioni delle autorit\u00e0 di vigilanza, supplier review e valutazioni interne dei rischi generano continuamente interventi di miglioramento. Quando tali finding vengono gestite attraverso sistemi, comitati e funzioni differenti, pu\u00f2 venire meno la visione complessiva e difetti simili possono essere registrati pi\u00f9 volte senza che venga effettivamente affrontata la causa sottostante. La vostra organizzazione necessita quindi di un processo integrato di remediation nel quale le finding vengano classificate sulla base della gravit\u00e0, del servizio aziendale critico coinvolto, della rilevanza giuridica, della root cause e delle relazioni con altri problemi. Devono poi essere definiti responsabili, scadenze, dipendenze e criteri di accettazione. Un\u2019azione di remediation non dovrebbe essere considerata completata semplicemente perch\u00e9 una modifica \u00e8 stata amministrativamente implementata, ma soltanto quando sia stato dimostrato che la misura funzioni effettivamente. Per le carenze critiche pu\u00f2 essere necessaria una validazione indipendente. Anche le misure compensative temporanee devono essere monitorate esplicitamente per evitare che soluzioni di emergenza diventino, senza una decisione consapevole, misure permanenti. Una governance centralizzata della remediation consente inoltre al management di comprendere meglio pattern strutturali, cause ricorrenti e ambiti nei quali la riduzione del rischio proceda troppo lentamente.<\/p>

La continuit\u00e0 istituzionale va infine ben oltre il ripristino di un singolo sistema o processo. La vostra organizzazione deve poter resistere a situazioni nelle quali tecnologia, fornitori, personale, sedi fisiche e capacit\u00e0 decisionale siano simultaneamente sottoposti a pressione. Ci\u00f2 richiede adeguata ridondanza in termini di conoscenze, poteri, dati, canali di comunicazione e capacit\u00e0 decisionale critica. Le funzioni chiave devono essere sostituibili, le informazioni essenziali devono restare accessibili durante gravi perturbazioni e le decisioni di crisi devono poter essere adottate anche quando i sistemi ordinari o le normali sedi di lavoro non siano disponibili. La Gestione integrata dei rischi di criminalit\u00e0 finanziaria<\/strong> deve costituire parte integrante dello stesso approccio alla continuit\u00e0. L\u2019indisponibilit\u00e0 del transaction monitoring, della customer due diligence, del sanctions screening, dei payment control o della fraud detection pu\u00f2 generare ulteriori rischi di criminalit\u00e0 finanziaria proprio nel momento in cui l\u2019attenzione operativa \u00e8 assorbita da altre criticit\u00e0. I continuity plan devono pertanto stabilire esplicitamente quali controlli di integrit\u00e0 debbano rimanere disponibili almeno a un livello minimo e quali attivit\u00e0 di monitoraggio rafforzato debbano essere attivate qualora i controlli ordinari risultino temporaneamente degradati. L\u2019obiettivo finale \u00e8 un\u2019organizzazione che non sia soltanto in grado di resistere a una perturbazione digitale, ma che possa dimostrare di mantenere, anche sotto pressione, il controllo sui servizi critici, sugli obblighi giuridici, sull\u2019integrit\u00e0 finanziaria e sul processo decisionale. La resilienza operativa digitale diventa cos\u00ec una competenza istituzionale permanente: non soltanto uno strumento per prevenire gli incidenti, ma un mezzo per proteggere continuit\u00e0, certezza del diritto, fiducia e affidabilit\u00e0 istituzionale quando l\u2019ambiente digitale viene gravemente compromesso.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

La resilienza operativa digitale non rappresenta pi\u00f9, per la vostra organizzazione, una questione meramente tecnica legata alla cybersicurezza, alla disponibilit\u00e0 delle reti, ai backup, ai controlli degli accessi o al ripristino dei sistemi ICT. La questione centrale di governance consiste ormai nello stabilire se, in condizioni di grave perturbazione digitale, la vostra organizzazione sia in grado di proteggere, mantenere e ripristinare le proprie funzioni essenziali o importanti in modo controllato, verificabile e giuridicamente difendibile, rendendo al contempo conto delle decisioni adottate prima, durante e dopo l\u2019evento. Si tratta di un cambiamento sostanziale. Un\u2019organizzazione pu\u00f2 aver implementato misure tecniche di sicurezza<\/p>\n","protected":false},"author":1,"featured_media":36168,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[244],"tags":[],"class_list":["post-36186","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ia-resilienza-digitale"],"acf":[],"_links":{"self":[{"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/posts\/36186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/comments?post=36186"}],"version-history":[{"count":7,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/posts\/36186\/revisions"}],"predecessor-version":[{"id":36193,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/posts\/36186\/revisions\/36193"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/media\/36168"}],"wp:attachment":[{"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/media?parent=36186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/categories?post=36186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vanleeuwenlawfirm.eu\/it\/wp-json\/wp\/v2\/tags?post=36186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}