l'approfondimento

Monitorare non basta: la vulnerabilità più grande è non avere un responsabile



Indirizzo copiato

Il monitoraggio produce informazioni, ma la sicurezza si genera solo quando quelle informazioni vengono trasformate in decisioni e la decisione richiede una cosa che spesso manca: responsabilità chiare. Ecco come la misura ID.RA-08 del Fncdp impone di risolvere proprio questo nodo

Pubblicato il 28 apr 2026

Giuseppe Alverone

Consulente e formatore Privacy e Cybersecurity. DPO certificato UNI CEI EN 17740:2024

Monica Perego

Consulente, Formatore Privacy & DPO



Monitoraggio comportamenti fraudolenti la guida pratica; Monitorare non basta: la vulnerabilità più grande è non avere un responsabile
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti

La misura ID.RA-08 del Framework Nazionale per la Cybersecurity e la Data Protection impone il monitoraggio delle vulnerabilità, ma il vero punto critico non è tecnico, ma organizzativo.

Senza una chiara attribuzione di ruoli, responsabilità e livelli decisionali, il flusso informativo si interrompe e la vulnerabilità resta senza governo.

Il secondo capitolo di questa tetralogia – dedicata alla subcategoria ID.RA-08 del Framework Nazionale – affronta il nodo centrale della responsabilità, mostrando come costruire un presidio efficace che integri competenze tecniche, funzioni operative e vertice aziendale.

Se nessuno decide non vi è sicurezza

Molte organizzazioni pensano di aver risolto il problema quando attivano il monitoraggio dei canali informativi. Si iscrivono alle mailing list, configurano strumenti di alerting, assegnano a qualcuno il compito di “tenere d’occhio” le vulnerabilità.

In realtà, questo è solo l’inizio.

Perché il monitoraggio produce informazioni, ma la sicurezza si genera solo quando quelle informazioni vengono trasformate in decisioni e la decisione richiede una cosa che spesso manca: responsabilità chiare.

È qui che si può crearsi la frattura: le informazioni arrivano, ma non trovano un punto di presa perché nessuno ha il mandato di valutare, l’autorità per decidere né la responsabilità di intervenire.

Così la vulnerabilità resta sospesa e quando resta sospesa, diventa un rischio concreto.

La misura ID.RA-08 del FNCDP, letta in profondità, impone di risolvere proprio questo nodo.

Il monitoraggio come funzione organizzativa

Il primo requisito operativo che l’ACN, nella determinazione n.379907 del 19.12.2025, ha fissato per realizzare la sottocategoria ID.RA-08 richiedono che i canali del CSIRT, dei CERT, degli ISAC e dei fornitori vengano monitorati in modo sistematico.

Questo implica che il monitoraggio non può essere affidato all’iniziativa individuale o alla buona volontà ma deve diventare una funzione strutturata.

Pertanto, è necessario:

  • definire chi, all’interno dell’organizzazione, è responsabile di questa attività;
  • stabilire continuità operativa, copertura nel tempo e sostituzioni in caso di assenza;
  • garantire che il flusso informativo non si interrompa mai.

Il monitoraggio, affinchè sia efficace, deve essere continuo e quindi le segnalazioni sulle vulnerabilità devono essere aggiornate più volte al giorno. Una verifica sporadica non è sufficiente.

Tutto questo porta a una prima scelta organizzativa da assumere: il monitoraggio può essere interno oppure esternalizzato.

In entrambi i casi, la responsabilità resta in capo all’organizzazione.

Il rischio più frequente è pensare che basti assegnare il compito a una funzione tecnica senza considerare che in realtà, il monitoraggio è solo il primo anello di una catena più ampia.

Il nodo delle responsabilità interne

Definire chi monitora è necessario ma non è sufficiente. Occorre chiarire chi analizza le informazioni ricevute, chi valuta l’impatto e chi decide le azioni da intraprendere. Questi ruoli non sempre coincidono.

In molte organizzazioni, la funzione IT ha le competenze tecniche per comprendere una vulnerabilità, ma non ha l’autorità per decidere interventi che possono avere impatti operativi, economici o strategici.

Si pensi, per esempio al caso dell’installazione di una patch che sicuramente
comporta o c’è il rischio che comporti l’indisponibilità dei sistemi per alcune ore.

La scelta del momento in cui intervenire non può restare all’IT. È una responsabilità della Direzione.

Spetta al vertice decidere tempi e modalità, coordinandosi con le funzioni coinvolte, sia per la comunicazione interna sia, se necessario, verso l’esterno.

Allo stesso tempo, il vertice ha la responsabilità del rischio ma non può entrare nel dettaglio tecnico di ogni segnalazione.

Pertanto, è necessario costruire un modello chiaro in cui le competenze tecniche supportano la valutazione ma la decisione si colloca nel punto giusto della catena organizzativa.

