Ancorare il registro dei rischi ai dati ACN (e i tre modi di sbagliarlo)

Nella maggior parte dei registri dei rischi che capita di leggere in una PMI, la probabilità è un aggettivo. «Media». «Alta». Nessuna traccia di come ci si sia arrivati, nessun riferimento esterno, nessuna data. Da qualche mese esiste una fonte pubblica che permette di sostituire l'aggettivo con un ragionamento tracciabile: l'Operational Summary mensile di ACN.
È il punto su cui un auditor ISO/IEC 27001 si ferma per primo, e non perché pretenda una cifra: la norma non chiede un numero preciso, chiede un processo di valutazione ripetibile e riesami periodici documentati. Un aggettivo non è ripetibile. Due persone diverse, sullo stesso rischio, scrivono aggettivi diversi — e nessuna delle due può spiegare perché.
L'edizione di luglio 2026, pubblicata il 20 agosto, è l'occasione per spiegare come si usa questa fonte. E soprattutto come non si usa, perché i tre errori più comuni peggiorano il registro invece di migliorarlo.
Perché questa fonte è diversa
Tre proprietà, tutte verificabili aprendo il documento.
Ha una base giuridica, non un campione commerciale. I dati derivano dal monitoraggio del CSIRT Italia e dalle segnalazioni dovute per legge. Non è un'indagine su chi ha scelto di rispondere a un questionario, con l'autoselezione che ne consegue: è ciò che i soggetti obbligati devono notificare. Le comunicazioni inviate dal CSIRT a imprese e amministrazioni nel solo mese di luglio — 8.952, in aumento di 198 rispetto a giugno — sono trasmesse anche ai sensi dell'art. 2, comma 1, della Legge 90/2024.
Ha cadenza mensile. Il Rapporto Clusit è annuale, l'ENISA Threat Landscape è annuale. Dodici osservazioni l'anno cambiano la natura di ciò che si può dimostrare: non una fotografia da citare una volta e archiviare, ma una serie con cui alimentare il riesame periodico.
È nazionale e settoriale. A luglio i settori con più vittime sono stati Pubblica amministrazione locale, Manifatturiero, Tecnologico e Telecomunicazioni, con l'indicazione della minaccia prevalente per ciascuno: defacement per la PA locale, phishing e compromissione di caselle e-mail per il manifatturiero, esposizione dati per il tecnologico. È una granularità in cui una PMI italiana si riconosce, cosa che in un aggregato globale non accade quasi mai.
Dall'indicatore alla riga di registro
Il passaggio concreto, su un esempio reale di luglio. L'attività di analisi sui CMS open source esposti ha rilevato 1.074 istanze CMS compromesse, segnalate ai titolari dei sistemi o ai provider per la bonifica, concentrate nei settori vendita al dettaglio, manifatturiero, università e ricerca e PA locale. In parallelo, una campagna di defacement ha colpito oltre 60 siti basati su Joomla, sfruttando la CVE-2026-48907 nell'estensione Joomla Content Editor, già oggetto di un alert del CSIRT Italia il 15 giugno.
Nel registro dei rischi questo non diventa «rischio CMS: alto». Diventa una riga con quattro elementi:
- Scenario: compromissione del CMS del sito istituzionale tramite vulnerabilità nota non sanata, con defacement o hosting di contenuti malevoli.
- Evidenza esterna: Operational Summary ACN luglio 2026, 1.074 istanze compromesse rilevate; campagna Joomla/JCE su CVE-2026-48907, alert CSIRT del 15 giugno 2026.
- Applicabilità al nostro contesto: usiamo un CMS esposto? quale? con quali estensioni? qual è il tempo medio fra la pubblicazione di un alert CSIRT e l'applicazione della patch?
- Stima motivata: la probabilità sale non perché «lo dice ACN», ma perché l'evidenza esterna documenta campagne massive opportunistiche e la nostra verifica interna mostra un tempo di patching superiore alla finestra di sfruttamento osservata.
La differenza rispetto all'aggettivo è che questa riga si può discutere, contestare e ricalcolare. Ed è agganciabile al riesame: la revisione trimestrale del registro cita gli ultimi tre bollettini, producendo l'evidenza di monitoraggio continuo che la NIS2 e il §9.3 della 27001 chiedono di dimostrare.
Un dettaglio tecnico che conta: i numeri sono provvisori.
Confrontando le edizioni si scopre che ACN rivede i conteggi a posteriori. Il bollettino di aprile dichiara 174 incidenti; quello di maggio, citando aprile, scrive 175. Maggio dichiara 158 incidenti; giugno, citando maggio, scrive 161. Giugno dichiara 184; luglio, citando giugno, scrive 182. Sono scostamenti piccoli e fisiologici — il triage si consolida col tempo — ma hanno una conseguenza pratica: in un registro dei rischi si cita sempre il numero con l'edizione e la data del bollettino da cui proviene, non il numero da solo. Altrimenti si crea una discrepanza inspiegabile fra il registro e la fonte alla revisione successiva, ed è il tipo di dettaglio che in audit costa più della stima stessa.
1. Confondere la superficie di reporting con la minaccia
È l'errore più diffuso, e ACN lo previene esplicitamente. Il bollettino ricorda che gli obblighi di notifica introdotti dalla NIS2 sono pienamente operativi da gennaio 2026 e che questo «ha favorito un incremento significativo del numero di eventi e incidenti cyber visibili ad ACN rispetto ai medesimi periodi di riferimento degli scorsi anni». L'edizione di aprile è ancora più netta: l'incremento dei primi mesi del 2026 è «riconducibile alla progressiva entrata a regime degli obblighi di notifica introdotti dalla Direttiva NIS2», a conferma di «una più ampia emersione degli eventi e degli incidenti cyber».
Emersione, non aumento. E ACN aggiunge l'avvertenza decisiva, ripetuta di mese in mese: «all'ampliamento della visibilità garantita dal nuovo flusso informativo non corrisponde un aumento degli impatti causati dagli incidenti, i quali sono allineati alla media dei mesi precedenti».
Tradotto: la curva del 2026 sale perché è salito l'obbligo di segnalare, non perché l'Italia sia sotto attacco più di prima. Chi userà quei numeri come prova di un'escalation starà misurando l'entrata in vigore di una norma. La serie mensile degli eventi — 225 a gennaio, 435 a marzo, 265 ad aprile, 390 a maggio, 424 a giugno, 305 a luglio — è ingovernabile come indicatore di minaccia proprio per questo, e i cali sono altrettanto ingannevoli: la flessione del 28% di luglio è ricondotta «principalmente all'assenza di campagne DDoS di matrice hacktivista» e a un minor numero di eventi che hanno colpito fornitori di servizi IT. Nessuno è diventato più sicuro a luglio; sono mancate due categorie di eventi rumorosi.
2. Trattare una frequenza settoriale come la propria probabilità
Il settore «manifatturiero» contiene la multinazionale con SOC attivo 24 ore su 24 e la SRL con otto dipendenti, un gestionale non aggiornato e un NAS raggiungibile da Internet. Attribuire alla seconda la frequenza media del settore è un errore di categoria: sostituisce una stima soggettiva dichiarata con una stima soggettiva mascherata da dato.
Il caso Joomla di luglio lo dimostra meglio di qualunque argomento teorico. ACN osserva che la campagna ha colpito soggetti «in settori diversi — principalmente PA locale, ma anche enti di ricerca, università e imprese del settore tecnologico — tutti basati sul medesimo CMS», e conclude che «la selezione dei bersagli è avvenuta in funzione della vulnerabilità esposta, anziché del settore di appartenenza o delle caratteristiche dei soggetti colpiti».
L'attributo che determinava il rischio, quel mese, non era il settore: era quale software esponi e in che stato di aggiornamento. Un registro che pesa i rischi per settore avrebbe mancato completamente la campagna; un registro che parte dall'inventario degli asset esposti l'avrebbe intercettata. La statistica nazionale è un punto di partenza da correggere con l'esposizione reale — superficie esposta, maturità del patching, dipendenze da fornitori IT — non un moltiplicatore da applicare.
Vale anche per il perimetro: dei 3.210 asset potenzialmente vulnerabili individuati a luglio dal monitoraggio proattivo, le comunicazioni sono state indirizzate ai soggetti della constituency — i settori NIS, il Perimetro, le telco, la PA. Se l'azienda è fuori da quel perimetro, non riceve quella segnalazione: la stessa vulnerabilità, senza l'avviso.
3. Ignorare ciò che la fonte non vede
ACN misura ciò che arriva ad ACN. Il documento lo dichiara nella sua stessa formulazione: eventi e incidenti «visibili ad ACN». Una PMI fuori perimetro, colpita da ransomware, che ripristina dai backup e non notifica nulla a nessuno, in quei numeri non c'è. Il dato è un limite inferiore, non un censimento.
Questo non indebolisce la fonte: la qualifica. E dichiararlo nella metodologia del risk assessment è un punto di forza in audit, non una vulnerabilità. Un registro che scrive «questa stima si basa su dati che coprono i soggetti in perimetro e sottostimano per costruzione il segmento non obbligato» dimostra padronanza del metodo. Un registro che presenta il numero ACN come la fotografia completa del rischio nazionale dimostra il contrario.
Cosa portarsi in azienda
Non «usate i dati ACN». Piuttosto: la differenza fra un registro dei rischi che regge un audit e uno che non lo regge non sta nella precisione del numero, sta nella tracciabilità del ragionamento. Una fonte pubblica, periodica, con base giuridica e granularità settoriale rende quel ragionamento documentabile con uno sforzo marginale — a condizione di usarla come ancoraggio e non come automatismo.
Resta la domanda scomoda, che è di processo e non di dati. Il bollettino esce ogni mese; le nuove CVE pubblicate solo a luglio sono state 9.919, di cui 324 con almeno un proof of concept e 13 con sfruttamento attivo rilevato. Quante PMI hanno davvero qualcuno che legge dodici bollettini l'anno, li confronta, e traduce ciò che leggono in due righe di registro aggiornate? Nella nostra esperienza, poche — e non per pigrizia, ma perché il riesame periodico è un processo che nessuno ha mai progettato. Se è così, il problema non è la mancanza di dati. È che i dati migliorati degli ultimi mesi hanno reso visibile un vuoto che c'era da prima.
Fonti
- ACN, «Torna l'appuntamento mensile di ACN con i dati e gli indicatori della minaccia cyber in Italia», 20 agosto 2026
- ACN, Operational Summary luglio 2026, TLP:CLEAR
- ACN, Operational Summary aprile 2026, TLP:CLEAR
- ACN/CSIRT Italia, archivio delle pubblicazioni (serie mensile completa)
- CSIRT Italia, alert sullo sfruttamento attivo della CVE-2026-48907 (Joomla JCE), 15 giugno 2026
- Legge 28 giugno 2024, n. 90, art. 2, comma 1
- D.Lgs. 4 settembre 2024, n. 138 (attuazione della Direttiva NIS2)
- ISO/IEC 27001:2022, §6.1.2 e §9.3