La resilienza operativa digitale non rappresenta più, per la vostra organizzazione, una questione meramente tecnica legata alla cybersicurezza, alla disponibilità 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’evento. Si tratta di un cambiamento sostanziale. Un’organizzazione può aver implementato misure tecniche di sicurezza avanzate e rimanere comunque insufficientemente preparata a un’interruzione prolungata di un ambiente cloud, alla compromissione di identità 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’interruzione delle infrastrutture di pagamento o al guasto simultaneo di più sistemi interdipendenti. Le conseguenze giuridiche e operative di tali eventi dipendono sempre meno dal solo malfunzionamento tecnico iniziale o dal vettore d’attacco e sempre più dal modo in cui dipendenze, responsabilità, poteri di escalation, priorità 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’ambito di applicazione del regime NIS2, un sistema di obblighi in materia di gestione dei rischi, registrazione, notifica e governance richiede una dimostrabile capacità di controllo dei rischi di cybersicurezza. Per le entità finanziarie soggette a DORA, dal 17 gennaio 2025 si applica un regime europeo specifico relativo, tra l’altro, 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 è quindi spostato dalla mera esistenza di politiche di cybersicurezza alla capacità 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.
Per la vostra organizzazione ciò 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’indisponibilità sia accettabile, quali dati debbano rimanere disponibili e affidabili, quali fornitori siano in concreto indispensabili, quali capacità alternative siano realmente utilizzabili e quali decisioni debbano poter essere adottate entro tempi estremamente brevi durante una crisi. A ciò si aggiunge il fatto che più 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’entità finanziaria soggetta a DORA può, ad esempio, appartenere a un gruppo più ampio nel quale altre società 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à, funzione critica, servizio, sistema, fornitore e categoria di incidente, sia possibile identificare il regime giuridico applicabile, la funzione responsabile dell’azione, 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à operativa digitale non dipende da conoscenze informali detenute da un numero limitato di specialisti tecnici, ma è incorporata in responsabilità dimostrabili, capacità 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.
NIS2, normativa nazionale sulla cybersicurezza e obblighi settoriali in materia di sicurezza digitale
L’attuazione di NIS2 ha trasformato, per molte organizzazioni, la cybersicurezza da ambito prevalentemente tecnico a specifica area di governance e responsabilità giuridica. Per la vostra organizzazione, un’efficace conformità deve quindi iniziare con una precisa analisi dell’ambito di applicazione. Occorre stabilire se l’organizzazione nel suo complesso, una singola entità giuridica, una specifica attività o un determinato servizio rientri in un settore regolamentato e quale qualificazione giuridica ne derivi. Tale valutazione può risultare complessa quando gruppi societari svolgono più attività, quando i servizi vengono erogati attraverso diverse entità giuridiche, quando le funzioni digitali di supporto sono centralizzate o quando prestatori esterni rivestono un ruolo essenziale nell’erogazione di servizi regolamentati. Un’analisi troppo restrittiva può comportare la mancata individuazione di obblighi normativi o la loro identificazione tardiva. Un approccio eccessivamente ampio può 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à 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à competenti. L’ambito 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à aziendali e dipendenze digitali vengano esaminati congiuntamente.
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à, alla probabilità 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 è quindi sufficiente. La vostra organizzazione deve poter spiegare perché 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à operativa, il crisis management, la sicurezza della supply chain, la gestione delle vulnerabilità, il controllo degli accessi, la crittografia, le comunicazioni sicure, l’igiene informatica, la formazione, l’autenticazione multifattore e la valutazione del rischio dei fornitori. La coerenza tra tali misure è più importante della mera esistenza di documenti separati. Un forte sistema di gestione delle identità, ad esempio, offre una protezione limitata se gli account di recovery non sono adeguatamente protetti. Una politica fornitori dettagliata è poco efficace se i contratti non attribuiscono reali diritti di audit, informazione, notifica degli incidenti o risoluzione. Un incident response plan è 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à 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à operativa.
La dimensione di governance collegata a NIS2 richiede particolare attenzione poiché i rischi digitali diventano direttamente parte della supervisione e della responsabilità degli organi di gestione. I membri del management devono disporre di una comprensione sufficiente dei principali cyber risk, dell’efficacia delle misure adottate e delle conseguenze delle carenze strutturali. Ciò richiede più di dashboard periodiche contenenti il numero di vulnerabilità, segnalazioni di phishing o security alert. L’organo di gestione deve ricevere informazioni che consentano di comprendere l’esposizione materiale dei servizi critici, la rapidità con cui vengono corrette le vulnerabilità gravi, il livello di dipendenza da determinati fornitori, la reale capacità di recupero dei processi essenziali, l’efficacia dei controlli di accesso, lo stato delle principali finding di audit e il grado di preparazione rispetto a scenari nei quali più livelli di difesa falliscano contemporaneamente. Anche la formazione del management deve riflettere le responsabilità 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’autorità di vigilanza, la valutazione non si limiterà all’esistenza formale di policy. Potrà riguardare anche la qualità delle risk assessment, la rapidità e l’adeguatezza della remediation, la proporzionalità 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’accettazione del rischio, le decisioni di investimento, le eccezioni, le priorità di remediation e le escalation risultino motivate e documentate in modo dimostrabile.
DORA, gestione del rischio ICT nel settore finanziario e supervisione regolamentare
DORA introduce per le entità finanziarie un quadro europeo complessivo nel quale il rischio ICT non può più 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ò significa che la gestione del rischio ICT deve essere direttamente collegata alla strategia aziendale, alla gestione del rischio operativo, alla pianificazione della continuità, alla gestione dei fornitori, all’incident management e alla supervisione regolamentare. Il parametro centrale consiste nella capacità dell’organizzazione di identificare, proteggere, rilevare, gestire, ripristinare e valutare sistematicamente i rischi ICT. Ciò richiede un quadro coerente di gestione del rischio ICT nel quale le responsabilità 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ù 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à 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.
Un elemento caratterizzante di DORA è che l’efficacia della gestione del rischio ICT non viene valutata soltanto sulla base della sicurezza preventiva, ma lungo l’intero 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’impatto sui clienti, alle conseguenze finanziarie, alla perdita di dati, all’esposizione reputazionale e a eventuali effetti sistemici. Ciò 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 è 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à e se le soluzioni alternative siano realmente disponibili. Le finding derivanti dai test devono poi essere tradotte in misure concrete di remediation, priorità, responsabili e scadenze. Un programma di testing privo di una remediation effettivamente governata offre soltanto un’assurance limitata.
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ò 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’esternalizzazione della tecnologia non equivale all’esternalizzazione della responsabilità. 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à 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.
Servizi aziendali critici, Business Impact Analysis e mappatura delle dipendenze operative
La resilienza operativa digitale può 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à dell’impresa 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 è essenziale. Un’applicazione può essere tecnicamente importante senza essere direttamente critica per un servizio essenziale. Al contrario, un’applicazione relativamente semplice può costituire un punto di failure inatteso perché più processi rilevanti dipendono da essa. La vostra organizzazione deve quindi identificare i servizi critici in funzione delle conseguenze della perturbazione, della rapidità con cui può emergere un danno, della dipendenza di clienti o partner, degli obblighi normativi e della disponibilità di alternative. È altrettanto importante evitare di qualificare come critico ogni processo aziendale. Se quasi tutto viene considerato critico, viene meno una reale capacità di prioritizzazione e diventa difficile assumere decisioni efficaci di ripristino durante una crisi. La criticità richiede quindi una differenziazione rigorosa.
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 è decisivo. Un’interruzione di quindici minuti può avere un impatto limitato, mentre la stessa perturbazione dopo quattro ore, dodici ore o due giorni può 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à 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’analisi deve inoltre considerare gli effetti a catena. Il guasto di un singolo servizio di autenticazione può bloccare più applicazioni. L’indisponibilità di un data provider può compromettere il processo decisionale anche quando l’applicazione principale rimane operativa. Una perturbazione delle telecomunicazioni può contemporaneamente incidere sulle comunicazioni interne, sui rapporti con i clienti e sull’accesso agli ambienti cloud. Rendere visibili tali interdipendenze consente di ottenere una comprensione significativamente più realistica della vulnerabilità effettiva.
La mappatura delle dipendenze operative approfondisce ulteriormente questa analisi identificando l’intera 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 è formalmente classificato come critico può fornire un componente software essenziale utilizzato da più sistemi critici. Un fornitore esterno può dipendere da un subfornitore che utilizza lo stesso cloud provider della vostra organizzazione, con la conseguenza che un’apparente diversificazione può in realtà nascondere un unico punto concentrato di fallimento. Anche la concentrazione geografica può essere rilevante quando più data center, team o fornitori operano nella medesima area di rischio. Lo scopo della dependency mapping non è 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à di vigilanza.
Classificazione dei cyber incident, obblighi di notifica e reporting regolamentare
Un cyber incident assume rilevanza giuridica e strategica non appena emerge che l’evento può produrre conseguenze materiali sulla disponibilità, integrità, riservatezza, autenticità o continuità dei servizi. La difficoltà 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’ampiezza, la durata, i sistemi coinvolti, i dati compromessi e le conseguenze potenziali. Nel frattempo, i termini normativi di notifica possono già essere iniziati e un ritardo può 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’escalation, le informazioni minime che devono essere disponibili, chi sia autorizzato a classificare l’evento e chi sia responsabile della notifica esterna. I criteri devono essere sufficientemente concreti da restare utilizzabili sotto pressione. Una generica istruzione secondo cui un “incidente grave” 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à di ripristinare il servizio entro i tempi previsti.
Il processo di notifica deve inoltre tenere conto del fatto che un singolo incidente può attivare contemporaneamente più regimi giuridici. Un cyberattack può 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à disponibili e agli ulteriori approfondimenti necessari. Il processo deve impedire che l’urgenza comprometta l’accuratezza, 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ò che è noto, quali incertezze permangano, quali misure siano già state adottate e come venga organizzato l’ulteriore accertamento. Una rigorosa version control delle informazioni relative all’incidente è quindi essenziale.
La qualità del regulatory reporting dipende in misura significativa dalla qualità della documentazione sottostante relativa all’incidente. La vostra organizzazione deve poter ricostruire quando l’incidente sia stato rilevato, quali segnali fossero disponibili, quali decisioni siano state adottate, quali persone fossero coinvolte, quando sia avvenuta l’escalation, quali ipotesi siano state utilizzate e in quale momento fossero disponibili informazioni sufficienti per assumere una decisione di notifica. Questa timeline può diventare decisiva qualora un’autorità di vigilanza valuti successivamente se la segnalazione sia stata tempestiva e sufficientemente completa. Processo decisionale, classificazione e comunicazioni devono pertanto essere documentati fin dall’inizio. È altresì necessaria disciplina nelle comunicazioni interne. Ipotesi tecniche non confermate, qualificazioni informali o spiegazioni contrastanti possono successivamente creare difficoltà 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à. La posizione più 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.
Business continuity, disaster recovery e crisis management
La business continuity costituisce il cuore operativo della resilienza digitale perché nessuna misura preventiva di sicurezza può 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ù 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à deve essere determinata dalla funzione sociale, contrattuale ed economica del servizio interessato. Per ogni servizio aziendale critico deve pertanto essere definita la capacità 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ò, ad esempio, risultare sufficiente per mantenere temporaneamente un servizio essenziale, ma soltanto se i dati necessari restano accessibili, se il personale è effettivamente in grado di utilizzare tale processo e se la capacità disponibile è stata testata realisticamente. I continuity plan devono quindi basarsi su scenari realmente eseguibili e non su procedure teoriche.
Il disaster recovery si concentra più specificamente sul ripristino tecnico di sistemi, infrastrutture, dati e connettività, ma deve essere strettamente allineato con la business continuity. Gli obiettivi tecnici di recovery devono derivare dall’impatto 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’infrastruttura 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à 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’ambiente produttivo. Configurazioni, certificati, credenziali di autenticazione, informazioni relative al key management, versioni software e documentazione tecnica possono anch’essi essere essenziali per il ripristino. Un’organizzazione che conserva i file di dati ma non dispone delle configurazioni e dei componenti di accesso necessari può comunque affrontare una prolungata indisponibilità operativa.
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ò dover assumere decisioni in condizioni di forte incertezza rispetto alle priorità di ripristino, alla comunicazione, al ricorso a supporto esterno, alle misure verso i clienti, all’escalation nei confronti dei fornitori, al rapporto con le autorità, 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’approvazione formale. Il crisis management non deve dipendere da relazioni informali o dalla disponibilità 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.
All’interno di questo quadro più ampio, la Gestione integrata dei rischi di criminalità finanziaria deve rimanere strettamente collegata alla resilienza operativa digitale ogniqualvolta una perturbazione tecnologica possa compromettere i controlli destinati a prevenire, rilevare o gestire la criminalità finanziaria. La temporanea indisponibilità dei sistemi di transaction monitoring, sanctions screening, customer due diligence, fraud detection, payment control o identity verification può creare ulteriori rischi di criminalità finanziaria esattamente nel momento in cui l’attenzione operativa è assorbita da altre criticità. La pianificazione della continuità deve pertanto identificare quali controlli di criminalità 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à finanziaria consente così di collegare continuità digitale, integrità finanziaria, controllo delle transazioni, compliance alle sanzioni, prevenzione delle frodi e governance degli incidenti all’interno di un unico sistema di controllo. La resilienza digitale cessa quindi di essere una disciplina puramente tecnica di continuità e diventa una più ampia capacità istituzionale, finalizzata a proteggere simultaneamente continuità operativa, conformità regolamentare, integrità finanziaria e capacità della vostra organizzazione di assumere decisioni difendibili sotto pressione.
Test di resilienza operativa digitale, esercitazioni basate su scenari e test guidati dalle minacce
La resilienza operativa digitale non può 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, è 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ù dipendenze tecniche, organizzative ed esterne vengono compromesse simultaneamente. Un programma di testing efficace collega pertanto le vulnerabilità tecniche all’impatto concreto sull’attività. 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ù unità organizzative, dati essenziali diventino temporaneamente inaffidabili, un fornitore esterno di servizi ICT disponga di una capacità di ripristino insufficiente oppure emerga che diversi fornitori dipendono dalla medesima infrastruttura sottostante. Non deve essere la complessità tecnica dello scenario a guidare l’esercizio, ma il potenziale impatto sulla continuità 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’esercitazione. 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à e capacità di recovery corrispondano realmente alle esigenze operative.
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à dei servizi, alle priorità di ripristino, agli obblighi regolamentari di notifica, alle comunicazioni verso i clienti, al coinvolgimento di consulenti esterni e all’escalation verso le autorità di vigilanza. Un’esercitazione ben progettata deve riprodurre deliberatamente questa incertezza. La vostra organizzazione può, ad esempio, trovarsi inizialmente di fronte a quella che appare come una limitata indisponibilità di servizio, per poi scoprire che l’evento è collegato a un accesso non autorizzato, a una possibile manipolazione dei dati e alla compromissione di un fornitore. In una fase successiva può emergere che lo stesso fornitore supporta anche un altro servizio aziendale critico, amplificando ulteriormente l’impatto operativo. Introducendo questi sviluppi in modo progressivo, l’esercitazione consente di verificare se le informazioni siano condivise tempestivamente, se le responsabilità 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à di escalation disponibili. Il valore di tali esercitazioni non risiede quindi nella conferma della conoscenza delle procedure esistenti, ma nell’individuazione delle incoerenze tra piani formali e comportamento effettivo. La vostra organizzazione ottiene così informazioni concrete sulla velocità decisionale, sulla qualità dei dati, sulla capacità di coordinamento, sulla recuperabilità dei processi e sulle dipendenze organizzative che una revisione documentale convenzionale potrebbe non evidenziare.
Per le entità finanziarie, DORA può inoltre richiedere, a seconda della natura, delle dimensioni e del profilo di rischio dell’organizzazione, test di penetrazione avanzati basati sulle minacce. Questi test analizzano l’organizzazione dal punto di vista di avversari realistici e verificano se funzioni critiche possano essere compromesse mediante tecniche, tattiche e procedure coerenti con l’intelligence 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à di gestione delle vulnerabilità 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’attacco coordinata. Le finding non devono pertanto essere classificate esclusivamente in termini tecnici. La vostra organizzazione deve determinare quali vulnerabilità possano compromettere servizi critici, quali cause strutturali siano alla base delle debolezze individuate e quali misure di remediation meritino priorità. Questo approccio si collega direttamente alla Gestione integrata dei rischi di criminalità finanziaria, poiché gli stessi percorsi digitali di accesso che minacciano la continuità operativa possono essere sfruttati per frodi nei pagamenti, appropriazione o abuso di identità, manipolazione dei dati, elusione delle sanzioni o altre forme di criminalità finanziaria. Collegare i risultati tecnici dei test ai rischi operativi, giuridici e di integrità permette di ottenere una visione molto più completa dell’esposizione effettiva della vostra organizzazione. L’esito 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é il testing contribuisca direttamente al rafforzamento strutturale della resilienza digitale.
Rischio ICT derivante da terze parti, registri di outsourcing e dipendenze da fornitori critici
La continuità digitale della vostra organizzazione dipende sempre più 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ò crea una questione fondamentale di governance: la vostra organizzazione può esternalizzare l’esecuzione 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à esistano e quali conseguenze deriverebbero da una improvvisa indisponibilità del fornitore. Devono inoltre essere considerate la solidità finanziaria, operativa e giuridica della controparte. Un fornitore tecnicamente sofisticato può comunque generare un rischio significativo di continuità 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à del servizio aziendale supportato.
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ò 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à, gli obiettivi di recovery, gli obblighi di testing, la protezione dei dati, i diritti di risoluzione e il supporto all’uscita. 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’indagine 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ò introdurre nuovi subfornitori, migrare infrastrutture o sostituire componenti tecnici. Se tali modifiche non vengono individuate tempestivamente, il profilo di rischio del servizio può 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.
I registri degli accordi contrattuali ICT assumono particolare rilievo ai sensi di DORA, poiché devono offrire visibilità sull’ampiezza 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à giuridiche, localizzazioni, categorie di dati e subfornitori. La vostra organizzazione deve poter utilizzare tale quadro per individuare se più 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’impatto di un incidente. Anche una diversificazione apparente può 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à dei singoli confini contrattuali. La stessa metodologia può essere utilizzata nell’ambito della Gestione integrata dei rischi di criminalità finanziaria per valutare se terze parti abbiano accesso a dati finanziari sensibili, flussi di transazioni, identità dei clienti o meccanismi di controllo rilevanti per la prevenzione e l’individuazione della criminalità finanziaria. Il rischio fornitori diventa così una componente integrata della resilienza digitale, della continuità operativa e della gestione dei rischi di integrità. 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’evento e di dimostrare successivamente quali misure di controllo fossero state predisposte.
Responsabilità degli organi di gestione, propensione al rischio ICT e supervisione del senior management
La resilienza operativa digitale richiede una responsabilità 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à dell’organizzazione, 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ò 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. È molto più rilevante determinare quanto downtime non pianificato di un servizio critico sia accettabile, quali tempi massimi di recovery possano essere tollerati, quante vulnerabilità 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’ordinaria operatività e quali situazioni richiedano una decisione esplicita degli organi di gestione. Ciò evita che eccezioni tecniche temporanee si trasformino progressivamente in rischi strutturali di governance senza un adeguato livello di challenge e supervisione.
La qualità della supervisione manageriale dipende in larga misura dalla qualità 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à possano compromettere l’erogazione 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’anzianità delle finding di audit più rilevanti, la disponibilità 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’affidabilità del restore dei backup e il numero di eccezioni significative alle policy di sicurezza. Anche le tendenze assumono rilievo. Una deviazione isolata può essere tollerabile, mentre un deterioramento persistente dello stesso indicatore può 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à state adottate e quali incertezze residue permangano.
La responsabilità degli organi di gestione si manifesta inoltre nel modo in cui vengono bilanciati interessi concorrenti. Gli investimenti nella resilienza digitale competono spesso con priorità 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ò essere economicamente comprensibile, ma può al tempo stesso aumentare l’esposizione 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à finanziaria assume qui particolare rilievo. Una debolezza nei controlli digitali può compromettere non solo la continuità 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à 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é determinati rischi vengano accettati e come venga verificato che tale accettazione rimanga entro limiti giuridici, regolamentari e sociali sostenibili.
Indagini di vigilanza, esposizione all’enforcement e difesa procedurale
La vigilanza sulla resilienza operativa digitale sta evolvendo da una valutazione prevalentemente policy-based verso una verifica sempre più fattuale dell’effettiva efficacia dei sistemi di controllo. Quando un’autorità di vigilanza formula domande sulla conformità a NIS2, alla disciplina nazionale di cybersicurezza, a DORA o a obblighi settoriali connessi, l’analisi difficilmente si limiterà alla documentazione di policy. Può 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à con cui le carenze note siano state affrontate. Per la vostra organizzazione è quindi essenziale trattare un’indagine 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à giuridica e con quale finalità di supervisione? Una disclosure eccessivamente ampia o insufficientemente controllata può involontariamente aprire nuove linee di indagine o sovrapporre fatti tra loro distinti. Un atteggiamento eccessivamente difensivo può, al contrario, compromettere il rapporto con il supervisore e generare l’impressione che informazioni rilevanti vengano trattenute. L’approccio più solido combina cooperazione trasparente, rigoroso controllo fattuale, precisa delimitazione giuridica e comunicazioni coerenti.
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’esistenza di misure adeguate, da attacchi sofisticati, vulnerabilità precedentemente sconosciute, errori di fornitori o una combinazione eccezionale di circostanze. L’analisi giuridica deve quindi esaminare quali misure fossero in vigore prima dell’incidente, quali rischi fossero ragionevolmente conoscibili, quali segnali fossero disponibili, con quale rapidità l’organizzazione abbia reagito e quali miglioramenti siano stati introdotti successivamente. Allo stesso tempo, l’assenza 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’epoca della decisione e quelle acquisite soltanto successivamente. In caso contrario, l’analisi può essere influenzata da hindsight bias, facendo apparire un rischio molto più prevedibile di quanto fosse ragionevolmente prima dell’evento. Una solida difesa procedurale deve quindi dimostrare quali fatti fossero conosciuti in ogni momento decisionale, quali incertezze permanessero e perché determinate scelte fossero difendibili nelle circostanze concrete.
Quando un’autorità valuta misure di enforcement, assumono rilievo centrale proporzionalità, imputabilità, prova, causalità 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’organizzazione. Anche il ruolo dei fornitori esterni può essere rilevante. Sebbene l’outsourcing non elimini la responsabilità, la causa concreta dell’incidente può influire sulla valutazione del grado di colpa e sulla proporzionalità 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à manageriale. La stessa logica vale quando l’incidente presenta collegamenti con frodi, manipolazione dei dati, abusi nei pagamenti o altre forme di criminalità finanziaria. La Gestione integrata dei rischi di criminalità finanziaria può, in tali situazioni, collegare cyber incident, controlli interni, rischi transazionali e possibili pattern di abuso all’interno di un unico quadro probatorio. Ciò consente alla vostra organizzazione non soltanto di rispondere alle richieste dell’autorità, ma anche di dimostrare che la remediation sia stata integrata in modo strutturale e che i rischi sottostanti siano stati effettivamente ridotti.
Governance integrata della resilienza digitale, remediation e continuità istituzionale
La resilienza operativa digitale raggiunge la massima efficacia quando cybersicurezza, continuity management, ICT risk management, supplier management, legal compliance, privacy, controllo della criminalità finanziaria e crisis management non operano come discipline separate, ma vengono collegate all’interno di un unico sistema coerente di governance. Ciò 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ò permette di evitare sia la frammentazione sia un’eccessiva semplificazione giuridica.
La governance della remediation costituisce un elemento fondamentale di tale sistema. Finding di audit, analisi post-incidente, risultati di testing, osservazioni delle autorità 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ò venire meno la visione complessiva e difetti simili possono essere registrati più 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à, 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’azione di remediation non dovrebbe essere considerata completata semplicemente perché una modifica è stata amministrativamente implementata, ma soltanto quando sia stato dimostrato che la misura funzioni effettivamente. Per le carenze critiche può 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.
La continuità 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à decisionale siano simultaneamente sottoposti a pressione. Ciò richiede adeguata ridondanza in termini di conoscenze, poteri, dati, canali di comunicazione e capacità 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à finanziaria deve costituire parte integrante dello stesso approccio alla continuità. L’indisponibilità del transaction monitoring, della customer due diligence, del sanctions screening, dei payment control o della fraud detection può generare ulteriori rischi di criminalità finanziaria proprio nel momento in cui l’attenzione operativa è assorbita da altre criticità. I continuity plan devono pertanto stabilire esplicitamente quali controlli di integrità debbano rimanere disponibili almeno a un livello minimo e quali attività di monitoraggio rafforzato debbano essere attivate qualora i controlli ordinari risultino temporaneamente degradati. L’obiettivo finale è un’organizzazione 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’integrità finanziaria e sul processo decisionale. La resilienza operativa digitale diventa così una competenza istituzionale permanente: non soltanto uno strumento per prevenire gli incidenti, ma un mezzo per proteggere continuità, certezza del diritto, fiducia e affidabilità istituzionale quando l’ambiente digitale viene gravemente compromesso.