Se questo modello non esiste possono generarsi due scenari tipici:

  • nel primo, le decisioni vengono prese troppo in basso senza una visione complessiva del rischio e sono solo quello che impatta sui sistemi IT;
  • nel secondo, le decisioni non vengono prese affatto, perché nessuno si assume la responsabilità.

Entrambi sono pericolosi.

L’estensione del presidio oltre l’IT

Un altro errore frequente è considerare la gestione delle vulnerabilità come un tema esclusivamente IT.

La realtà è diversa. Infatti, molte vulnerabilità riguardano sistemi che impattano direttamente sulla produzione, sulla logistica, sui servizi erogati; nei contesti industriali, coinvolgono ambienti OT.

Questo significa che il presidio deve estendersi oltre l’area dei sistemi industriali. Quindi, devono essere coinvolte figure come i responsabili di produzione, i manutentori, l’ufficio tecnico e non per trasformarli in esperti di cyber security, ma per integrare la valutazione tecnica con la conoscenza operativa.

Senza questa integrazione, il rischio viene valutato in modo parziale e una
valutazione parziale porta a decisioni sbagliate.

Il ruolo dei fornitori e le criticità operative

Quando l’organizzazione non dispone internamente di tutte le competenze necessarie, il monitoraggio può essere affidato in parte ai fornitori.

Questa decisione, seppure semplifichi alcuni aspetti, apre una serie di criticità che non possono essere ignorate.

Il fornitore potrebbe non avere una visibilità completa sull’intero perimetro tecnologico e potrebbe non conoscere tutte le applicazioni utilizzate, soprattutto quelle sviluppate internamente o integrate nel tempo.

Inoltre, potrebbe avere una visione limitata al proprio ambito di intervento.

Tutto questo crea un rischio rilevante: il monitoraggio diventa frammentato; le informazioniarrivano in modo disomogeneo e la responsabilità si disperde.

Per evitare questo scenario, è necessario che i contratti definiscano chiaramente cosa deve essere monitorato, con quali modalità, con quali tempi e con quali obblighi di comunicazione.

Oltre che individuare livelli di escalation e i referenti interni dell’organizzazione con cui il fornitore deve interagire per mettere in atto le misure concordate.

Anche in questo caso, la responsabilità ultima resta interna.

La necessità di una procedura formalizzata

Il terzo requisito operativo della misura ID.RA-08 non impone esplicitamente una procedura per il monitoraggio ma richiede comunque un piano di gestione delle vulnerabilità.

Ora, dal punto di vista operativo, è difficile immaginare un piano efficace senza una procedura chiara.

Quindi sarà necessario definire come:

  • avviene il monitoraggio e quali canali vengono verificati e con quale frequenza;
  • vengono registrate le informazioni e come vengono trasmesse alle funzioni competenti;
  • vanno gestite le situazioni di urgenza;
  • è garantita la continuità operativa;
  • evitare che una segnalazione rilevante resti senza risposta.

La procedura non è un adempimento ma lo strumento che rende il sistema affidabile.

Senza procedura, tutto dipende dalle persone e ciò che dipende solo dalle persone non è controllabile.

Il punto di equilibrio tra tecnica e decisione

La gestione delle vulnerabilità richiede un equilibrio delicato:

  • da un lato, servono competenze tecniche per comprendere la natura della vulnerabilità e le possibili contromisure;
  • dall’altro, serve una capacità decisionale che tenga conto degli impatti sull’organizzazione nel suo complesso.

Questo equilibrio non si costruisce automaticamente ma deve essere progettato.
Quindi bisogna definire flussi chiari, tempi di risposta, livelli di escalation. Occorre stabilire quando una decisione può essere presa a livello operativo e quando deve essere portata al livello superiore.

Questo è il punto in cui la sicurezza diventa governance.

Non si tratta più di gestire un problema tecnico ma di integrare una decisione nella gestione complessiva del rischio.

Quando ogni informazione trova un responsabile

I requisiti operativi della sottocategoria ID.RA-08 non si limitano a richiedere di monitorare le vulnerabilità, ma richiedono anche di costruire un sistema in cui ogni informazione trova un responsabile, ogni analisi trova un decisore, ogni decisione trova un’azione.

Senza questa catena, il monitoraggio è inutile.

Le organizzazioni che definiscono chiaramente ruoli e responsabilità riescono a trasformare le informazioni in scelte mentre quelle che non lo fanno accumulano dati senza riuscire a usarli.

La differenza non è tecnologica, ma organizzativa.

Nel prossimo capitolo della tetralogia, il focus si sposterà sul passaggio più delicato: come si prende una decisione su una vulnerabilità. Questo è il punto su cui si gioca la capacità di trasformare un’informazione in protezione concreta.

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x