Come dimostrare la compliance NIS2 in un audit: le evidenze tecniche che contano davvero

Policy e documenti non bastano

La NIS2 ha una cattiva reputazione come esercizio burocratico. L'idea che per essere compliant basti produrre un set di policy, una valutazione del rischio teorica e qualche organigramma di responsabilità è diffusa nelle PMI italiane, e deriva spesso da come la compliance IT viene gestita tradizionalmente.

Ma gli audit NIS2 in ambito OT funzionano diversamente. Un verificatore tecnico esperto non si accontenta di vedere un documento che descrive come in teoria vengono gestiti gli asset OT: chiede di vedere la lista degli asset aggiornata la settimana scorsa. Non si accontenta di una policy di gestione delle vulnerabilità: chiede di vedere gli ultimi report di vulnerability assessment e le decisioni documentate di patching. Non si accontenta di un piano di incident response: chiede di vedere i log degli alert gestiti negli ultimi mesi.

Questa distinzione tra documenti di intenzione e evidenze tecniche è fondamentale per capire cosa serve davvero per superare un audit NIS2 in ambito OT.

Le quattro categorie di evidenze tecniche

1. Asset inventory aggiornato

Un audit NIS2 OT inizia quasi sempre con una domanda diretta: "Mostratemi la lista dei vostri asset OT". La risposta attesa non è un file Excel redatto sei mesi fa e aggiornato a mano durante le manutenzioni. E' un inventario che dimostri di essere mantenuto attivo, con date di aggiornamento recenti e un processo definito per mantenerne la correttezza.

Le informazioni minime che un inventario OT deve contenere per essere utile in un audit:

• Identificativo univoco e nome del dispositivo
• Tipo (PLC, HMI, RTU, SCADA server, historian, dispositivo di campo)
• Produttore e modello
• Versione firmware/software corrente
• Indirizzo IP o identificatore di rete
• Zona di rete di appartenenza
• Criticità operativa (cosa succede se questo dispositivo va offline?)
• Stato delle vulnerabilità note (CVE rilevanti identificate)

Un inventario che manca di voci recenti, che contiene dispositivi con data di ultimo aggiornamento di anni fa, o che non include i dispositivi di campo (solo i server SCADA, per esempio) è un segnale negativo per il verificatore.

La domanda di follow-up più comune: "Come viene aggiornato questo inventario quando si aggiunge un nuovo dispositivo?" Se la risposta è "manualmente quando ci ricordiamo", la robustezza del processo è evidentemente bassa.

2. Evidenza di vulnerability assessment periodico

La NIS2 richiede processi di gestione delle vulnerabilità. In un audit, questo si traduce nella capacità di dimostrare che il vulnerability assessment viene condotto con una certa regolarità, che i risultati vengono documentati, e che le vulnerabilità identificate vengono gestite con un processo tracciabile.

Le evidenze tipicamente richieste:

• Report dell'ultimo vulnerability assessment (data, scope, metodologia)
• Lista delle vulnerabilità identificate con il loro stato (patchata, accettata, con misura compensativa)
• Registro delle decisioni: per ogni vulnerabilità aperta, documentazione della decisione presa e della sua motivazione
• Evidenza che le fonti di intelligence sulle vulnerabilità OT vengono monitorate (avvisi CISA ICS-CERT, bollettini dei vendor)

Un elemento spesso mancante nelle PMI: la documentazione delle decisioni di non applicare una patch. "Abbiamo deciso di non aggiornare il firmware del PLC perché l'aggiornamento richiederebbe un fermo linea di 8 ore e abbiamo implementato come misura compensativa X" è una posizione difendibile in un audit. "Non abbiamo aggiornato perché non ci abbiamo pensato" non lo è.

La periodicità accettabile dipende dalla criticità dell'ambiente. Per sistemi OT critici, un vulnerability assessment annuale è un minimum. Per asset ad alta criticità con vulnerabilità note attivamente sfruttate, può essere richiesta una frequenza maggiore.

3. Log di detection e gestione degli alert

La capacità di rilevare compromissioni è implicita nei requisiti NIS2 ma spesso sottovalutata. Se un incidente significativo deve essere notificato entro 24 ore, significa che l'organizzazione deve essere in grado di rilevarlo entro tempi molto più brevi. Questo presuppone l'esistenza di un sistema di monitoring e di un processo di gestione degli alert.

Le evidenze che un verificatore cerca in questa categoria:

• Prova che esiste un sistema di monitoring della rete OT (non necessariamente sofisticato, ma presente e funzionante)
• Log degli alert degli ultimi mesi, con evidenza che vengono esaminati e gestiti
• Documentazione della triage degli alert: ogni alert deve risultare "esaminato" con un'indicazione dell'esito (falso positivo con motivazione, incidente reale gestito, situazione da monitorare)
• Processo di escalation: chi riceve gli alert, chi decide se è un incidente, chi notifica il management

Un'organizzazione che non ha logging del traffico OT è in una posizione molto debole in un audit NIS2. La domanda "come fate a sapere se avete subito un incidente?" non ha risposta soddisfacente se non c'è un sistema di monitoring.

Un punto spesso trascurato: la retention dei log. I log devono essere conservati per un periodo sufficiente a supportare un'eventuale investigazione forense. Sei mesi è un minimum ragionevole; un anno è meglio. Log che vengono sovrascritti ogni settimana non sono evidenze.

4. Procedure di notifica incidente documentate e testate

La NIS2 stabilisce scadenze precise per la notifica degli incidenti significativi: 24 ore per l'early warning, 72 ore per la notifica iniziale completa, 30 giorni per il rapporto finale. Rispettare queste scadenze senza una procedura pronta è praticamente impossibile durante la gestione di un incidente reale.

Le evidenze richieste in questa area:

• Procedura di notifica incidente scritta, con workflow chiaro e responsabilità assegnate
• Definizione operativa di "incidente significativo" applicabile al contesto specifico
• Contatti aggiornati di ACN e procedure di accesso al portale di notifica
• Evidenza che la procedura è stata esercitata (tabletop exercise, simulazione)
• Registro degli incidenti passati, anche quelli non significativi ai fini NIS2, come dimostrazione che il processo di rilevamento e gestione è attivo

L'ultima evidenza è spesso la più difficile da produrre per le PMI che non hanno mai formalizzato il processo: un registro vuoto ("non abbiamo mai avuto incidenti") è plausibile per un'organizzazione con monitoring robusto, ma è sospetto per una che non ha monitoring e non ha mai trovato nulla.

Il monitoring OT continuo come fonte di evidenza

Una delle sfide degli audit NIS2 è che le evidenze richieste devono essere costruite nel tempo. Non si può produrre sei mesi di log di monitoring la settimana prima di un audit: i log devono esistere già, datati correttamente, non manipolabili.

Questo crea un vantaggio strutturale per le organizzazioni che hanno implementato monitoring OT continuo: il sistema genera automaticamente evidenze date e ora in modo non modificabile. I report di monitoring diventano documentazione di audit senza lavoro aggiuntivo.

Concretamente, un sistema di monitoring OT ben configurato produce:

• Report periodici dell'inventario degli asset rilevati, con timestamp
• Log di tutti gli alert generati con data, ora, descrizione e stato di gestione
• Evidenza delle comunicazioni anomale rilevate e delle azioni intraprese
• Report sulle vulnerabilità identificate sugli asset monitorati
• Storico delle variazioni nell'inventario degli asset (nuovi dispositivi apparsi, dispositivi rimossi)

Questo tipo di documentazione automatica risponde direttamente alle richieste più frequenti dei verificatori NIS2, e lo fa con evidenze che hanno credibilità intrinseca: sono prodotte da un sistema tecnico in modo continuo, non redatte a mano in vista dell'audit.

Come strutturare il pacchetto di evidenze per un audit

Un approccio pratico è costruire un "pacchetto di audit" che possa essere presentato rapidamente quando richiesto. Non deve essere uno stack di carta: può essere una cartella di file organizzata, aggiornata periodicamente.

Il pacchetto minimo per un audit NIS2 OT include:

1. Inventario asset OT (aggiornamento recente documentato)
2. Ultimo report di vulnerability assessment, con registro delle decisioni sui finding
3. Policy di sicurezza OT approvata dal management (con data di approvazione e revisione)
4. Procedura di incident response e notifica NIS2 (con evidenza di almeno un'esercitazione)
5. Log degli alert degli ultimi 90-180 giorni, con triage documentata
6. Elenco dei fornitori con accesso remoto ai sistemi OT e relativi controlli in atto
7. Configurazioni di backup e piano di disaster recovery OT

La preparazione di questo pacchetto non è un'attività una tantum: richiede che i processi sottostanti siano attivi e che le evidenze si accumulino nel tempo. L'audit, in questo senso, non è l'obiettivo finale ma la verifica che i processi di sicurezza funzionano come dichiarato.

---

La differenza tra chi passa un audit NIS2 e chi no non sta nella capacità di scrivere policy: sta nell'avere processi tecnici attivi che producono evidenze verificabili. Questo richiede investimento in strumenti e processi prima dell'audit, non durante.

L'angolo MON5

Le evidenze che reggono un audit NIS2, come visto, si accumulano nel tempo: non si improvvisano la settimana prima. MON5 le produce come sottoprodotto del funzionamento normale: l'inventario asset continuo della fase ANALYZE risponde alla richiesta "mostratemi la lista aggiornata", mentre il monitoraggio della fase PROTECT genera log datati di alert, nuovi dispositivi e accessi remoti.

Il supporto compliance NIS2 integrato collega questi dati ai requisiti della direttiva, riducendo il lavoro di preparazione del pacchetto di audit. Per fotografare oggi la distanza dai requisiti, un assessment OT è il modo più rapido.